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