一名好的工程師一般都有這些能力

曾經(jīng)有這樣試驗(yàn)，隨機(jī)選擇一組對象進(jìn)行工作的自評，幾乎所有對象的自評分都在實(shí)際成績的平均分以上。在工程師團(tuán)隊(duì)中也不例外，許多工程師有這樣的困 惑，自己覺得工作已經(jīng)做得不錯(cuò)，但是上司好像察覺不到，甚至還對自己的工作吹毛求疵。如果有個(gè)合適參照標(biāo)準(zhǔn)，工程師或許就可以更好的對自己工作進(jìn)行自評。

管理者也同樣面臨類似困惑，在一個(gè)組織中，需要定期對團(tuán)隊(duì)中的成員進(jìn)行考核及晉升，但是考核的標(biāo)準(zhǔn)是什么？小團(tuán)隊(duì)中主要取決于管理者的意志；大型組織中流程會更規(guī)范，但也存在考核者憑感覺來給被評估者打分的情況，或者是考核者心中的衡量標(biāo)準(zhǔn)千差萬別。

從工程師自我提升追求及職業(yè)規(guī)劃的角度，情況會更復(fù)雜。每一個(gè)工程師都有不同的追求目標(biāo)，孟巖有一篇很有影響力的《技術(shù)路線的選擇重要但不具有決定性》，文中工程師的追求類型被描述成事業(yè)目標(biāo)型、團(tuán)隊(duì)精英型、技術(shù)高手型、得過且過或養(yǎng)家糊口型四種。文中將“獨(dú)特的個(gè)性知識經(jīng)驗(yàn)組合”看做是工程師的核心競爭力，不過對于這個(gè)經(jīng)驗(yàn)的組合不同人會有不同的理解。

從團(tuán)隊(duì)或者企業(yè)的角度來看，主要從團(tuán)隊(duì)的貢獻(xiàn)角度來評估技術(shù)工程師的成績，就如同評估一個(gè)科學(xué)家的成看他看對人類的貢獻(xiàn)類似。離開了環(huán)境，單純評估技術(shù)沒有意義。比如一個(gè)技術(shù)人員對Linux內(nèi)核看得滾瓜爛熟，單就這一點(diǎn)并不能看到太大直接價(jià)值。

但是在業(yè)界，知識點(diǎn)的重要性通常被放大了，業(yè)界也形成了一些非理性的氛圍。工程師會努力學(xué)習(xí)某個(gè)技術(shù)（如C++語言）的方方面面，即使大部分場合只 用到了其中小部分功能。技術(shù)管理者在招聘、考核、晉升等過程中也通常把知識點(diǎn)放在一個(gè)很重要的地位，面試題中會出現(xiàn)工作中并不常用的領(lǐng)域的各種知識點(diǎn)。

這跟前幾天某條關(guān)于大學(xué)教育的微博有異曲同工之妙，大學(xué)教育經(jīng)歷了全部是知識點(diǎn)的教育，慢慢意識到需要培養(yǎng)的能力不僅是知識點(diǎn)，而主要應(yīng)是獨(dú)立思考能力。

技術(shù)人員追求的也不僅是知識點(diǎn)，而是在專業(yè)領(lǐng)域正確做事的方法及達(dá)成目標(biāo)的能力。兩個(gè)同時(shí)入職的員工，一段時(shí)間后技術(shù)好的那個(gè)就發(fā)展得好嗎？還是有更好做事方法及能達(dá)成目標(biāo)的人更容易得到認(rèn)可？

我認(rèn)為一個(gè)好的工程師必要的能力

設(shè)計(jì)能力

設(shè)計(jì)能力參見前文技術(shù)評審中關(guān)于設(shè)計(jì)的描述，簡要的說就是具備設(shè)計(jì)簡潔、易于擴(kuò)展及維護(hù)的功能及特性能力。

需要補(bǔ)充一個(gè)設(shè)計(jì)方面的anti-pattern， 選擇合適的技術(shù)及架構(gòu)，意味著不引入及增加不必要的抽象層或框架，并提供高質(zhì)量、穩(wěn)定、高效、安全的代碼。不少能力還不錯(cuò)的人員有這個(gè)缺點(diǎn)，一個(gè)簡單的項(xiàng) 目，出于追求流行或者對于某項(xiàng)技術(shù)的崇拜心理，引入了復(fù)雜的技術(shù)或框架，對于個(gè)人來說確實(shí)提高了見識，增加了業(yè)內(nèi)交流的資本，但是對于組織來說這種鍛煉卻 是團(tuán)隊(duì)成效的噩夢，對于技術(shù)從業(yè)人員來說，不盲目引入不必要的高深技術(shù)來保證項(xiàng)目進(jìn)展是一種基本的職業(yè)素養(yǎng)。

此外設(shè)計(jì)中還有一個(gè)隱含的條件，就是選擇的方案能相對減少開發(fā)周期，加快交付時(shí)間。也就是下一點(diǎn)介紹的。

交付能力

通俗的說就是不管發(fā)生了什么，都能按時(shí)交付。

充分考慮自身技術(shù)能力、項(xiàng)目依賴、隊(duì)員排期沖突、負(fù)面情緒、技術(shù)方案風(fēng)險(xiǎn)、未預(yù)知的技術(shù)障礙、需求變化等。

具備為功能的設(shè)計(jì)做取舍的能力，但功能取舍并不以犧牲產(chǎn)品的核心愿景為前提。

規(guī)范與協(xié)作

在編碼前能夠完成模塊或特性的清晰架構(gòu)或設(shè)計(jì)文檔，并保持在開發(fā)過程以及代碼重構(gòu)過程中文檔的一致性。

推動及促進(jìn)團(tuán)隊(duì)的代碼及設(shè)計(jì)規(guī)范，并確保執(zhí)行過程中與規(guī)范的一致，并能根據(jù)實(shí)際情況對流程及規(guī)范提供優(yōu)化建議。

編寫的代碼通常當(dāng)做團(tuán)隊(duì)的模板或者是最佳實(shí)踐的設(shè)計(jì)模式。

團(tuán)隊(duì)效率貢獻(xiàn)

有改善團(tuán)隊(duì)效率方面的貢獻(xiàn)嗎？比如做一個(gè)相似項(xiàng)目為何周期很長？為什么開發(fā)完成之后又花了比開發(fā)周期更長的時(shí)間調(diào)試或修改bug？

推進(jìn)代碼復(fù)用，你的代碼和工具其他小組或部門愿意用嗎，準(zhǔn)備讓他們用嗎？有推動讓他們用嗎？

自動化體系來幫助提高測試、開發(fā)、debug、跟蹤用戶問題的效率

能夠用服務(wù)化的方法來解決異構(gòu)、多版本問題

有優(yōu)化流程貢獻(xiàn)？

已經(jīng)不是那個(gè)獨(dú)行俠或個(gè)人技術(shù)英雄的時(shí)代了，融入團(tuán)隊(duì)，多考慮對團(tuán)隊(duì)的貢獻(xiàn)，更容易得到成長。