軟體工程師能力自我評價

標籤：blog   http   使用   資料   width   io   

1.保持高標準，不要受制於破窗理論(broken windows theory)[i]。
當你看到不靠譜的設計、糟糕的代碼、過時的文檔和測試案例的時候，不要想“既然別人的代碼已經這樣了，My Code也可以隨便一點啦。”

2. 主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想“可能別人會來管這個事情” ，或者“我下個月發一個郵件讓大家討論一下”。要主動地把問題給解決了[ii]。

3. 經常給自己充電，身體訓練是運動員生活的一部分，學習是軟體工程師職業的伴侶。每半年就要瞭解和學習一些新的相關技術。通過定期分享（面對面的分享，寫技術部落格等）來確保自己真正掌握了新技術。

4. DRY （Don‘t Repeat Yourself）——別重複。在一個系統中，每一個知識點都應該有一個無異議的、正規的表現形式。

5. 消除不相關模組之間的影響，在設計模組的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。

6. 通過快速原型來學習，快速原型的目的是學習，它的價值不在於代碼，而在於你通過快速原型學到了什麼。

7. 設計要接近問題領域，在設計的時候，要接近你目標使用者的語言和環境。

8. 估計任務所花費的時間，避免意外。在開始工作的時候，要做出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。

9. 圖形介面的工具有它的長處，但是不要忘了命令列工具也可以發揮很高的效率，特別是可以用指令碼構建各種組合命令的時候。

10. 有很多代碼編輯器，請把其中一個用得非常熟練。讓編輯器可以實現自己的定製，可以用指令碼驅動，用起來得心應手。

11. 理解常用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，什麼時候用，什麼時候不用。

12. 代碼版本管理工具是你代碼的保障，重要的代碼一定要有代碼版本管理。

13. 在debug的時候，不要驚慌，想想導致問題的原因可能在哪裡。一步一步地找到原因。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在自己的代碼裡面加 log.

14. 重要的介面要用形式化的“合約”來規定。用文檔和斷言、自動化測試等工具來保證代碼的確按照合約來做事，不多也不少。使用斷言 (assertion) 或者其他技術來驗證代碼中的假設，你認為不可能發生的事情在現實世界中往往會發生。

15. 只在異常的情況下才使用異常 (Exception),  不加判斷地過多使用異常，會降低代碼的效率和可維護性。記住不要用異常來傳遞正常的資訊。

16. 善始善終。如果某個函數申請了空間或其他資源，這個函數負責釋放這些資源。

17. 當你的軟體有多種技術結合在一起的時候，要採用松耦合的配置模式，而不是要把所有代碼都整合到一起。

18. 把常用模組的功能打造成獨立的服務，通過良好的介面 (API) 來調用不同的服務。[YEKA1] 

19. 在設計中考慮對並行的支援，這樣你的API 設計會比較容易擴充。

20. 在設計中把展現模組 (View) 和實體模組 (Model) 分開，這樣你的設計會更有靈活性。 

21. 重視演算法的效率，在開始寫之前就要估計好演算法的效率是哪一個數量級上的（big-O）。

22. 在實際的運行情境中測試你的演算法，不要停留在數學分析層面。有時候一個小小的實際因素 (是否支援大小寫敏感的排序，資料是否支援多語言)會導致演算法效率的巨大變化。

23. 經常重構代碼，同時注意要解決問題的根源。

24. 在開始設計的時候就要考慮如何測試 ，如果代碼出了問題，有log 來輔助debug 麼? 儘早測試，經常測試，爭取實現自動化測試，爭取每一個構建的版本都能有某些自動化的測試。

25. 代碼產生工具可以產生一堆一堆的代碼，在正式使用它們之前，要確保你能理解它們，並且必要的時候能debug 這些代碼。

26. 和一個實際的使用者一起使用軟體，獲得第一手反饋。 

27. 在自動化的測試的時候，要有意引地入bug，來保證自動化的測試的確能捕獲這些錯誤。

28. 如果測試沒有做完，那麼開發也沒有做完。

29. 適當地追求程式碼涵蓋範圍：每一行的代碼都覆蓋了，但是程式未必正確。要確保程式覆蓋了不同的程式狀態和各種組合條件。

30. 如果團隊成員碰到了一個有普遍意義的bug,  應該建立一個測試案例抓住以後將會出現的類似的bug。

31. 測試：多走一步，多考慮一層。如果程式運行了一星期不退出，如果使用者的螢幕解析度再提高一個檔次，這個程式會出什麼可能的錯誤?

32. （帶領團隊）瞭解使用者的期望值，稍稍超出使用者的期望值，讓使用者有驚喜。

33.  (帶領團隊) 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過時的假設、對使用者的誤解或其他因素所遮擋。

34. （帶領團隊）把所有的術語和項目相關的名詞、縮寫等都放在一個地方。

35. （帶領團隊）不要依賴於某個人的手動操作，而是要把這些操作都做成有相關許可權的人士都能啟動並執行指令碼。這樣就不會出現因為某人休假而項目被卡住的情況。

36. （帶領團隊）要讓重用變得更容易。一個軟體團隊要創造一種環境，讓軟體的重用變得更容易。

37. （帶領團隊）在每一次迭代之後，都要總結經驗，讓下一次迭代的排程更可靠。

 

[i]      參見：http://en.wikipedia.org/wiki/Broken_windows_theory

[ii]      Jim Barksdale 是Netscape 公司的CEO, 他提出了Snake Rule，見到問題，就要解決問題，但是也不要沉溺於無法挽回的事情中。參見：http://www.menk.com/blog/archives/2006/11/20/jim-barksdales-rules-of-snakes  以及 http://www.celebrazio.net/jimb/15.html

 [YEKA1]“和使用模組交流”有點彆扭？