結(jié)合中國軟件行業(yè)的特點，歸納出在中國IT行業(yè)“好工程師”的要素，并做成一個自我評價清單。
?

1.保持高標準，不要受制于破窗理論(broken windows theory)。
?
當(dāng)你看到不靠譜的設(shè)計、糟糕的代碼、過時的文檔和測試用例的時候，不要想“既然別人的代碼已經(jīng)這樣了，我的代碼也可以隨便一點啦。”
?
2.?主動解決問題。當(dāng)看到不靠譜的設(shè)計，糟糕的代碼的時候，不要想“可能別人會來管這個事情” ，或者“我下個月發(fā)一個郵件讓大家討論一下”。要主動地把問題給解決了。
?
3.?經(jīng)常給自己充電，身體訓(xùn)練是運動員生活的一部分，學(xué)習(xí)是軟件工程師職業(yè)的伴侶。每半年就要了解和學(xué)習(xí)一些新的相關(guān)技術(shù)。通過定期分享（面對面的分享，寫技術(shù)博客等）來確保自己真正掌握了新技術(shù)。
?
4. DRY （Don't Repeat Yourself）——別重復(fù)。在一個系統(tǒng)中，每一個知識點都應(yīng)該有一個無異議的、正規(guī)的表現(xiàn)形式。
?
5.?消除不相關(guān)模塊之間的影響，在設(shè)計模塊的時候，要讓它們目標明確并單一，能獨立存在，沒有不明確的外部依賴。
?
6. 通過快速原型來學(xué)習(xí)，快速原型的目的是學(xué)習(xí)，它的價值不在于代碼，而在于你通過快速原型學(xué)到了什么。
?
7.?設(shè)計要接近問題領(lǐng)域，在設(shè)計的時候，要接近你目標用戶的語言和環(huán)境。
?
8.?估計任務(wù)所花費的時間，避免意外。在開始工作的時候，要做出時間和潛在影響的估計，并通告相關(guān)人士，避免最后關(guān)頭意外發(fā)生。
?
9. 圖形界面的工具有它的長處，但是不要忘了命令行工具也可以發(fā)揮很高的效率，特別是可以用腳本構(gòu)建各種組合命令的時候。
?
10.?有很多代碼編輯器，請把其中一個用得非常熟練。讓編輯器可以實現(xiàn)自己的定制，可以用腳本驅(qū)動，用起來得心應(yīng)手。
?
11.?理解常用的設(shè)計模式，并知道擇機而用。設(shè)計模式不錯，更重要的是知道它的目的是什么，什么時候用，什么時候不用。
?
12.?代碼版本管理工具是你代碼的保障，重要的代碼一定要有代碼版本管理。
?
13.?在debug的時候，不要驚慌，想想導(dǎo)致問題的原因可能在哪里。一步一步地找到原因。要在實踐中運用工具，善于分析日志（log），從中找到bug。同時，在自己的代碼里面加 log.
?
14.?重要的接口要用形式化的“合同”來規(guī)定。用文檔和斷言、自動化測試等工具來保證代碼的確按照合同來做事，不多也不少。使用斷言 (assertion) 或者其他技術(shù)來驗證代碼中的假設(shè)，你認為不可能發(fā)生的事情在現(xiàn)實世界中往往會發(fā)生。
?
15.?只在異常的情況下才使用異常?(Exception), 不加判斷地過多使用異常，會降低代碼的效率和可維護性。記住不要用異常來傳遞正常的信息。
?
16.?善始善終。如果某個函數(shù)申請了空間或其他資源，這個函數(shù)負責(zé)釋放這些資源。
?
17. 當(dāng)你的軟件有多種技術(shù)結(jié)合在一起的時候，要采用松耦合的配置模式，而不是要把所有代碼都集成到一起。
?
18.?把常用模塊的功能打造成獨立的服務(wù)，通過良好的界面 (API) 來調(diào)用不同的服務(wù)。
?
19.?在設(shè)計中考慮對并行的支持，這樣你的API 設(shè)計會比較容易擴展。
?
20.?在設(shè)計中把展現(xiàn)模塊 (View) 和實體模塊 (Model) 分開，這樣你的設(shè)計會更有靈活性。
?
21.?重視算法的效率，在開始寫之前就要估計好算法的效率是哪一個數(shù)量級上的（big-O）。
?
22.?在實際的運行場景中測試你的算法，不要停留在數(shù)學(xué)分析層面。有時候一個小小的實際因素 (是否支持大小寫敏感的排序，數(shù)據(jù)是否支持多語言)會導(dǎo)致算法效率的巨大變化。
?
23.?經(jīng)常重構(gòu)代碼，同時注意要解決問題的根源。
?
24. 在開始設(shè)計的時候就要考慮如何測試?，如果代碼出了問題，有l(wèi)og 來輔助debug 么? 盡早測試，經(jīng)常測試，爭取實現(xiàn)自動化測試，爭取每一個構(gòu)建的版本都能有某些自動測試。
?
25.?代碼生成工具可以生成一堆一堆的代碼，在正式使用它們之前，要確保你能理解它們，并且必要的時候能debug 這些代碼。
?
26.?和一個實際的用戶一起使用軟件，獲得第一手反饋。
?
27.?在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。
?
28.?如果測試沒有做完，那么開發(fā)也沒有做完。
?
29.?適當(dāng)?shù)刈非蟠a覆蓋率：每一行的代碼都覆蓋了，但是程序未必正確。要確保程序覆蓋了不同的程序狀態(tài)和各種組合條件。
?
30. 如果團隊成員碰到了一個有普遍意義的bug, 應(yīng)該建立一個測試用例抓住以后將會出現(xiàn)的類似的bug。
?
31.?測試：多走一步，多考慮一層。如果程序運行了一星期不退出，如果用戶的屏幕分辨率再提高一個檔次，這個程序會出什么可能的錯誤?
?
32. （帶領(lǐng)團隊）了解用戶的期望值，稍稍超出用戶的期望值，讓用戶有驚喜。
?
33. (帶領(lǐng)團隊) 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過時的假設(shè)、對用戶的誤解或其他因素所遮擋。
?
34. （帶領(lǐng)團隊）把所有的術(shù)語和項目相關(guān)的名詞、縮寫等都放在一個地方。
?
35. （帶領(lǐng)團隊）不要依賴于某個人的手動操作，而是要把這些操作都做成有相關(guān)權(quán)限的人士都能運行的腳本。這樣就不會出現(xiàn)因為某人休假而項目被卡住的情況。
?
36. （帶領(lǐng)團隊）要讓重用變得更容易。一個軟件團隊要創(chuàng)造一種環(huán)境，讓軟件的重用變得更容易。
?
37. （帶領(lǐng)團隊）在每一次迭代之后，都要總結(jié)經(jīng)驗，讓下一次迭代的日程安排更可靠。
?


