[分享]解析「程序員的十大技術煩惱」

每一個程序員都會因遇到各類各樣的問題，有時這些問題就是煩惱。本文總結了一些讓程序員的煩心事兒，在Coding時你是否也遇到過這些煩惱？今天咱們來看看程序員的煩惱。每一個程序員都有本身煩心事，不論這事指的是範圍蠕變（scope creep），仍是指匈牙利變量命名 （Hungarian notation），咱們都明白，這是咱們有咱們行業裏的特定的煩惱。 下面要說的就是讓程序員們煩惱的十件事情。

10. 註釋 — 只解釋了「how」卻沒有解釋「why」

入門級的編程課程一般會教育學生們寫代碼前先寫註釋、並且要儘可能多註釋。 這種教育的出發點是「多註釋確定比少註釋好、少註釋確定比沒註釋好」。可不幸的是，不少的程序員把這當成了一種任務，對每一行代碼都註釋一下。

r = n / 2; // 讓 r 等於 n 除以 2

// 當 r - (n/r) 大於 t 時進行循環
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // 設置 r 等於 r + (n/r) 的一半
}

通過這樣的註釋，你否明白了這段代碼是幹什麼的？的確，我也沒明白。 問題就在於，雖然有大量的註釋，可它們只是描述了代碼是幹什麼了，卻沒有說明代碼爲何要這樣寫。

如今，請看一下咱們採用另一種方式對同一段代碼進行的註釋:

// 使用牛頓-Raphson算法求n的平方根近似值

r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}

這就好多了！也許咱們仍是不能徹底明白這段代碼的做用，但至少是有了一點方向了。

註釋是用來幫助讀者理解代碼的，不是用來解釋語法的。 我能夠大膽的認爲，讀者對for循環的工做原理是瞭解的；因此不必寫這樣的註釋：「// 對客戶列表進行for循環操做」。讀者不明白的是你的代碼是作什麼用的，你爲何要採用這種方式實現它。

9. 干擾

很 少有程序員能在眨眼之間從一種活動中轉換到編程的狀態中。一般狀況下，咱們更相似於須要慢慢啓動的火車，而不是能忽然加速的 法拉利; 咱們須要必定的時間才能進入工做狀態，一旦咱們進入穩定有效的工做狀態，咱們的工做效果和產出會很豐碩。 不幸的是，當思路不斷的被客戶、經理、以及你的同事打斷時，你的大腦很難進入編程的狀態。

當咱們幹一件事情時，有太多的雜事須要咱們放在內心，咱們須要先放下這個事情，處理那我的事情，回頭又幹這個事情，還不能有差錯。這些干擾會中 斷咱們的思路，而從新整理清楚思路又要你花費大量的時間，這是讓人懊惱的、沒有比這更讓人泄氣、讓人有挫折感的過程了。

8. 範圍蠕變（Scope creep）

範 圍蠕變（Scope creep） (也稱做焦點蠕變（focus creep）， 需求蠕變（requirement creep）, 功能蠕變（feature creep），以及其它一些亂七八糟的演變詞語)，指在項目管理裏項目的需求變動失控。 當一個項目的範圍沒有明確的定義清楚、沒有文檔化、不受控時就會出現這種現象。 這一般被認爲是一種有負面影響的事情，應該盡力避免。

範圍蠕變一般會把一個簡單的需求變成一個複雜驚人的須要大量時間的巨無霸。 那些負責需求調研的傢伙們只須要敲幾下無辜的鍵盤就能把事情變成這樣：

◆版本 1: 顯示這個地區的地圖

◆版本 2: 顯示這個地區的地圖，要三維立體的

◆版本 3: 顯示這個地區的地圖，要三維立體的，並且可以使用它做爲飛行導航圖

一個原本30分鐘能完成的任務變成了一項要幾百人/天才能完成的超級複雜的系統。更糟糕的是，大多數狀況下，需求變動是發生在開發階段 的，這樣一來你須要重寫代碼，從新迴歸，有時要把前幾天纔開發的代碼刪除。

7. 管理者 — 徹底不懂編程

管 理工做不是一種簡單的工做。人是一種讓人很討厭的動物; 咱們善變、喜怒無常，咱們都自覺得天下第一。想讓這樣的一羣人都感到滿意和團結，你須要付出像山同樣大的努力。 然而，這並不意味着管理者就能夠在對下屬的工做絕不理解的狀況下進行管理。 當管理者對咱們的工做沒有一點知識概念時，後果只會是需求頻繁變更，不現實的工期，廣泛的挫折感（管理者和開發人員）。程序員們對此的抱怨至關廣泛，這也 是產生爭執不合的根源。

