每個程序員都有自己煩惱的事。不論這事指的是范圍蠕變(scope creep),還是 指匈牙利變量命名 (Hungarian notation),還是有臭味的同事,我們都明白,這是我們有我們行業里的特定的煩惱。 下面要說的就是十大讓程序員們煩惱的事情,這是我從最 近的在StackOverflow上的一個調查里整理出來的,并且摻雜了一些我個人的經驗:
10. 注釋 — 只解釋了“how”卻沒有解釋“why”
入門級的編程課程通常會教育學生們寫代碼前先寫注釋、而且要盡量多注釋。 這種教育的出發點是“多注釋肯定比少注釋好、少注釋肯定比沒注釋好”。 可不幸的是,很多的程序員把這當成了一種任務,對每一行代碼都注釋一下。 這就是為什么會經??吹较馢eff Atwood在他的博客文章Coding Without Comments提到的代碼:
1 r = n / 2; // 讓 r 等于 n 除以 2
2
3 // 當 r - (n/r) 大于 t 時進行循環
4 while ( abs( r - (n/r) ) > t ) {
5 r = 0.5 * ( r + (n/r) ); // 設置 r 等于 r + (n/r) 的一半
6 }
經過這樣的注釋,你否明白了這段代碼是干什么的?的確,我也沒明白。 問題就在于,雖然有大量的注釋,可它們只是描述了代碼是干什么了,卻沒有說明代碼為什么要這樣寫。
現在,請看一下我們采用另外一種方式對同一段代碼進行的注釋:
1 // 使用牛頓-Raphson算法求n的平方根近似值
2 r = n / 2;
3
4 while ( abs( r - (n/r) ) > t ) {
5 r = 0.5 * ( r + (n/r) );
6 }
這就好多了!也許我們還是不能完全明白這段代碼的作用,但至少是有了一點方向了。
注釋是用來幫助讀者理解代碼的,不是用來解釋語法的。 我可以大膽的認為,讀者對for循環的工作原理是了解的;所以沒必要寫這樣的注釋:“// 對客戶列表進行for循環操作”。 讀者不明白的是你的代碼是做什么用的,你為什么要采用這種方式實現它。
9. 干擾
很少有程序員能在眨眼之間從一種活動中轉換到編程的狀態中。通常情況下,我們更類似于需要慢慢啟動的火車,而不是能突然加速的 法拉利; 我們需要一定的時間才能進入工作狀態,一旦我們進入穩定有效的工作狀態,我們的工作效果和產出會很豐碩。 不幸的是,當思路不斷的被客戶、經理、以及你的同事打斷時,你的大腦很難進入編程的狀態。
當我們干一件事情時,有太多的瑣事需要我們放在心里,我們需要先放下這個事情,處理那個人事情,回頭又干這個事情,還不能有差錯。這些干擾會中 斷我們的思路,而重新整理清楚思路又要你花費大量的時間,這是讓人懊惱的、沒有比這更讓人泄氣、讓人有挫折感的過程了。
8. 范圍蠕變(Scope creep)
來自 Wikipedia 的解釋:
范圍蠕變(Scope creep) (也稱作焦點蠕變(focus creep), 需求蠕變(requirement creep), 功能蠕變(feature creep),以及其它一些亂七八糟的演變詞語),指在項目管理里項目的需求變更失控。 當一個項目的范圍沒有明確的定義清楚、沒有文檔化、不受控時就會出現這種現象。 這通常被認為是一種有負面影響的事情,應該盡力避免。
范圍蠕變通常會把一個簡單的需求變成一個復雜驚人的需要大量時間的巨無霸。 那些負責需求調研的家伙們只需要敲幾下無辜的鍵盤就能把事情變成這樣:
版本 1: 顯示這個地區的地圖
版本 2: 顯示這個地區的地圖,要三維立體的
版本 3: 顯示這個地區的地圖,要三維立體的,而且能夠使用它作為飛行導航圖
暈倒!一個本來30分鐘能完成的任務變成了一項要幾百人/天才能完成的超級復雜的系統。更糟糕的是,大多數情況下,需求變更是發生在開發階段 的,這樣一來你需要重寫代碼,重新回歸,有時要把前幾天才開發的代碼刪除。
7. 管理者 — 完全不懂編程
管理工作不是一種簡單的工作。人是一種讓人很討厭的動物; 我們善變、喜怒無常,我們都自以為天下第一。 想讓這樣的一群人都感到滿意和團結,你需要付出像山一樣大的努力。 然而,這并不意味著管理者就可以在對下屬的工作毫不理解的情況下進行管理。 當管理者對我們的工作沒有一點知識概念時,后果只會是需求頻繁變動,不現實的工期,普遍的挫折感(管理者和開發人員)。 程序員們對此的抱怨相當普遍,這也是產生爭執不合的根源(就像一個歡鬧的卡 通片).
原文轉自:http://www.vaikan.com/top-10-things-that-annoy-programmers/