50多歲的程序員不合群、寫防御性代碼，能力再好又能怎樣？

是不是年紀大一些的程序員都喜歡寫防御性代碼？我已經見過好幾個了，基本上都是40歲以上的程序員，但是，我以前見到的，基本上都是在代碼里面埋坑但是不說的，這回我們公司這個年紀超過50歲的程序員不光脾氣不好，還把防御性代碼擺在了明面上！需要說明的事，接下來我所說的事情僅僅只是我所遇到的情況，不代表廣大大齡程序員。

我們公司有個50多歲的程序員，下面就叫他老常吧，說起來，老常還是我招聘進來的，當初面試老常的時候，我就知道他不是個好說話的人，再加上年紀大了，所以我有些猶豫。

但是，本著只要能干活，其他無所謂的心態，面試完老常后，我還是在老常的簡歷上寫了一個“OK”，并標明“可能有點難溝通”。

當時我們公司也缺人，尤其是老常是專門寫運動控制模塊的，這部分本來人才就少，碰到老常這種幾十年工作經驗的，我和老板也比較謹慎，生怕因為年齡歧視導致流失了一個人才。

事實證明，我們的選擇是沒有錯的，老常的工作效率和在運動控制這塊的經驗真是無人能比，基本上專業知識信手拈來，幾乎碰到任何問題不管是軟件上的還是硬件上的，都能輕松找到問題點并且解決。

總之，說老常是個運動控制方面的專家，也一點不為過。

但是，很快問題就出現了，我們發現，老常在分工協作方面顯得非常霸道，基本上團隊所有人都得按照他的思路來，只要有人沒有按照他的思路來，老常就會和那個人爭得面紅耳赤。

慢慢地，大家為了不和老常產生沖突，和老常討論問題的時候總是會觀察老常的情緒，只要老常表現出一點不耐煩的意思，就只能妥協，按照老常的方法來。

其實，這種情況，對于團隊管理來說，其實是不對的，雖然老常可能是運動控制方面的專家，但是也僅限于運動控制，像其他方面，比如說系統架構、機器視覺、用戶體驗方面考慮得還是不如團隊中的一些其他人的。

更讓人難以接受的是，老常總擺出一副只要是他寫的代碼，其他人都接受不了的態度，意思就是，只要別人改了或者接手他的代碼，他就會直接告訴那個人，還不如讓那個人重新寫一套。

公司是不可能讓別人重構老常的代碼的，所以有一次有個新項目，軟件部分都是一樣的，只不過需要新增一些功能，但是老常在其他項目，所以公司就安排了一個另外一個同樣是做運動控制的程序員老胡，讓老常把代碼跟老胡好好講講，爭取讓老胡在老常的代碼基礎上去新增功能。

老胡興沖沖得去找老常，結果碰了一鼻子灰，老胡不管有什么問題，老常在旁邊一言不發，搞得老胡很尷尬，老胡也是40歲左右的人了，但是脾氣很好，見老常總是一副看不見他的樣子，只得自己悶頭去研究老常的代碼去了。

后來，這事后來老常自己表示，每個人的代碼思路都不一樣，他之所以不讓老胡在他的代碼基礎上改，就是覺得老胡的思路跟他不一樣，還不如重新寫一套。

道理雖然是這樣，但是這是一個團隊，總不能每個人只負責一套系統吧，不管系統出現任何需要增刪改的東西，都只能找當初寫的那個人負責？那萬一那個人離職了呢？

但是，老常就是不肯合作，最后公司也拿老常沒辦法，只能讓老胡自己去研究老常的代碼，雖然老胡最終把老常的代碼研究清楚了，但是卻花了幾倍的時間，可憋屈了！

而老常最大的問題就是防御性代碼太明顯了，最典型的例子就是他和一個機器視覺程序員合作的時候，有個場景，需要標定相機，按照機器視覺程序員的需求，需要老常將多個軸移動到指定位置，然后發送一個消息給機器視覺程序，機器視覺程序通過拍照，尋找標定物，然后得出標定物的位置，從而標定相機位置。

需要標定的位置總共有四個點，業務規則上，標定相機位置也是需要四個點的，用來標定物理距離，但是生產時只需要看兩個點的位置，就來糾正物理距離。

四個點的話，需要軸平行移動兩次，將四個點的坐標全部作為參數寫到標定函數里面去，最終得出相機的物理坐標，其實兩個也可以，但是會有些許誤差。

機器視覺程序員最開始使用的是兩點距離標定的，后來發現這個方法不行，就改成了四個點標定，但是老常不愿意動代碼了，每次標定相機物理距離的時候，老常的做法是先做兩點坐標標定，然后再手動移動到另外兩點上，再做一次兩點標定，最后將兩次的結果手動算出來，得出一個偏差值，寫到代碼里。

這么說可能大家不理解，簡單的說兩點標定做一次會有偏差，但是做兩次，將兩次的結果相減，會得出另外一個值，這個值就是做一次標定的偏差值。

這個值，是老常靠手動算出來的，并且選擇寫死在代碼里，而不是自動算出來的。

這就是典型的防御性代碼了，不管老常是不是這么想的，但是很顯然，只要這套系統離開了老常，那么誰也玩不動了！

結語

這幾個事情的發生，讓公司下定了要找人替代老常的決心，公司決定把希望寄托在老胡身上，并且，老常也感受到了。

在老常眼里，公司這就是“卸磨殺驢”，但是，從公司角度來說，一個人的能力再好，可不服從管理，不愿意別人碰自己的代碼，甚至犧牲用戶體驗，寫防御性代碼，這是公司接受不了的。