章淼老師在軟件工程能力方面，積累了多年的經(jīng)驗，這個話題他之前也分享過多次，整體上內(nèi)容有修改調(diào)整。

章老師博士畢業(yè)后在清華待了 12 年，主要是做網(wǎng)絡(luò)方面的研究，到 2006 年的時候離開清華，進入到工業(yè)界，首先做了六年的用戶產(chǎn)品研發(fā)，之后在 2012 年加入百度，一直做網(wǎng)絡(luò)基礎(chǔ)架構(gòu)相關(guān)的開發(fā)工作，主要是對內(nèi)服務(wù)，在運維部和系統(tǒng)部，做 BFE 平臺研發(fā)。2020 年 6 月份轉(zhuǎn)入對外服務(wù)，現(xiàn)在在做 BFE 商業(yè)化推廣。2018 年 1 月到 2021 年 10 月份，兼任百度公司代碼規(guī)范委員會主席。

接下來的內(nèi)容主要分為三個部分，都是在圍繞工程能力。第一，說明清楚為什么要重視工程能力；第二，闡述什么是工程能力；第三，說一下怎么來提高工程能力。

為什么要提升工程能力

這個話題這兩年受到很大的關(guān)注，和現(xiàn)在形勢變化有很大關(guān)系，第一個很重要的形勢是業(yè)界競爭加劇了，很多所謂藍海或者非?？瞻椎念I(lǐng)域已經(jīng)不存在了，大家都在同一個領(lǐng)域競爭，競爭非常激烈；成本已經(jīng)發(fā)生了巨大的上漲，現(xiàn)在中國軟件工程師成本與美國相比，差距沒有那么大，據(jù)之前的交流，中國軟件工程師的成本已經(jīng)超過英國，跟美國已經(jīng)沒有太大的差距了；產(chǎn)業(yè)升級，之前互聯(lián)網(wǎng)公司大部分做的是 ToC 互聯(lián)網(wǎng)，現(xiàn)在很多公司都轉(zhuǎn)向 ToB，轉(zhuǎn)向 ToB 對軟件研發(fā)或者工程能力的要求，已經(jīng)有了非常大的變化。

另外也發(fā)現(xiàn)一些現(xiàn)象，現(xiàn)在很多互聯(lián)網(wǎng)公司加班加點。在去年還出現(xiàn)了 996.ICU，圈外人不知道什么意思，圈內(nèi)人都知道，每天 9 點上班，9 點下班，一周工作 6 天，最后累到進入 ICU 重癥監(jiān)護室。今年我們也發(fā)現(xiàn)有一些變化，很多公司開始響應(yīng)國家號召，減少工作時間，盡量避免 6 天工作制。但是減少時間之后，我們該怎么樣保證工作產(chǎn)出？這其實要依賴我們的工程能力。

我還觀察到的現(xiàn)象，很多的從業(yè)者寫了很長時間的代碼，甚至 8-10 年以上，但是很多的方法都是錯的，換句話說，軟件工程師是一個所謂的青春飯，為什么？其實跟從業(yè)者的素質(zhì)是有關(guān)系的。所以以上的形式，要求我們中國的軟件工程師，也需要更新迭代。

《經(jīng)濟新動能》一書討論的是中國經(jīng)濟如何進行轉(zhuǎn)型升級。在這種大潮流下，IT 從業(yè)者或者中國軟件工程師也要考慮這個問題，就是這四個字“轉(zhuǎn)型升級”。

什么是工程能力

很多人認識到要提升工程能力，但是提升什么能力呢？如果沒有正確的認識，可能也無從下手。有些人會認為工程能力就是寫好代碼。確實我們很多軟件工程師每天關(guān)注的或者平時學(xué)習(xí)的東西，僅僅是寫代碼。

