編輯 | 薛梁
章淼老師在軟體工程能力方面，積累了多年的經驗，這個話題他之前也分享過多次，整體上内容有修改調整。
章老師博士畢業後在清華待了 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，這些細節都管不過來。而且從整個行業趨勢來看，高度自組織的小團隊才是趨勢。大家可能記得我前面提到，由優秀的人構成小規模軟體工程團隊，遠遠高于大規模一般人構成的團隊。
好的項目管理來自：第一，了解項目管理的常識和原則；第二，實事求是的态度。我發現很多人在面臨項目問題的時候，采取回避，或者是隐瞞的态度，這不利于項目正常進行。是以這裡面非常強調我們要講真話，要敢于向外披露。
第三，需要對知識社會有正确的了解。知識社會的特征是什麼，從權利為中心轉向以知識為中心，我們要尊重專業、自主管理，這些不是靠人能看住，即使可以看着人表面在工作，但沒有看住大腦。還有以人為中心，要摒棄大工業生産的思想，每個人都是螺絲釘，每個人都會被替代，這樣的思想是會被替代的。
這裡面推薦兩本書，一個是德魯克《知識社會》，如果沒有知識社會，我們不可能建立現在非常高效知識團隊。第二本書是清華的《快速開發》，出版的非常早，但是非常好的一本書。
總 結
我們的社會越來越被資訊驅動，在資訊社會裡面軟體驅動資訊社會，軟體研發是非常重要的。其次，軟體工程師的提升，對中國有巨大的意義，大家不要忽視自己的責任。
活動推薦