分享成為高效程式設計師的7個重要習慣

　　作為軟體工程師，你希望從工作中獲得的是：穩定的薪水、參與好專案的機會、好工作的跳板或只是和其他程式師成為好基友。這裡的“高效”，我指的是按時完符合要求的專案的能力。經歷過不少軟體編寫工作後，我相信以下實踐會幫助你學會“高效”，同時提高專業聲望、拉長職業壽命，和獲得個人滿足。

　　1.理解你的需求

　　成為高效程式設計師的第一步是，保證時間的合理分配。沒有什麼比將時間花在完全沒有前途的工作上更浪費的了。

　　儘快開工

　　儘快完成一個直觀的系統。這意味著先建立介面，無論是程式介面還是使用者介面，然後生成內部功能的存根程式碼（如果有必要的話）。這麼做便於“客戶”檢視，通過執行使用者介面或編寫程式介面的程式碼，可以發現最初程式碼存在的矛盾或遺漏。甚至在第一次交付以前，你有可能會注意到問題或可改進的地方。

　　有一個經典觀念認為，如果你提前設計好所有東西，那麼之後你要做的就只剩寫程式碼了。如果你之前做過完全相同的專案，那麼這個說法當然正確。但如果不是，你很可能會陷入死角，也就是你只是在猜想或執行一個可疑的假設。

　　很早以前在一家無限網路的新公司工作時，我們開了兩個月的會來設計一個將在6個月內釋出的無線門戶和閘道器。最終，我們厭煩了開會，開始編寫程式碼。頭兩週內，我負責的部分與原始設計不符，兩個月後的第一個無線連線測試表明，我完全誤解了無線協議。

　　這不是說設計是沒必要的。但在一定程度上，設計只是一種猜想。設計應該通實執行來確認，並且早執行總是比晚執行好。

　　即使原始設計是充分的，只要你發現可以調整的地方，你就要改進它。硬體產品、建築和大型軟體專案等會受到僵死的“預製”的損害，但對於軟體，你可以在專案早期提煉專案要求，然後製作適合的介面。但是，這必須儘早完成。

　　儘早開工有利於樹立你的職業形象。如果能向你的老闆展示一些成果，他會很高興的。另一方面，提早開工有助於緩解焦慮。

　　經常交付

　　一旦你完成一些可用的東西了，不要只是把它留作“概念實證”。要讓其他人試執行它、看看他們的反應，然後讓它指導開發過程的優先次序。觀察人們如何使用你的軟體，這是無可代替的方法。客戶問卷調查和焦點研究可能會提供一些有用的意見，但有可能會讓開發者的設計決定和特點被客戶牽著鼻子走，這是一種冒險。

　　特別是要儘快將軟體交付QA人員，經常提交成果，最好是按預定的時間間隔。讓他們測試每天的成果，或至少是每週的成果也是好的。這會讓QA人員覺得自己全程參與專案開發，從而培養職業責任感，更樂意發現和報告問題。最需要優先解決的是導致產品失效的問題，如崩潰或死迴圈——讓問題儘可能涵蓋多方面，熟悉整個產品，這樣才有可能提早發現設計問題。

　　在一個小型3D軟體公司，我負責移植從SGI出品的龍頭產品到Windows NT。6個月後，移植沒完成，倒有了崩潰的傾向，我很不情願地將第一輪成果交付測試團隊。幸運的是，因為漏洞太多，QA經理堅持要我立刻解決導致測試

　　人員無法有意義地使用程式的問題。如果是我自己測試，我應該會忙於看起來更困難更重要的核心3D問題，可能會怠慢看來起比較普通的問題，如使用者介面、載入-儲存功能和與計劃支援的硬體之間的相容性。

　　程式師常常不想過早將程式碼交付測試人員——他們不想聽到自己已經知道的漏洞；而測試人員極有可能不想測試基本上行不通的東西。但測試人員的工作就是找到這些問題。如果程式師想盡快看到成果的話，應該把漏洞報告當成好東西。

　　2.把工作當真

　　將軟體放在儘可能接近完工的狀態下執行。你永遠不知道你什麼時候得演示系統、傳送評估備份或甚至交付。

　　使用真實資料

　　如果你只用作為著冰山一角的樣本資料作測試，那麼，你的程式可能一撞上真實資料的大冰山就沉了。

　　我曾參與開發一種用於評估先進的半導體絕對值的供應鏈管理產品。跨過交付這道大坎後，我們接到訊息說他們輸入的第一批真實資料仍然在處理中——已經兩天了。我同情主程式師，他不得不在管理人員和客戶的催促之下忙活了兩週。很高興遇上這事的人不是我。

　　使用正式版本

　　記住，用你自己的機器建立的東西不是正式的。

　　在最近的一個遊戲開發專案中，我負責使用者介面，我陸續從QA那接到報告說有些顏色不對。最後，我發現問題只出現在交付版本中，另一位程式師使用專門的主機除錯工具找到了漏洞。結果竟是一個我在兩個月前犯下的愚蠢錯誤，沒有指定初始顏色值。除錯版本總是選擇特定的預設值，但是交付版本會更改，最終結果是不太確定的。如果我注意經常地執行交付版本，我會立刻發現問題的，而不是損失大量的時間。

　　經常合併

　　及時將你的程式碼併入主程式碼庫中——你拖得越久，這項工作就越累。

　　我曾與一名程式師共事，他覺得每天資料庫中出現的所有新程式碼和資料變化都“很麻煩”。確實，這讓所有其他程式師每天都要花一定時間合併，他才能夠只掃視一下程式碼和資料就開始執行一些不錯的獨立樣本。但每一次階段性交付時，我們都要花好幾天再次把單獨的程式碼接到當前的程式碼庫中，有時候甚至得拖延交付或冒著損失整個專案的風險。

　　將你的程式碼與正式版本分開意味著程式師不能評估你的程式碼，以及測試員不能儘早發現漏洞。可能你並不想其他人挑剔你的程式碼，但早發現問題總是比晚發現好的——所以，忍了罷。