但是我今天重點想表達的觀念是，工程能力不僅僅是寫好代碼這么簡單，也不是某一個人寫好代碼這么簡單，它反映的是團隊的綜合素質(zhì)。軟件工程師大多是理工科畢業(yè)，感覺人文學(xué)科對軟件工作似乎是沒有太大的幫助，但我經(jīng)過這 20 多年軟件研發(fā)之后，深刻體會到做工程不僅僅是自然科學(xué)，也是人文社會科學(xué)。所以對于從業(yè)者來說是需要關(guān)注那些非技術(shù)的方方面面，而且你會發(fā)現(xiàn)在你工作的大量時間中，并不是用在琢磨技術(shù)上，很多時間可能是涉及到溝通等非技術(shù)因素，對我們影響非常非常大，還有包括項目管理，這些看上去和技術(shù)并沒有直接關(guān)系，但是對研發(fā)項目，或者工程能力影響是巨大的。

工程能力的定義來自《百度軟件工程能力定義》，這是百度內(nèi)部的文件，寫于 2019 年底，當時要提升工程能力，需要有文件闡述到底什么是工程能力。最后我們寫了這樣的一句話：使用系統(tǒng)化的方法，在保證質(zhì)量的前提下，更高效率為客戶和用戶持續(xù)交付有價值的軟件或服務(wù)的能力。這句話可以拆解為以下五個要點，第一是研發(fā)的目的是要提供價值，第二是質(zhì)量第一，第三是要實現(xiàn)價值持續(xù)交付，第四要使用系統(tǒng)化和科學(xué)的方法，第五是持續(xù)提升研發(fā)效率。

軟件研發(fā)的目的是要提供價值

業(yè)界中的現(xiàn)象是，很多從事軟件研發(fā)的同學(xué)，比較習(xí)慣從技術(shù)角度來考慮問題，比較喜歡研究復(fù)雜的技術(shù)，技術(shù)簡單覺得沒有意思，沒有興趣去搞。這就造成我們花了大量的精力搞了很復(fù)雜的技術(shù)，但是做出來對社會沒有價值。所以這里面也寫了一下我的觀點，我們在工作中所使用的手段，包括技術(shù)設(shè)計、編寫代碼等技術(shù)只是手段，而不是目的。所以我們不要因為在做的過程當中，使用太多的手段，而忘記我們的目的。

在軟件項目規(guī)劃階段，需要從客戶需求或商業(yè)價值角度考慮，而不是你寫完整后再考慮這個問題。另外，要建立成本意識，我們要考慮投入產(chǎn)出比，要做一個項目應(yīng)該是有收益，而不是最后獲得收益比成本還要小，那就虧本了。這是剛才說的第一點，軟件要能夠提供價值。

質(zhì)量第一

這一點也經(jīng)常被忽視，在項目緊急的時候，就在時間和質(zhì)量之間進行權(quán)衡和取舍，犧牲質(zhì)量，降低對質(zhì)量的要求。那么在《軟件開發(fā)的 201 個原則》里面對質(zhì)量也有所討論，第一條講到質(zhì)量第一。作者是這樣說的，無論如何定義質(zhì)量，客戶都不會容忍低質(zhì)量的產(chǎn)品。即使質(zhì)量差，也按時交付產(chǎn)品，這似乎是政治正確的行為，但這是短視的。從中長期來看，這樣做是自殺。質(zhì)量必須放在首位，沒有可權(quán)衡的余地，說的非常明確。我們拿這條來衡量我們現(xiàn)實當中工作，會發(fā)現(xiàn)很多團隊其實都是在做這樣的事情。

那我們該怎么做呢？第一，對所有的項目，首先需要明確定義質(zhì)量的要求，質(zhì)量并不是絕對的，在各個場景下可能質(zhì)量要求有所不同。所以我們到底做到什么樣的質(zhì)量，這是需要在項目初期定義清楚。第二，在質(zhì)量方面不能妥協(xié)。前面提到我們的軟件要交付提供價值，如果是低質(zhì)量的軟件無法提供價值，整個研發(fā)活動就變得沒有意義了。第三點，我們也需要平衡質(zhì)量和交付時間的關(guān)系，不是降低質(zhì)量，要提高技術(shù)水平，通過技術(shù)手段更高效率、更低成本的保障質(zhì)量，比如說我們可以用自動回歸方法，甚至用 AI 方法，用這些高技術(shù)來保證質(zhì)量。第四，高質(zhì)量的軟件一定是設(shè)計出來的，而不是靠后邊測試、運維保證的，這些都已經(jīng)很晚了。所以我們在設(shè)計階段，就應(yīng)該保證軟件設(shè)計的質(zhì)量，這是非常關(guān)鍵的。

