編輯 | 薛梁章淼老師在軟件工程能力方麵 積纍瞭多年的經驗 軟件工程能力漫談：比質量更重要的，是項目管理能力｜ArchSummit - 趣味新聞網

編輯 | 薛梁

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

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

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

為什麼要提升工程能力

這個話題這兩年受到很大的關注，和現在形勢變化有很大關係，第一個很重要的形勢是業界競爭加劇瞭，很多所謂藍海或者非常空白的領域已經不存在瞭，大傢都在同一個領域競爭，競爭非常激烈； 成本已經發生瞭巨大的上漲，現在中國軟件工程師成本與美國相比，差距沒有那麼大，據之前的交流，中國軟件工程師的成本已經超過英國，跟美國已經沒有太大的差距瞭 ；産業升級，之前互聯網公司大部分做的是 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》的書裏麵明確提齣，沒有文檔的設計，不是設計。所以現實當中很多軟件工程師沒有做設計，直接就是撲上去寫代碼，這件事情是非常荒謬的，在其他行業都會去寫設計文檔，再投入生産，而在我們這個行業，都沒有寫任何文檔，就做完瞭，開始編碼，所以這件事情非常荒謬。

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

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

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

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

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

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

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

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

總 結

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

活動推薦