知乎網(wǎng)友草根屁民則認為程序員要學(xué)會“刻意練習(xí)”：
?
? 國外的技術(shù)問答社區(qū)StackOverflow，有個帖子討論得很火，說的正是“How does a programmer employ deliberate practice? （程序員如何應(yīng)用'刻意練習(xí)'）”。

程序員進行“刻意練習(xí)”，最早是在《Software Craftmanship（軟件工藝）》一書中正式提到，新出的《程序員應(yīng)該知道的97件事》也有一小節(jié)提及。但最系統(tǒng)、詳盡討論的是《Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman（軟件開發(fā)者路線圖：從學(xué)徒到高手）》，可以稱得上是程序員“刻意練習(xí)”的一本行動教科書。

程序員進行”刻意練習(xí)“，與其他領(lǐng)域相比有一個天然優(yōu)勢，就是可以充分利用網(wǎng)絡(luò)和開源。除了《軟件開發(fā)者路線圖：從學(xué)徒到高手》提到的方法，Hacker News技術(shù)社區(qū)的討論還建議了一些網(wǎng)絡(luò)資源，如Coding Dojo（編程擂臺）、Code Kata（精心設(shè)計的21個編程練習(xí)），Ruby社區(qū)的Ruby Quiz郵件列表等。

優(yōu)秀的開源代碼也是很好的學(xué)習(xí)對象。StackOverflow問答社區(qū)建議，可以借鑒富蘭克林學(xué)習(xí)寫作的方法，分析一段優(yōu)秀的開源代碼，梳理邏輯、做好筆記，然后嘗試自己重新實現(xiàn)，再與源代碼進行比對。這個過程可以循環(huán)遞進地進行。 還有知乎網(wǎng)友invalids簡單的歸納了八個字： 概念清晰，直指本質(zhì)

概念清晰，意思是對接觸到的東西，都要有打破砂鍋問到底的好習(xí)慣。而且不僅要問，還要去理解、進而舉一反三。

如果有人連一樣?xùn)|西究竟是什么都弄不清楚，還指望能正確理解它？

有了概念清晰這個基礎(chǔ)，下一個要追求的就是“直指本質(zhì)”（很顯然，如果概念都不清晰，還指望看到本質(zhì)？）

直指本質(zhì)，意思就是要能最簡潔但又最準確的，概括多個概念之間的關(guān)系。

寫程序，本質(zhì)上就是在用程序維護或模擬概念之間的關(guān)系；甚至程序語言本身，就包含了很多基本概念（如順序、分支、循環(huán)）；而這些基本概念內(nèi)部或者之間，又有復(fù)雜的聯(lián)系。

任何理解錯誤，最終都會體現(xiàn)為bug。而且是不提高自己就無從發(fā)現(xiàn)的“高難度”bug（很顯然，對不同人，高難度的定義也不同）。

概念越清晰，基礎(chǔ)抽象就越不容易出現(xiàn)偏差；本質(zhì)抓的越準，代碼出現(xiàn)邏輯錯誤的機會就越少——這自然而然就導(dǎo)向了KISS（Keep IT Simply & Stupid ）。

當(dāng)然，概念清晰、直指本質(zhì)的人，知識面不一定就很寬、很深；在他們知識面拓寬、鉆深之前，是不能稱為優(yōu)秀軟件工程師的；但一個概念不清晰的人，絕對不會是一個很好的工程師——任何行業(yè)都是如此。 ?
工程師們，你決定怎樣的才是IT業(yè)的“好工程師”呢？

總結(jié)

以上是生活随笔為你收集整理的“优秀IT工程师”是什么样的？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。