實現(xiàn)軟件價值的持續(xù)交付

觀察到很多現(xiàn)象，即項目執(zhí)行過程當中的前緊后松狀態(tài)，前邊非常投入，花了很多資源，等軟件研發(fā)出來之后，后邊軟件沒有人關(guān)注了，會發(fā)現(xiàn)設(shè)計文檔腐爛、代碼沒有人維護。原因是我們沒有對軟件整個生命周期與價值輸出有清晰的認識，我們只做了短期準備，我們覺得軟件開發(fā)完就結(jié)束了。所以第一點要提升認識，認識到軟件開發(fā)與維護都是長周期的，一個軟件甚至可以運行 10、20 年。在這樣的認識基礎(chǔ)上，需要綜合考慮全周期的研發(fā)成本問題，而不是只考慮開始的時候很快的，最后成本非常高。要做好長期維護的準備，而且要持續(xù)進行改進，一個軟件是逐步通過長期迭代、長期優(yōu)化產(chǎn)生出來的。

這一點也非常非常重要。我們可以看到的現(xiàn)象是什么？在中國軟件很多從業(yè)者是缺乏對軟件開發(fā)方法的深入學(xué)習(xí)。我曾經(jīng)做過調(diào)研，很多從業(yè)者看過真正的軟件工程的書籍，不超過兩本，甚至有些人沒看過，比如說我看到一些列表，某個語言的用法，比如說某些網(wǎng)絡(luò)知識，這些都不是專業(yè)的軟件工程的書籍，我們可以看到在中國軟件復(fù)用比例是非常之低的。所以這一點我們首先要認識到，軟件工程本身是一個非常專業(yè)的方向，軟件誕生已經(jīng)超過半世紀，這些方法甚至在上世紀 90 年代已經(jīng)出現(xiàn)很多成熟的方法，但是非常遺憾的是中國很多從業(yè)者，對這些方法都還沒有充分的掌握。另外，我們也要基于現(xiàn)在優(yōu)秀的基礎(chǔ)設(shè)施高速迭代，現(xiàn)在出現(xiàn)了像云原生思想，包括很多設(shè)施已經(jīng)云化，這些對我們是非常有幫助的。還有軟件復(fù)用能力，建立可復(fù)用的軟件。

使用系統(tǒng)化和科學(xué)的方法

是否使用科學(xué)的方法，效率差距是非常大的，可能差 10 倍、100 倍，甚至從零到一，你用這些正規(guī)方法，有些軟件就可以搞定，如果你沒有掌握系統(tǒng)科學(xué)的方法，這樣復(fù)雜度的軟件你可能根本搞不定。所以掌握科學(xué)方法，對我們駕馭大型軟件是非常重要的。

談到系統(tǒng)科學(xué)方法，我引申一下，我們需要堅持軟件開發(fā)的原則，很多從業(yè)者在現(xiàn)實中，我發(fā)現(xiàn)很容易屈服于各種外部力量，比如說一個領(lǐng)導(dǎo)怎么怎么說，或者說他的需求方怎么怎么說，或者周圍人怎么怎么說，就很容易做出很扭曲的行為。這個原因是什么呢？我思考一下，因為很多從業(yè)者并不知道軟件研發(fā)的基本原則，一個人當他心里沒有原則的時候很容易屈服于外界壓力，所以我們需要堅持軟件開發(fā)的原則。

