“优秀IT工程师”是什么样的?
生活随笔
收集整理的這篇文章主要介紹了
“优秀IT工程师”是什么样的?
小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
結(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è)的“好工程師”呢?
?
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)題。
- 上一篇: Ping命令及其协议
- 下一篇: WebService入门讲解