|
|
每個程序員都有自己煩惱的事。不論這事指的是范圍蠕變（scope creep），還是指匈牙利變量命名（Hungarian notation），還是有臭味的同事，我們都明白，這是我們有我們行業(yè)里的特定的煩惱。下面要說的就是十大讓程序員們煩惱的事情，這是我從最近的在StackOverflow上的一個調(diào)查里整理出來的，并且摻雜了一些我個人的經(jīng)驗：
10. 注釋 — 只解釋了“how”卻沒有解釋“why”
入門級的編程課程通常會教育學生們寫代碼前先寫注釋、而且要盡量多注釋。這種教育的出發(fā)點是“多注釋肯定比少注釋好、少注釋肯定比沒注釋好”。可不幸的是，很多的程序員把這當成了一種任務，對每一行代碼都注釋一下。這就是為什么會經(jīng)常看到像Jeff Atwood在他的博客文章Coding Without Comments提到的代碼：
r = n / 2;// 讓 r 等于 n 除以 2
// 當 r - (n/r) 大于 t 時進行循環(huán)
while( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );// 設置 r 等于 r + (n/r) 的一半
}
經(jīng)過這樣的注釋，你否明白了這段代碼是干什么的？的確，我也沒明白。問題就在于，雖然有大量的注釋，可它們只是描述了代碼是干什么了，卻沒有說明代碼為什么要這樣寫。
現(xiàn)在，請看一下我們采用另外一種方式對同一段代碼進行的注釋:
// 使用牛頓-Raphson算法求n的平方根近似值
r = n / 2;
while( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
這就好多了！也許我們還是不能完全明白這段代碼的作用，但至少是有了一點方向了。
注釋是用來幫助讀者理解代碼的，不是用來解釋語法的。我可以大膽的認為，讀者對for循環(huán)的工作原理是了解的；所以沒必要寫這樣的注釋：“// 對客戶列表進行for循環(huán)操作”。讀者不明白的是你的代碼是做什么用的，你為什么要采用這種方式實現(xiàn)它。
9. 干擾
很少有程序員能在眨眼之間從一種活動中轉(zhuǎn)換到編程的狀態(tài)中。通常情況下，我們更類似于需要慢慢啟動的火車，而不是能突然加速的法拉利；我們需要一定的時間才能進入工作狀態(tài)，一旦我們進入穩(wěn)定有效的工作狀態(tài)，我們的工作效果和產(chǎn)出會很豐碩。 不幸的是，當思路不斷的被客戶、經(jīng)理、以及你的同事打斷時，你的大腦很難進入編程的狀態(tài)。
當我們干一件事情時，有太多的瑣事需要我們放在心里，我們需要先放下這個事情，處理那個人事情，回頭又干這個事情，還不能有差錯。這些干擾會中斷我們的思路，而重新整理清楚思路又要你花費大量的時間，這是讓人懊惱的、沒有比這更讓人泄氣、讓人有挫折感的過程了。
8. 范圍蠕變（Scope creep）
來自 Wikipedia 的解釋：
范圍蠕變（Scope creep） (也稱作焦點蠕變（focus creep），需求蠕變（requirement creep）,功能蠕變（featurecreep），以及其它一些亂七八糟的演變詞語)，指在項目管理里項目的需求變更失控。當一個項目的范圍沒有明確的定義清楚、沒有文檔化、不受控時就會出現(xiàn)這種現(xiàn)象。 這通常被認為是一種有負面影響的事情，應該盡力避免。
范圍蠕變通常會把一個簡單的需求變成一個復雜驚人的需要大量時間的巨無霸。那些負責需求調(diào)研的家伙們只需要敲幾下無辜的鍵盤就能把事情變成這樣：
- 版本 1: 顯示這個地區(qū)的地圖
- 版本 2: 顯示這個地區(qū)的地圖，要三維立體的
- 版本 3: 顯示這個地區(qū)的地圖，要三維立體的，而且能夠使用它作為飛行導航圖
暈倒！一個本來30分鐘能完成的任務變成了一項要幾百人/天才能完成的超級復雜的系統(tǒng)。更糟糕的是，大多數(shù)情況下，需求變更是發(fā)生在開發(fā)階段的，這樣一來你需要重寫代碼，重新回歸，有時要把前幾天才開發(fā)的代碼刪除。
7. 管理者 — 完全不懂編程
管理工作不是一種簡單的工作。人是一種讓人很討厭的動物；我們善變、喜怒無常，我們都自以為天下第一。想讓這樣的一群人都感到滿意和團結，你需要付出像山一樣大的努力。然而，這并不意味著管理者就可以在對下屬的工作毫不理解的情況下進行管理。當管理者對我們的工作沒有一點知識概念時，后果只會是需求頻繁變動，不現(xiàn)實的工期，普遍的挫折感（管理者和開發(fā)人員）。程序員們對此的抱怨相當普遍，這也是產(chǎn)生爭執(zhí)不合的根源(就像一個歡鬧的卡通片).
6. 寫文檔
在說這個條目之前我先承認，我們確實有很多的文檔生成工具，但據(jù)我的經(jīng)驗，這些工具都是只適合生成API文檔，以供其他程序員參考。如果你開發(fā)的軟件是平時人們每天都要用的，你必須要寫一些外行人(例如你的實施，客服等)都能理解的文檔手冊。
我們可以很容易的看出，有些事情程序員們極不愿意去做。你可以簡單的回顧一下所有的開源項目。人們百折不撓的對這些項目的一個索求是什么：文檔。
我敢打保票的說，不管在哪里，至少會有一半的程序員當要求寫文檔時會說：“不能讓其他人去寫嗎？“。
5. 程序 — 缺少文檔
我可從來沒說過我們程序員是說一套做一套的人。程序員們經(jīng)常會在他們的項目里用到第三方的類庫和應用。于是，我們需要文檔。很不幸呀，就像我在第6條里說的那樣，程序員們痛恨寫文檔。這戲劇性的事情發(fā)生在我們自己身上。
當你需要使用一個第三方類庫時發(fā)現(xiàn)，至少有一半的API無從知道是干什么用的，沒有任何事情比這個更打擊人的了。函數(shù)poorlyNamedFunctionA()和函數(shù)poorlyButSimilarlyNamedFunctionB()有什么區(qū)別？在我使用 PropertyX 屬性前是否需要測試一下它是不是 null 值？我估計只有通過自己的測試和報錯才能弄清楚!可惡。
4. 硬件
任何一個曾經(jīng)被叫去調(diào)試一個數(shù)據(jù)庫服務器上奇怪的宕機現(xiàn)象，或是被叫去解決RAID驅(qū)動器不能正確的工作的問題的程序員，當發(fā)現(xiàn)是硬件問題時，都會痛苦不已。人們有一種普遍的誤解，認為程序員就是搞電腦的，他們肯定知道如何修理電腦。不可否認，有些程序員確實是個全才，但我估計，絕大部分程序員都不知道，或者根本不關心當程序被編譯成機器碼后如何工作的。我們只關心做出來的東西是否符合需求文檔，這樣我們才能集中精力去解決這上層的任務。
3. 含糊不清
“網(wǎng)站宕機了”. “XX功能工作不正常”。 處理含糊不清的任務是種痛苦。 每次當非程序員被要求重現(xiàn)他們所遇到的問題時表現(xiàn)出的憤怒都讓我吃驚不已。他們似乎不太明白，僅僅一句”它宕機了，修復它！”是無法讓我們開始工作的，我們需要更多的信息。
軟件的運行是(大部分情況下)有跡可尋的。我們也樂見與此。請遷就我們，幫我們指出是在哪個階段，什么情況下出的問題，而不是簡單的說一句”修復它“。
2. 其他程序員
程序員經(jīng)常和其他程序員合不來。詫異嗎，但這是真的。這方面的事情我可以輕松的列出十大條，講細點甚至可以單獨寫篇博客，所以這里我只列出幾個常見的、讓其他同事感到懊惱的程序員的特征：
- 脾氣暴躁以至態(tài)度極不友好。
- 不能明白什么時候該去討論系統(tǒng)的架構，什么時候是應該去動手去做。
- 無法進行有效的溝通，使用易于誤解的專業(yè)術語。
- 自己的事情處理不好。
- 對要做的程序和項目缺乏興趣。
那么，這最后的，但不是最糟糕的，序號為1的讓程序員們煩惱的…
1. 自己寫的代碼 — 6個月以后的
Don’t sneeze, I think I see a bug.
回顧一下自己以前寫的代碼，是否也會愁眉苦臉？當時怎么會這么愚蠢！怎么能編寫成這樣的東西！燒掉!丟到火里！
哈，好消息。你并不孤單。
現(xiàn)實是，軟件技術界是一個不斷變化的世界。今天被看成是最好的方式，明天也許就會過時。我們不可能寫出完美的代碼，因為判斷我們的程序好壞的標準日新月異。這令人很不爽，你的作品，今天看來是那么的完美，但也許不久之后就會變成被人嘲笑的對象了。真是讓人沮喪，因為不論我們?nèi)绾闻Φ膶W習最新最棒的開發(fā)工具，設計，框架，以及開發(fā)方法，我們總是比最新的技術發(fā)展趨勢慢了一拍。對于我來說，這是做一個程序員最苦惱的事情了。我們不斷的升級技術，是為了讓軟件更好，但卻禁不住感到，我就像一個做沙毯（sand-painting）的和尚。
好了，全都給寫出來了。這十大讓程序員煩惱的事情。依舊，如果你覺得我的文章里有什么疏漏的地方，請讓我知道，歡迎留下評論！
it知識庫：程序員的十大煩惱，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
