高效程式員應該養成的七個習慣

高效程式員應該養成的七個習慣

       對于軟體工程師來說，工作也許意味着許多東西 -- 穩定的收入、做自己感興趣的項目、找一份更好工作的跳闆，或者你隻是喜歡與其他程式員共事。但說到“效率”，強調的是在一定時間内按質完成項目的能力。Phil Chu根據自己的經驗提出了高效程式員應該養成的七個習慣。建議去看看作者的原文(可能需要代理才能正常通路)。

　　一．了解你的需求

　　成為一個有效率的程式員首先要知道如何正确的支配自己的時間。對時間最大的浪費莫過于去做那些沒有用處或者永遠不會上線的項目。而導緻這種結果的根源往往是對需求了解的偏差。

要最大程度避免這種情況的發生，最好的辦法是快速模組化，盡可能讓示範系統早點出來。對于客戶來說，隻有看得到摸得着的産品擺在面前，他們才會有興趣去試用觀察，才會在實際的操作中發現供需雙方在需求了解上的偏差。否則即使你寫上幾百頁的需求分析文檔也隻能是自己的一面之詞，客戶可沒耐心去檢查這些文檔寫的是否準确。

　　另一方面，你應該讓每一個階段的開發成果都能夠盡早的送出給客戶。讓他們以完全不考慮操作合理性和業務邏輯性的傻瓜級操作來發現程式員程式設計中的固有思維局限。尤其必須讓QA盡早的介入到項目開發中來。如果能夠每天送出一份測試版本給QA自然是最理想的了，但大多數項目開發做不到這樣的粒度，那麼就争取每周送出一份可測試版本。重要的是應該讓QA和開發能夠保持交錯并行狀态。隻有這樣，才能讓QA盡早發現bug，降低每個 bug的修複成本，同時縮減獨立測試周期的跨度。

　　程式員往往不願意把半成品代碼傳遞給測試人員，相反他們更喜歡在所有代碼都完工，達到自己滿意的程度之後再讓别人來測試。因為在這之前的代碼往往存在很多程式員自己知道需要修改（或者故意留待後續補全）的流程缺失和Bug，測試人員并不知道哪些是真正的Bug，哪些隻是臨時性的運作錯誤，每次都會一股腦兒作為Bug回報給程式員。這往往讓程式員們心煩。同時測試人員有時候也不喜歡測試這種很多分支都走不通的中間版本。

　　但不管喜不喜歡，測試并發現問題是測試人員的工作；程式員則應該認識到，Bug回報得越早就越是件好事情。QA和開發之間的關系往往很敵對，可實際上雙方的目标是一緻的。“忠言逆耳”古訓有之，對于程式員來說就應該“有則改之，無則加勉”。總好過項目完成之後才發現一堆的問題，到那時候再要做修改，基本上都會牽一發而動全身，痛苦的還是程式員自己。

　　二．保持真實性

　　盡可能讓你的系統運作在最接近真實環境配置下面，使用有實際意義的資料和真實的編譯版本，并經常性進行子產品整合。如果你的測試環境使用的資料都是些胡亂添加的東西，那麼将來和測試資料大相徑庭的真實資料這塊大冰山早晚會撞沉你的程式。另一方面如果你隻在開發環境來編譯運作測試，會發現正式釋出之後有各種各樣莫名其妙的問題産生，到最後原來都是因為環境配置與開發環境有些不起眼的差異所導緻。把所有子產品整合進行編譯聯調，看上去應該是最後作的一項附加工作，但實際上這是一項需要在開發過程中經常性進行的工作。隻有這樣QA才能有最完整的東西拿來測試，得到更多的Bug回報，同時降低子產品整合的難度。

　　三．了解你的代碼

　　書寫規範的代碼，并保持代碼的整潔。Coding是一門藝術。正如寫作一樣，同樣的文字在文豪的筆下就能夠熠熠生輝，讀起來賞心悅目；在普通人的筆下大概就隻是詞能達意的效果了；在某些人的筆下或許就需要研究半天才能猜出個大概來。當然不可能人人都成為藝術家，但至少你可以學會欣賞藝術、學習藝術。書寫漂亮的代碼是對自己工作的尊重，也是對其他程式員的尊重。如果你的代碼中間充斥着大段過時的注釋、可讀性差的變量/函數，怎麼去要求别人或者自己以後能夠了解它們？

　　四．最優程式設計

　　把你的時間花在代碼的功能上, 而不是去把現有的代碼改得對自己胃口（尤其對于那些copy/paste過來的代碼）；要找到系統的瓶頸進行優化，而不是對那些無益于系統整體性能提高的地方做無用功。

　　五．管理好你自己

　　也許有人會說計劃和進度控制是PM的事情，但一個好的程式員應該比PM更了解自己目前工作的進度。不論上頭給的進度計劃是否合理，你都應該有自己的原則和概念，清楚知道每天該做什麼怎麼去做。

　　六．持續教育

　　隻有不斷的學習、實踐、犯錯誤，你才會真正有所提高。在我看來，對于程式員來說最好的老師不在學校，而在書本、網絡、社群。學會自我學習才能保持與時俱進。

　　七．R-E-S-P-E-C-T