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