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

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


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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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