本文轉載自開源中國，譯文鏈接：Click Me
10. 註釋說明“是什麼”，而不是“爲什麼”
入門級編程課程教導學生要學會頻繁且儘早地註釋。不可否認在學習編程的起步階段這方法的確是相當有效的（即使看到最簡單的代碼行都像天書）。然而許多程序員即使已經從一隻小菜鳥長大成一位計算機牛人，也還是把這個習慣給延續了下來。
r = n / 2; // Set r to n divided by 2
// Loop while r – (n/r) is greater than t
while (abs ( r – (n/r) ) > t) {
r = 0.5 * ( r + (n/r) );
// Set r to half of r + (n/r) }看明白上面的代碼是啥意思沒？
四個字：雲裏霧裏。
上述問題就是，雖然有很多註釋，但是卻沒有說明爲什麼要寫這些代碼。下面將上述相同的代碼換用另一種註釋，那效果就大大不同了。
// square root of n with Newton-Raphson approximation
r = n / 2;
while ( abs ( r – (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}是不是好多了！雖然我們還是沒有完全理解這段代碼是什麼意思，但是至少我們精簡了代碼，清爽多了。
寫註釋是爲了幫助讀者理解代碼。這裏假設，所有閱讀代碼的人都已經對 for 循環如何運行有了基本的瞭解。他們可能不清楚的是，你的代碼如何奏效或者你爲什麼選擇這條路徑來實現。
9. 各種打攪
在大多數情況下，程序員的思緒比起法拉利更像是火車，需要慢慢啓動，也就是說我們得醞釀一下才能進入狀態。但是一旦我們全身心投入的時候，就會高效完成很多令人嘖嘖稱讚的代碼。只是很不幸的是，這是很難達到的境界，因爲我們的思路總是不斷受到客戶和同事的打攪。
8. 範圍蔓延
維基百科將範圍蔓延定義爲“在項目範圍內不受控制的變化”。範圍蔓延會使得一個相對簡單的請求延伸成一個極爲複雜和耗時的任務。它就是運用一些看似方便無害的要求蔓延範圍，一步一步破壞項目的時間表：
-
版本1：顯示所在位置的地圖
-
版本2：顯示所在位置的三維地圖
-
版本3：顯示所在位置的三維地圖，精確到可以作爲飛行導航
7. 管理層不懂編程
當然，也會有例外，此點標題僅爲個人遭遇，如有雷同，純屬巧合。
首先我們要承認，管理不是個簡單活。下屬會討厭你：他們脆弱的內心有時也會受傷。並且要保持一大羣人的團結和凝聚力幾乎就像是座山一樣的任務。然 而，任務艱鉅並不意味着管理者能不對他們的下屬有一個基本的瞭解。當管理層無法把握工作理念，就會使員工出現範圍蔓延，超出完成期限，感到挫折心情沮喪等 等狀況。這是很多程序員在日常工作中經常抱怨和焦慮的根本原因。
6. 寫文檔
沒錯，的確有很多文檔生成工具，但我的經驗告訴我，這些工具都是隻適合生成 API 文檔，以供其他程序員參考。如果你開發的軟件是很多人在日常生活中都會用到的，那麼你最好寫一些即使外行人也能理解的文檔（例如，應用程序如何工作、故障診斷指南等等）。
好吧，有些程序員可不樂意幹這事兒。大家經常做的是，快速瀏覽開源項目，然後開始不斷的搜尋文檔來獲取幫助。
我敢打保票的說，不管在哪裏，幾乎所有的程序員被要求寫文檔時，都會說：“不能讓其他人去寫嗎？”
5. 缺少文檔的程序
好吧，我從來沒有說過我們程序員是說一套做一套的人。程序員經常被要求在項目中用到第三方的類庫和應用。這使得我們不得不需要文檔。但是正如我在上面那條說的那樣，程序員痛恨寫文檔。真是個矛盾又糾結啊！
當我們需要使用一個第三方類庫是，卻不知道至少有一半的 API 有什麼用，沒有什麼比這個更讓人崩潰了。知道函數 poorlyNamedFunctionA ()和 poorlyButSimilarlyNamedFunctionB ()的區別不？當我訪問 PropertyX 時是不是需要先做一個 null 測試？如果缺少文檔，我估計我得通過自己的測試和錯誤報告才能知道結果，哦，my god！
4. 硬件（總是被當成修電腦的）
任何一個程序員要是被叫去調試數據庫服務器上一種奇怪的宕機現象，或者去解決 RAID 驅動器不能正常工作的問題，而最後發現卻是硬件的原因，orz 都會痛苦不已。話說，不知道哪裏來的誤解，人們竟然會以爲程序員這種整天搗鼓電腦的傢伙，肯定知道如何修電腦。好吧，有些程序員確實會修（大概是他們大學 時泡妹子修煉的技能？），但是，我敢打包票，大多數程序員是不知道的，或者對程序被編譯成機器碼後是如何工作的毫不關心。
我們關心什麼呢？我們關心的是我們做出來的東西是否符合需求，這樣我們才能集中精力去解決更高級別的任務。
3. 含糊不清
“哎呀，我的網站出問題了”、“XX 功能不正常”，這種指向性不明確的要求最痛苦了。我特別訝異的是，當我們要求那些非程序員重現問題時，他們竟然會憤怒不已。難道他們不知道，僅僅一句“電腦壞掉了，快點修復一下”，我們是沒辦法開始工作的，我們需要更多的信息。
軟件的運行，在大多數情況下，是有跡可循的。我們也喜歡這種方式。請遷就我們，幫助我們找出是在哪一步出現的問題，而不是簡單一句“修復”。
2. 與其他程序員的相處
程序員經常和其他程序員合不來。不要裝的很驚訝，內心早承認了吧，親愛的程序員們。關於這方面的事例我隨口就可以列出十大條，甚至可以另外單獨寫篇博客，所以在本文中我僅列出幾個之所以會和同事難以好好相處的常見原因：
-
脾氣暴躁，態度不友好。
-
不明白什麼時候該去討論系統的架構，什麼時候該開工。
-
無法進行有效的溝通，使用易於誤解的專業術語。
-
自己的事情處理不好。
-
對代碼庫和項目興致缺缺。
這還不是最糟糕的，還有個重量級的“程序員殺手”——No.1 在後面呢……
1. 6 個月後再看自己的代碼
別打噴嚏，我發現了一個 bug。
你有沒有回過頭去看看自己以前寫的代碼，有沒有情不自禁地捶胸頓足？有沒有在懊惱自己當初怎麼會這麼傻逼，寫出這種垃圾玩意！刪掉，刪掉，通通刪掉！
好吧，你可以開心一下，這種事並不單單發生在你身上。
我們的編程世界是在不斷變化的。今天或許是最棒的技術，明天搞不好就過時了。我們永遠寫不出完美的代碼，因爲評價的標準也在隨着時代的進步而不斷提高。無論我們寫出來的代碼現在看來是要多完美有多完美，但是很可能在不久之後就是被人嘲笑的對象了。
這的確讓人情不自禁的沮喪，因爲即使我們現在怎麼努力去學習最新最棒的開發工具、設計、框架，以及開發方法，我們總是比最新的技術發展趨勢慢了一 步。於我而言，這是作爲一個程序員最爲懊惱的事情了，沒有之一，所以我把這一條列爲 No.1。我們能做的就是不斷更新自己的技術，不過有時候，我卻會覺得我就像是個搞沙雕的，不斷推到重做，呵呵。