6. 寫文檔

在說這個條目以前我先認可，咱們確實有不少的文檔生成工具，但據個人經驗，這些工具都是隻適合生成API文檔，以供其餘程序員參考。若是你開發 的軟件是平時人們天天都要用的，你必需要寫一些外行人(例如你的實施，客服等)都能理解的文檔手冊。

咱們能夠很容易的看出，有些事情程序員們極不肯意去作。 你能夠簡單的回顧一下全部的開源項目。 人們百折不撓的對這些項目的一個索求是什麼：文檔。
我敢打保票的說，無論在哪裏，至少會有一半的程序員當要求寫文檔時會說：「不能讓其餘人去寫嗎？「。

5. 程序 — 缺乏文檔

我可歷來沒說過咱們程序員是說一套作一套的人。 程序員們常常會在他們的項目裏用到第三方的類庫和應用。 因而，咱們須要文檔。 很不幸呀，就像我在第6條裏說的那樣，程序員們痛恨寫文檔。這戲劇性的事情發生在咱們本身身上。

當 你須要使用一個第三方類庫時發現，至少有一半的API無從知道是幹什麼好用的，沒有任何事情比這個更打擊人的了。 函數 poorlyNamedFunctionA() 和函數 poorlyButSimilarlyNamedFunctionB() 有什麼區別？ 在我使用 PropertyX 屬性前是否須要測試一下它是否是 null 值？我估計只有經過本身的測試和報錯才能弄清楚!。

4. 硬件

任 何一個曾經被叫去調試一個數據庫服務器上奇怪的宕機現象，或是被叫去解決RAID驅動器不能正確的工做的問題的程序員，當發現是硬件問題時， 都會痛苦不已。 人們有一種廣泛的誤解，認爲程序員就是搞電腦的，他們確定知道如何修理電腦。 不能否認，有些程序員確實是個全才，但我估計，絕大部分程序員都不知道，或者根本不關心當程序被編譯成機器碼後如何工做的。咱們只關心作出來的東西是否符 合需求文檔，這樣咱們才能集中精力去解決這上層的任務。

3. 含糊不清

「網站宕機了」. 「XX功能工做不正常」。 處理含糊不清的任務是種痛苦。 每次當非程序員被要求重現他們所遇到的問題時表現出的憤怒都讓我吃驚不已。 他們彷佛不太明白，僅僅一句」它宕機了，修復它！」是沒法讓咱們開始工做的，咱們須要更多的信息。

軟件的運行是(大部分狀況下)有跡可尋的。咱們也樂見與此。 請遷就咱們，幫咱們指出是在哪一個階段，什麼狀況下出的問題，而不是簡單的說一句」修復它「。

2. 其餘程序員

程序員常常和其餘程序員合不來。詫異嗎，但這是真的。 這方面的事情我能夠輕鬆的列出十大條，講細點甚至能夠單獨寫篇博客，因此這裏我只列出幾個常見的、讓其餘同事感到懊惱的程序員的特徵：

◆脾氣暴躁以致態度極不友好。

◆不能明白何時該去討論系統的架構，何時是應該去動手去作。

◆沒法進行有效的溝通，使用易於誤解的專業術語。

◆本身的事情處理很差。

◆對要作的程序和項目缺少興趣。

那麼，這最後的，但不是最糟糕的，序號爲1的讓程序員們煩惱的…

1. 本身寫的代碼 — 6個月之後的

Don’t sneeze, I think I see a bug.

回顧一下本身之前寫的代碼，是否也會愁眉苦臉？當時怎麼會這麼愚蠢！怎麼能編寫成這樣的東西！燒掉!丟到火裏！

現 實是，軟件技術界是一個不斷變化的世界。 今天被當作是最好的方式，明天也許就會過期。 咱們不可能寫出完美的代碼，由於判斷咱們的程序好壞的標準突飛猛進。 這使人很不爽，你的做品，今天看來是那麼的完美，但也許不久以後就會變成被人嘲笑的對象了。 真是讓人沮喪，由於不論咱們如何努力的學習最新最棒的開發工具，設計，框架，以及開發方法，咱們老是比最新的技術發展趨勢慢了一拍。 對於我來講，這是作一個程序員最苦惱的事情了。咱們不斷的升級技術，是爲了讓軟件更好，但卻禁不住感到，我就像一個作沙毯（sand-painting） 的和尚。

http://www.chinae8.net/cn/cpzx/info_4.aspx?subnavID=126