這里講到什么是原則，原則是工作的準則，而且它代表了很多的集體智慧。在《軟件的 201 原則》里提到了很多重要的原則，我們這兒列了一下，比如說質(zhì)量第一，先確定問題，再寫需求，沒有文檔的設(shè)計不是設(shè)計。像這樣的原則都非常重要，但是你仔細想，在現(xiàn)實工作當中很多團隊、很多人在工作當中，不斷的打破這些原則，這恰恰是造成我們工作非常低效重要的原因。這里面我寫了：沒有原則就會隨意妥協(xié)，結(jié)果就是低效、低質(zhì)的工作。

這也是百度這些同學(xué)為什么在過去兩年很努力在推這本書《軟件開發(fā) 201 個原則》，這是 1995 年出版的非常經(jīng)典的軟件工程書籍，這里面提到很多重要的原則，這本書上個月已經(jīng)正式出版，我們發(fā)現(xiàn)很多開發(fā)者對這本書評價非常高。但是我也看到很多人對這些原則嗤之以鼻，甚至看不懂，有些人對這本書評價非常低，這一點是非常令人痛心，明明不知道這些原則，當把這些原則告訴他的時候也沒有任何感覺，這一點我是非常遺憾的。

持續(xù)提升研發(fā)效率

研發(fā)效率絕對不是一天可以見成的，甚至永無止境。發(fā)現(xiàn)很多管理者對業(yè)務(wù)目標非常關(guān)注，但是對軟件研發(fā)的能力并沒有持續(xù)關(guān)注。這是一個非常大的誤區(qū)。所以提升效率、提升人效，應(yīng)該是一個軟件研發(fā)團隊一直需要追求的目標，應(yīng)該去想一想我們今天是怎么做軟件的，一年兩年之后，我們怎么能夠更好的做軟件，會有什么變化。

軟件工程能力提升，該怎么做？

在百度的軟件工程能力定義里，工程能力的素質(zhì)中的個人能力素質(zhì)，包括團隊的能力素質(zhì)，以及公司的能力素質(zhì)。個人能力素質(zhì)包括需求的把握、系統(tǒng)設(shè)計，這兩個主要是關(guān)于前面的設(shè)計階段。編碼能力、項目管理，還有運維能力，這是軟件后期上線運維，以及產(chǎn)品意識、客戶服務(wù)意識、安全意識、質(zhì)量意識，還有溝通能力。對一個個體來說，這些是非常重要的工程能力。

這里想強調(diào)一點，對于工程能力來說，人是根本。我認為人的要素是最為關(guān)鍵的。這里面有一個說法，為什么使用同樣工具的人，為什么你的效率只有別人的 N 分之一。而且對一個優(yōu)秀的人來說，他只使用一般的工具，他工作的產(chǎn)出會遠遠超過一般的人使用優(yōu)秀的工具。還有一個很重要的趨勢是什么呢？小規(guī)模優(yōu)秀工程師團隊，要遠遠超過大規(guī)模一般工程師團隊。這是為什么呢？因為對一個大的團隊來說，溝通成本是非常高的，團隊內(nèi)溝通成本是隨著人的數(shù)量呈指數(shù)級上升。所以這方面由于現(xiàn)在軟件工具提升，包括各種云平臺的出現(xiàn)，實際上把效能變的更大了，一個小的團隊可以做非常非常多的事情。

對于一個優(yōu)秀產(chǎn)品，一定是來自于優(yōu)秀的人與團隊的，一定不是來自一個一般的團隊。我也曾經(jīng)講過，軟件是人類智慧的結(jié)晶，優(yōu)秀的智慧結(jié)晶一定是來自優(yōu)秀的人與團隊。所以我的建議是軟件研發(fā)主管或者 Leader，多投一些精力培養(yǎng)團隊成員。

從個人素質(zhì)來講，我經(jīng)常簡化為三點：代碼、文檔、項目管理。這三者當中的排序，我個人認為項目管理是高于文檔、高于代碼，這可能跟很多人的認識會不一樣，很多工程師認為代碼是最重要，90%甚至 95%以上的軟件工程師是忽視項目管理的，沒有掌握正規(guī)的方法。

