業務模型的價值(程式員的另外一條出路)

文章目錄

• 1：業務、技術如何平衡   
• 2：程式員如何學習業務
• 3：結合業務、技術提煉業務模型

最近一直忙於新公司的基礎庫建設和一些業務系統的開發，接觸到了一些比較有思想的技術人員，在他們身上發覺到了很多值的深思的話題，也領悟到了一些比較有價值的經驗在此與同行們分享一下也算是探討一下吧；[王清培著作權，轉載請給出署名]

都說技術人員應該重視業務的學習和培養，只有精通業務了才能更好的發揮技術。其實我是不太贊成這句話的，為什嗎？從我的個人經曆和經驗來看，這是對的。當然世事無絕對，站在我們程式員的角度講，我絕對建議技術人員始終要以技術為主業務為輔的觀點。可能有些朋友要來火了，技術輔助業務應該是業務大於技術，凡事都是相對的。如果以業務為主，就等於把自己的小命送給公司管了，如果以技術為主那麼小命還是自己保管的。這句話經曆過的人才會懂，我就不解釋了。

1：業務、技術如何平衡   

中國的行情我想我們都瞭解，對於一般的企業來說，技術不重要，重要的是能在最短的時間內出東西。80%的IT企業都是屬於這種類型的，他們要求程式員快速的熟悉業務知識，然後就開始參與項目的開發。

大部分是重複勞動，程式員都在做些基本的增、刪、改、查的工作。而且這些工作都是經過層層封裝的，程式員接觸到的技術面非常的窄。長期這樣下去定力不足的程式員就會受到周圍環境的影響。有的可能選擇轉行，有的可能選擇做業務、做實施。其實這個時候我們應該勇於的選擇，應該堅持自己的理想。當然這需要興趣的支撐。

改行我就不發表看法了，畢竟人各有志。這篇文章討論的主題是業務和技術的結合，如何在技術和業務之間提煉核心的領域模型，讓我們的技術更有用武之地。

那麼站在公司的角度講我們應該多去學習業務知識，技術一般都是放在一些架構師手上，我們只要學會使用公司的架構就行了。

技術輔助於業務，搞業務的人始終覺得業務大於技術，技術人員應該聽他們的。這種現象很普遍，至少我接觸到的公司都是這樣的。他們讓程式員改什麼就改什麼，因為他們不懂程式的錯綜複雜，可能一點點的不合理都有可能造成程式的整體結構變動，帶來的工作量可能是開發的幾倍。領導又可能會說，你們能不能設計一個很模組化的，高內聚低耦合的外掛程式系統或者又是什麼新的名詞。我們可能很無語，因為他們不懂技術？哪有一勞永逸的系統啊；

其實矛盾點就在於如果我們技術人員用大精力去學習業務知識，我們相對學習技術的時間會很少，那麼我們就是把自己和公司綁在了一起。這個時候我們考慮的問題的角度是不同的，如果你重視業務那麼你可能需要公司對你的提拔或者說是你的飯碗是捏在公司手上的，如果公司哪天看你不順眼，你就失業了。如果我們的技術一直是領先的，那麼我不怕你公司不要我，我到哪裡都是能生活的。可能說這句話有點自私，但是我到覺得程式員應該學會保護自己。[王清培著作權，轉載請給出署名]

如果真的覺得你的領導值得你去追隨，那麼你就好好學習業務吧；如果公司真的沒有值得你付出的地方，那請你好好學習技術吧；

2：程式員如何學習業務

我們程式員該如何學習業務？我覺得我們應該有選擇的學習，不要所有東西都學。

一個公司的業務可能很簡單也可能很複雜，我們要選擇跟系統相關的業務，做哪塊我們學習哪塊，最重要的是有業務模型的概念在腦子裡，這中模型化的思想可以看看《領域驅動設計》。

為什麼要說有業務模型的概念呢？其實這是一種慢慢培養我們設計能力的方式。程式員學習業務知識在概念上一定要明確，不能模糊，因為這些概念都要在系統中體現的。如果我們理解上是模模糊糊的那麼我們寫的代碼也是含糊不清的，在和同事交流的時候我們的模組可能造成其他模組的不明確，這時候瓶頸就來了。

我們學習業務知識一定要記得能否在代碼中體現整體結構，能否提煉出業務模型；

圖1:

我們學習業務知識要適當的歸類，將某一條業務線上的對象抽象出來。

如果我們能善於在代碼中表達業務，那麼這和光使用技術來實現準系統要強了很多。至少這是設計類的工作。(設計能力體現技術層次)

3：結合業務、技術提煉業務模型

在和一些搞領域模型的人聊天的時候，能感受到很強烈的模型感。他們對業務的理解很苛刻，不允許存在半點鐘模糊。為什麼要強調這麼細緻呢？這能使他們的模型更加健壯穩固。往往他們的競爭力非常的明顯，精通業務和技術。

但是又與我們所見到的業務不同，他們能將業務順利的過度到代碼上。他們能將業務梳理的很工整，我們只要稍微瞭解一點業務就可以參與項目的開發，在代碼中完全是按照業務的模型來構造的。這種人一旦熟悉了某個行業之後，是絕對的領域專家了。

總結：

其實上面廢話一堆，也算是我最近來的一點小小的感悟吧。

技術是我們程式員的生命線，只有在技術上佔據絕對的優勢才能保住飯碗。然後將我們的技術提升到一個建模境界，那就真的技術服務於人了。謝謝；