惹惱程序員的十件事[1]

程序員是一個比較特殊的羣體，他們因爲長期和電腦打交道所養成的性格和脾氣也是比較相近的。當然，既然是人，當然是會有性格的，也是會有脾氣的。下面，讓我來看看十件能把程序惹毛了的事情。一方面我們可以看看程序員的共性，另一方面我們也可以看看程序員的缺點。無論怎麼樣，我都希望他們對你的日常工作都是一種幫助。

第十位 程序註釋

程序註釋本來是一些比較好的習慣，當程序員老手帶新手的時候，總是會告訴新手，一定要寫程序註釋。於是，新手們當然會聽從老手的吩咐。只不過，他們可能對程序註釋有些誤解，於是，我們經常在程序中看到一些如下的註釋：

r = n/2; //r是n的一半
//循環，僅當r- n/r不大於t
while （（r-n/r） <=t）{
… …
r = 0.5 * （r-n/r）; // 設定r變量
}

每當看到這樣的註釋——只註釋是什麼，而不註釋爲什麼，相信你一定會被惹火，這是誰寫的程序註釋啊？不找來罵一頓看來是不會解氣了。程序註釋應該是告訴別人你的意圖和想法，而不是告訴別人程序的語法，這是爲了程序的易讀性和可維護性，這樣的爲了註釋而註釋的註釋，分明不是在註釋，而是在挑釁，惹毛別人當然毋庸置疑。

第九位 打斷

正當程序沉浸於編程算法的思考，或是靈感突現正在書寫程序的時候，但卻遭到別人的打斷，那是一件非常痛苦的事情，如果被持續打斷，那可能會讓人一下子就煩躁起來。打斷別人的人在這種情況下是非常不禮貌的。被打斷的人就像函數調用一下，當其返回時，需要重新恢復斷點時的現場，當然，人不是電腦，恢復現場通常是一個很痛苦的過程，極端的情況下可能需要從頭開始尋找思緒，然後一點一點地回到斷點。

因此，我看到一些程序員在需要安靜不被打擾的時候，要麼會選擇去一個沒人找得到的地方，要麼會在自己的桌子上方高掛一個條幅以示衆人——“本人正執行內核程序，無法中斷，請勿騷擾，謝謝！”，可能正在沉浸於工作的程序被打斷是多麼大的開銷。自然，被打斷所惹毛了的人也不在少數了。

第八位 需求變化

這個事情估計不用多說了。只要是是程序員，面對需求變化的時候可能總是很無奈的。一次兩次可能還要吧接受，但也頂不住經常變啊。據說敏捷開發中有一套方法論可以讓程序員們享受需求的變化，不知道是真是假。不過，今天讓你做一個書桌，沒有讓你把書桌改成餐桌，後天讓你把餐桌改成雙人牀，大後天讓你把牀改成小木屋，然後把小木屋再改成高樓大廈。哎，是人都會被惹毛了的。那些人只用30分鐘的會議就可以作出任何決定，但後面那幾十個程序員需要搭上幾百個小時的辛苦工作。如果是我，可能我也需要神獸草泥馬幫助解解氣了。

不過，這也正說明了，程序員並不懂得怎麼和用戶溝通，而用戶也不懂得和程序員溝通，如果一個項目沒有一箇中間人（如：PM）在其中協調的話，那麼整個項目可能就是“雞同鴨講”，用戶和程序員都會被對方所惹毛了。如果要例舉幾個用戶被惹毛的事情，估計程序員的那種一根筋的只從技術實現上思考問題的方法應該也能排進前5名。

第七位 經理不懂技術

外行領導內行的事例還少嗎？領導一句話，無論對不對，都是對的，我們必需照做，那怕是多麼愚蠢多麼錯誤的決定，我們也得照做。程序員其實並不怕經理不懂技術，最怕的就是不懂技術的經理裝着很懂技術。最可氣的是，當你據理力爭的挑站領導權威的時候，領導還把你視爲異類。哎，想起這樣的領導別說是罵人了，打人的衝動都有了。

其實，經理只不過是一個團隊的.支援者，他應該幫助團隊，爲團隊排憂解難。而不是對團隊發號施令。其實管理真的很簡單，如果懂的話，就幫着做，如果不懂的話，就相信下屬，放手讓下屬做。最怕的就是又不懂技術，還不信任下屬的經理了。哎，這真是程序員的痛啊。

第六位 用戶文檔

用戶文檔本來不應該那麼的令人害怕。這些文檔記錄了一切和我們所開發的軟件有關的一些話題。因爲我們並不知道我們所面對的用戶的電腦操作基礎是什麼樣的，所以，在寫下這樣的文檔的時候，我們必需假設這個用戶什麼也不懂。於是，需要用最清楚，最漂亮的語言寫下一個最豐富的文檔。那怕一個拷貝粘貼的操作，可能我們都要分成五、六步來完成，那怕是一個配置IP位址的操作，我們也要從開始選單開始一步一步的描述。對於程序員來說，他們在開發過程中幾乎天天都在使用自己開發的軟件，到最後，可能都有得有點吐了，但還得從最簡單的部份寫這些文檔，當然容易令他們煩燥，讓程序員來完成這樣的文檔可能效果會非常不好。所以，對於這樣的用戶文檔，應該由專門的人來完成和維護。