首先從代碼說起，要求非常清楚，要能寫出讓別人很容易看懂的代碼，這個要求好像非常低，但是其實很多人是做不到的。這里面我引用的是 Python 的非常好的一句話，第一句話是優(yōu)美比丑陋好，你的顯示比隱示更好。其實 Python 語言，很多人沒有關(guān)注到這里面講到的東西，所以我們代碼應(yīng)該是寫的要盡量簡單、盡量優(yōu)美，要盡量使用簡單的方法。

所以寫好代碼方法也很簡單，我這邊列了五點：

第一，合理的模塊劃分。很多同學(xué)模塊劃分有很嚴重的問題，導(dǎo)致未來軟件維護非常困難，也非常難以復(fù)用。

第二，清晰的函數(shù)定義。別看函數(shù)這么簡單，我發(fā)現(xiàn)很多同學(xué)對函數(shù)語義定義并不清楚。

第三，短小清晰的代碼段落。如果我們想想很多同學(xué)寫出的代碼幾百行沒有任何一行空行、注釋。

第四，準確的命名，強調(diào)一下，漂亮代碼要具備一定的語文基礎(chǔ)，寫代碼和寫文章一樣。

第五，清晰的注釋，確實應(yīng)該講很多人的代碼里面，幾乎看不到任何一行注釋。

此外，認真的代碼評審，是提升代碼質(zhì)量最好的方法，同時也是傳播編程方法最好的方法。但是非常遺憾，在中國互聯(lián)網(wǎng)行業(yè)還有很多團隊沒有真正執(zhí)行代碼評審。

真正的軟件工程師在軟件上的追求：差一個空格都不行。我們離這個目標還很遠。

工程能力提升的第二點：文檔

我們需要大家重視文檔，文檔的忽視確實受到了所謂“敏捷”運動的影響，因為很多人對敏捷有錯誤的認識，似乎很多人的概念里，敏捷就是不寫文檔。但是我今年確實對敏捷做了一些研究，敏捷運動當時的起源是應(yīng)對上世紀 80 年代或者是 90 年代非常重視文檔要求，做一個項目要寫非常非常多文檔，文檔已經(jīng)成為工作的負載。所以敏捷思想提出要少寫一點文檔，是說少寫一點，而不是不寫，不知道在中國怎么傳成敏捷就是不寫項目文檔。

在《軟件開發(fā) 2.0》的書里面明確提出，沒有文檔的設(shè)計，不是設(shè)計。所以現(xiàn)實當中很多軟件工程師沒有做設(shè)計，直接就是撲上去寫代碼，這件事情是非?；闹嚨模谄渌袠I(yè)都會去寫設(shè)計文檔，再投入生產(chǎn)，而在我們這個行業(yè)，都沒有寫任何文檔，就做完了，開始編碼，所以這件事情非常荒謬。

另外一個角度大家要認識到為什么要寫好項目文檔，因為在整個項目過程當中我們有超過 50%的時間是用來溝通的，所以溝通效率會極大影響研發(fā)的效率。文檔的目的是什么呢？我認為，第一點提升溝通的效率，通過一個清晰的文檔，可以極大提升溝通效率。第二是提升對思考過程的管理。你在整個設(shè)計過程當中，我們把文檔作為一種設(shè)計工具，用來整理思想。

所以從這個角度出發(fā)，我們很多人關(guān)于文檔是作為最后存檔方式的一種認識，是非常錯誤的。這里面我寫了兩句話，第一，不會寫文檔就等于你不會做設(shè)計。第二，不會寫文檔就無法成為高級工程師。所以很多人的天花板是非常明確，可能寫了 8-10 年的代碼，但是你不會寫文檔，所以至今仍然無法躍升成為高級軟件工程師。

