轉自：軟件工程能力漫談：比質量更重要的，是項目管理能力 | ArchSummit

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

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

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

為什么要提升工程能力

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

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

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

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

什么是工程能力

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

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

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

軟件研發的目的是要提供價值

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

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

質量第一

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

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

實現軟件價值的持續交付

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

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

使用系統化和科學的方法

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

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

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

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

持續提升研發效率

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

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

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

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

對于一個優秀產品，一定是來自于優秀的人與團隊的，一定不是來自一個一般的團隊。我也曾經講過，軟件是人類智慧的結晶，優秀的智慧結晶一定是來自優秀的人與團隊。所以我的建議是軟件研發主管或者 Leader，多投一些精力培養團隊成員。

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

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

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

第一，合理的模塊劃分。很多同學模塊劃分有很嚴重的問題，導致未來軟件維護非常困難，也非常難以復用。第二，清晰的函數定義。別看函數這么簡單，我發現很多同學對函數語義定義并不清楚。第三，短小清晰的代碼段落。如果我們想想很多同學寫出的代碼幾百行沒有任何一行空行、注釋。第四，準確的命名，強調一下，漂亮代碼要具備一定的語文基礎，寫代碼和寫文章一樣。第五，清晰的注釋，確實應該講很多人的代碼里面，幾乎看不到任何一行注釋。

此外，認真的代碼評審，是提升代碼質量最好的方法，同時也是傳播編程方法最好的方法。但是非常遺憾，在中國互聯網行業還有很多團隊沒有真正執行代碼評審。

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

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

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

在《軟件開發 2.0》的書里面明確提出，沒有文檔的設計，不是設計。所以現實當中很多軟件工程師沒有做設計，直接就是撲上去寫代碼，這件事情是非?；闹嚨?#xff0c;在其他行業都會去寫設計文檔，再投入生產，而在我們這個行業，都沒有寫任何文檔，就做完了，開始編碼，所以這件事情非?；闹?。

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

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

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

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

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

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

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

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

總? ? 結

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

總結

以上是生活随笔為你收集整理的【转】软件工程能力漫谈：比质量更重要的，是项目管理能力的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。