若是你是業務線的程序員

    最近在面試工做中，遇到了一些和我同樣在業務線摸爬滾打多年的程序員，很遺憾他們沒有達到公司的標準經過初試。因爲看到的不是個例，就想着總結一篇文章出來，寫給和我同樣「奮戰」在業務線上的程序員(開發人員），一塊兒鞭策一塊兒進步。

    1、若是你是業務線的程序員

    一、業務線程序員的工做內容和挑戰

 

 

    【圖1】

    我以爲歸納一句話：「把甲方的業務需求用代碼變爲現實」。之因此用「甲方」而沒有用「產品經理」這個詞，是由於需求的提出者並不必定像互聯網公司同樣是產品經理，在傳統軟件行業多是項目經理甚至客戶，還有可能就是老闆。

    拋開可能面對的高併發帶來的技術高可用、分佈式一致性等等技術難點，有時候咱們業務線的程序員(開發人員）本身也認可，工做的挑戰每每是來自於「容易變化的需求和不容易的適應變化的代碼之間的矛盾」。需求的變化，表現爲不肯定的持續變化的需求，來源於外界環境的變化和甲方的決策。代碼的適應性，表現爲已有的代碼在面對變化後的需求時實現的難易程度。

    二、面對現實

        曾經有過的把老闆的口頭需求轉化爲產品文檔的經歷讓我意識到：做爲一名開發人員，不要幻想能遇到把全部產品邏輯一次想清楚的產品經理（甲方），由於我本身都作不到這點。與其不停的抱怨多變的需求，不如讓本身專一於解決問題並擁抱變化，不要去作那個團隊中讓人討厭的「過後諸葛亮」。
　　若是碰見「讓你作根據主題根據手機殼變化」的那樣的產品經理，解決的問題辦法不少種，揍這種智商低下的把本身拉下水，有點不值。不過，哪裏有壓迫哪裏就會有反抗是真的。

    2、不要成爲這樣的業務線程序員

    面試業務線的程序員，我通常會問至少以下三類問題。

    首先讓面試者把他作過的一個需求先簡單講一下。候選人若是不可以描述清楚本身實現的需求，代表基本的溝通能力仍是須要增強的，業務線上的程序員不止和機器打交道，能把本身掌握的信息清楚準確的傳遞給他人很重要。

    而後會再問一下這個需求的具體實現，目的是考驗系統分析設計的能力。若是一個工做超過3年的程序員，依然不能借助uml之類的工具清晰的把需求涉及的模塊和領域模型表述出來，那麼就不要輕易的給本身的簡歷寫上「有多年系統分析的經驗」。面對需求進行系統分析的結果，若是是直接設計的表結構，這樣的設計很難面對將來的需求變化，由於抽象的高度不夠太容易「只見樹木不見森林」。高級的產品經理都能用uml清晰的表達本身的產品邏輯，更況且咱們程序員了。

    最後一個問題是關於面向對象的思想的，好比oo的原則，設計模式之類的。讓我不能接受的是，有的候選人不瞭解設計模式竟然就敢大言不慚的說「我以爲設計模式在業務開發的工做中沒什麼用」之類的話。面向對象思想，設計模式，領域建模等等，都是一些業內的大牛爲了解決業務開發中的問題而總結分享出來的，業務線的程序員更應該比系統開發線的程序員掌握的好。

    3、業務線程序員的成長

    一、真正作好平常的業務開發工做

    （1）完善基本功

    若是你學過，若是你也認爲「設計模式在業務開發的工做中沒什麼用」，那麼就在學一遍，同時想想過去的工做中有沒有可以從新設計優化的地方。

 

 

    【圖2 關於面向對象的學習路線】

    學習掌握oo三大特性、oo六大原則、二十一個設計模式後，再瞭解一些領域驅動設計的思想，那麼無論到了任何公司任何業務場景，我相信你都會很快上手。

    （2）鍛鍊溝通能力

    不是口若懸河滔滔不絕才是好的溝通能力，對於程序員來講，能把產品經理（甲方）的需求理解到位，能把本身的技術方案講給小夥伴聽並確保他們理解的沒有大誤差就足夠了。關於正確理解需求，個人作法是先認真的聽並提問，等以爲本身消化之後就拉上產品經理給她講，進行驗證。

    二、學習一種建模語言

    好比uml，學習掌握後，和產品經理和技術小夥伴，不論是溝通需求仍是講解設計方案，都會效率高不少，你們不都說「一圖勝千言」嗎。

    三、像系統開發的程序員那樣持續學習

    （1）拓寬寫本身的視野

    瞭解些業內出現和發展的技術，沒準何時你就用上了，即便用不上但瞭解一下沒壞處。好比微服務、大數據、AI、區塊鏈等等，一些大媽都能談的頭頭是道，咱們做爲個技術人瞭解一下真的不爲過，千萬不要像有個候選人說出來「微服務？微信的服務」這樣的話。有些問題不必定是要問你掌握多深，而是要看你做爲一名程序員還有沒有保持好奇心，保持對技術的敏感度，而不是守着老本一吃到底。

    若是你認爲本身的好奇心足夠並且自我驅動的能力也很強，能夠忽略後面這段。若是自我驅動的能力弱些，我建議你經過考個「系統分析師」或者「系統架構師」的證書，來督促本身學習，這個證書不但有現實的意義（好比落戶等），並且學習的過程會讓你收穫並養成一些習慣。 

  （2）瞭解些實現細節

    這個感悟，來自於本身看了《Redis設計與實現》這本書。我在前東家工做的時候，有個「病歷同步」的功能遇到了好多問題，若是當時能瞭解redis中多機數據庫的實現細節，確定會走很多彎路。

    最後，總結一下，若是你和我同樣，是業務線的程序員，千萬不能只知足於完成眼前的工做，要擁抱變化面對將來。

 

參考：

混IT，必須理解「甲方乙方」