怎么才能寫好文檔？第一，用戶思維。比如說寫需求文檔，要從用戶角度想問題，而不是從內(nèi)部實踐角度。第二，準確的概念定義。這跟剛才講代碼命名有一點類似，命名代表了概念，在文檔里面也同樣面臨著概念的問題。第三，要有清晰準確的邏輯，這一點也非常重要。第四，可能大家一般沒有關(guān)注到，就是規(guī)范的表達方式。無論是用文字還是圖表，我確實在工作當中會說，某某同學(xué)請你不要再使用你的方言。很多人確實沒有使用規(guī)范的方式，他用自己看懂的方式表達，別人理解起來很困難。第五，一定要有研究和思考能力，我們在工作當中都在不知不覺做著研究，研究就是定義問題、分析問題、解決問題。第六，嚴謹科學(xué)態(tài)度，很多同學(xué)寫文檔有很多的問號、不清楚的地方都留下來，這樣的話保留之后進入下一階段，這樣做的系統(tǒng)是經(jīng)不起歷史與時間的檢驗。第七，要認真和充分的設(shè)計評審，很多團隊在代碼評審上做的不好，應(yīng)該在文檔評審上做的更差，很多文檔可能沒有人看，直接通過了。所以這里面現(xiàn)在是 7 點，似乎好像很簡單，如果能把這些做到，我們一定可以產(chǎn)出非常高質(zhì)量的項目文檔。

也推薦對大家提升文檔是有幫助的兩本書，第一《人人都是產(chǎn)品經(jīng)理 2.0》，如果想學(xué)怎么做需求分析，我建議看看這本書，即使你不是產(chǎn)品經(jīng)理。第二本是《金字塔原理——思考、理論和解決問題的邏輯》，也很不錯，大家可以看看這兩本書。

第三點要強調(diào)的，也是最高優(yōu)先級的重視項目管理。從我到工業(yè)界差不多 15 年時間，我認為大量的團隊忽視了項目管理，在《軟件開發(fā)的 2.0》里面提到一個觀點，原則 127：好的管理比好的技術(shù)更重要。有再好的技術(shù)，如果你管理的不好，這個項目也是要失敗的。這里面就會有一個大家經(jīng)常問到的問題，我不是管理者，也不是 Leader，為什么要做項目管理？從德魯克的觀點出發(fā)，他提到我們現(xiàn)在這些人從事著這些行業(yè)，其實都是知識工作者，每個知識工作者都是管理者，我們要站在這個角度上看問題。所以每個工程師其實都是管理者，要做好自己的管理。而且現(xiàn)實工作當中你會發(fā)現(xiàn)很多項目是工程師在管理，他的經(jīng)理、Leader，這些細節(jié)都管不過來。而且從整個行業(yè)趨勢來看，高度自組織的小團隊才是趨勢。大家可能記得我前面提到，由優(yōu)秀的人構(gòu)成小規(guī)模軟件工程團隊，遠遠高于大規(guī)模一般人構(gòu)成的團隊。

好的項目管理來自：第一，了解項目管理的常識和原則；第二，實事求是的態(tài)度。我發(fā)現(xiàn)很多人在面臨項目問題的時候，采取回避，或者是隱瞞的態(tài)度，這不利于項目正常進行。所以這里面非常強調(diào)我們要講真話，要敢于向外披露。

第三，需要對知識社會有正確的理解。知識社會的特征是什么，從權(quán)利為中心轉(zhuǎn)向以知識為中心，我們要尊重專業(yè)、自主管理，這些不是靠人能看住，即使可以看著人表面在工作，但沒有看住大腦。還有以人為中心，要摒棄大工業(yè)生產(chǎn)的思想，每個人都是螺絲釘，每個人都會被替代，這樣的思想是會被替代的。

這里面推薦兩本書，一個是德魯克《知識社會》，如果沒有知識社會，我們不可能建立現(xiàn)在非常高效知識團隊。第二本書是清華的《快速開發(fā)》，出版的非常早，但是非常好的一本書。

總結(jié)

我們的社會越來越被信息驅(qū)動，在信息社會里面軟件驅(qū)動信息社會，軟件研發(fā)是非常重要的。其次，軟件工程師的提升，對中國有巨大的意義，大家不要忽視自己的責(zé)任。