|
|
本文是從 Top 7 programmers bad habits 這篇文章翻譯而來。
1. -所有的程序都寫的很爛，除了我的。
我要告訴你一個壞消息，兄弟，所有的程序都寫的很爛，包括你的。無論你在上面花多少功夫，其他大多數程序員總是會認為你寫的代碼很爛、他們能寫出比你好10倍的程序。我在前幾篇文章里已經討論過了這個問題，你可以讀讀這篇文章和這篇文章，從中你可以理解我所說的所有的程序都寫的很爛究竟是什么意思。
如何糾正：不要挑剔別人的程序，有一天也許你的程序會被人放在聚光燈下挑剔。要保持客觀和專業的評論，不要輕易判斷。要謙虛，從周圍人哪里學習經驗，警戒自己不要寫出這么糟的程序。
2. -我幾秒鐘就能把它改好，不用走變更流程了。
homer-simpson-doh
抄捷徑充滿誘惑，每個人都想抄捷徑。有時候抄捷徑是必要的，但總的來說，抄捷徑是危險的，非常危險，應該避免這樣做。走捷徑也許會節省你數小時的時間，但如果走錯了，它可能會給你帶來數月的麻煩。
如何糾正：遇到需要慎重處理的事情時不要太過自信。讓其他人來復查你的所作所為。如果你計劃要走捷徑，請確保讓你的負責人知道這樣做的理由以及其中的風險。每次在走捷徑時最好都讓你的經理來確認實施成功，也就是“讓他給你擦屁股”。
3. -這是個幾分鐘就能搞定的事。
在我的家鄉Barcelona，那里的圣家族大教堂讓我非常的自豪，它的舉世聞名來自于它的美麗，也來自于它的建筑完工日期的規劃(它動工于1882年，目前仍未完工)，但這可能是因為他們沒有讓一個程序員去估計這個完工時間，否則的話，估計出的完工所需的時間很可能2周。
如何糾正：從一開始，你就必須嚴肅的認識到，對于一個有一定規模的軟件開發過程來說，進行精確的時間評估是不現實的，我們能做的只是猜測。同樣要記住的非常相似一點是，我們通常會發現有很多事情根本不能預見到它們會花去我們數倍于我們初始估計的時間，我通常的做法是把估計的時間乘上1.5或2。
4. -唯我獨尊
很多程序員參與的討論會基本上看起來就像是一場斗雞，而不像是人類的討論，這通常會出現在關于設計和架構問題的討論會上。你基本上很容易看出其中各自都懷有順我者昌逆我者亡的心態，你基本上可以把大多數的爭論者所說的話直接換成咕咕！咕咕嘎！咕咕咕咕咕咕！咕咕嘎！
如何糾正：把你的自負留在心底。太過自負是所有程序員身上的一個非技術性的最大的一個毛病。凡事要三思而行。
5. -這不是我的錯！
在我看來，這另外一個大多數程序員都會有的壞毛病是缺乏責任心。我們總在找借口…就比如有人會說，如果在正常情況下，這個錯誤絕對不會出現，但說老實話，這很難讓人信服。
如何糾正：犯了錯誤不需要去捶胸頓足，也不需要用刨腹自殺來謝罪。我們應該懷有一種健康的態度，說出這樣的話：“呀，抱歉，我們現在就去改正這個錯誤，是我的錯”，這是一種很敬業的態度，這能幫助我們樹立一個好的聲譽，更好的得到你的同事的尊重。
6. -沒有激情
重復的和簡單的任務通常不會帶來什么動力，但這些事必須要完成，當程序員被要求去完成這些事情時，通常會顯得無精打采，沒有效率。
如何糾正：紀律問題。很不幸，我再也想不出其它的治療這種毛病的良方。
7. -不成熟
如果說把對計算機編程當作做愛，那很少有計算機能得到滿足。你根本就沒有潛心投入，干到一半就結束了，然后倒頭便睡。我發現大多數程序員對“干完”這個詞很糾結。請記住，干完意味著：測試過(不僅僅只是單元測試)，文檔完整，提交過，合并過…
如何糾正：這是一個很麻煩的問題，相對于完全的完成某些功能性問題而言，這些并不是顯得很有必要的任務會很龐雜和難處理，通常需要你有紀律性和受過培訓。也許，這最簡單的能讓一個程序員理解他的開發是否真正的完成的兩個辦法就是：相互復查和演示。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
