近日任正非的公開信《全面提升軟件工程能力與實踐，打造可信的高質(zhì)量產(chǎn)品》刷屏了，作為一個軟件工程專業(yè)科班出身的軟件開發(fā)從業(yè)者，自然是引起了我的好奇。仔細閱讀之下確實讓我大吃一驚，看似八股官方文，但細看之下是作者對于軟件工程的理解確實非常深刻，各種專業(yè)術(shù)語信手拈來，比喻恰到好處。

我對華為的研發(fā)其實一直挺好奇的，從傳統(tǒng)的硬件公司，到現(xiàn)在軟硬件齊頭并進，華為手機銷量都已經(jīng)超過了蘋果，可見華為的軟硬件研發(fā)實力早已是全球領(lǐng)先了。公開信中的這一句：

二十年前的 IPD 變革，重構(gòu)了我們的研發(fā)模式，實現(xiàn)了從依賴個人、偶然性推出成功產(chǎn)品，到制度化、持續(xù)地推出高質(zhì)量產(chǎn)品的轉(zhuǎn)變。

也揭示了華為的軟件研發(fā)能做到領(lǐng)先水平的原因。

華為是在 1999 年開始從 IBM 引進 IPD 的，到今年 2019 年正好 20 年，在過去的 20 年里，IPD 幫助華為從游擊隊變成了正規(guī)軍，研發(fā)隊伍從幾千人到幾萬人，軟件產(chǎn)品也覆蓋到手機操作系統(tǒng)、應用、云服務。

我對 IPD 是不甚了解的，只知道 IPD（Integrated Product Development，集成產(chǎn)品開發(fā)）是一種產(chǎn)品開發(fā)方法，但如果說軟件產(chǎn)品的開發(fā)方法，我是比較熟悉的，那就是軟件工程么！

任正非發(fā)出的這封信的大背景也很特殊，2018 年中美貿(mào)易戰(zhàn)開始，中興、華為首當其沖成為美國開刀的對象，跟風站隊的澳大利亞、新西蘭、英國也跳出來抵制華為，說華為不安全，可能含有間諜軟件，竊聽國家機密，這帽子一扣是很難扯清的！這就是為什么整封信從標題開始，一共 17 次提到兩個關(guān)鍵字：“可信”。

只有讓客戶覺得華為的產(chǎn)品“可信”，華為才能盡快走出這場危機，那么怎么才能做到可信？

如果你是餐廳老板，有人造謠你的廚房臟亂差，員工上完廁所不洗手，你怎么辦？最好的辦法自然是用先進的管理流程，并且讓整個做菜的過程盡可能公開透明。

所以信中有這樣一句話：

我們要轉(zhuǎn)變觀念，追求打造可信的高質(zhì)量產(chǎn)品，不僅僅是功能、特性的高質(zhì)量，也包括產(chǎn)品開發(fā)到交付過程的高質(zhì)量。

要轉(zhuǎn)變觀念，不再只認結(jié)果的質(zhì)量，還要追求過程質(zhì)量了！而如何追求過程質(zhì)量呢？那就是要：“全面提升軟件工程能力和實踐”

如果信到此為止，也就是個普通官方八股文了。領(lǐng)導們么，可不就是喜歡指個大方向，說你們要用軟件工程，要實施軟件工程，至于怎么用，那是你們的事情，畢竟做領(lǐng)導的哪有幾個真的懂軟件工程的，難得的是這封信居然有很多具體怎么做的內(nèi)容。

軟件項目管理金三角

先看這一句：

我們各級管理者和全體員工都不得以進度、功能、特性等為理由來降低可信的要求，確?？尚诺囊笤趫?zhí)行過程中不變形。

振聾發(fā)聵呀同志們，熱淚盈眶呀！生活中多少次：三個月的項目老板說你一個月就要給我做完；做到一半的項目，PM 說這個功能很重要，我們要加上去。最終怎么辦？犧牲質(zhì)量唄！又想要馬兒跑得快又想要馬兒不吃草，天底下哪有那么好的事情！

軟件工程里面早就告訴我們了：時間、范圍、成本這三個要素直接決定了產(chǎn)品的質(zhì)量！

?希望各位老板別光學喬布斯，也學學任正非！

程序開發(fā)

2018年底程序員被裁的不少，很多程序員開始擔憂起前景來，其實如果你能做到這下面要求的應該是不擔心被裁的！

我們要從最基礎的編碼質(zhì)量做起，視高質(zhì)量代碼為尊嚴和個人聲譽。代碼就像是高樓大廈的一磚一瓦，沒有高質(zhì)量的代碼，可信的產(chǎn)品就是空中樓閣。我們要優(yōu)化并遵循公司各種編程規(guī)范，遵從架構(gòu)與設計原則，熟練使用各種編程庫和API，編寫出簡潔、規(guī)范、可讀性強、健壯安全的代碼。

這一段是說給我們程序員看的，這其實也是對程序員的基本要求，大家看看自己，看看身邊，真能做到的有多少？像我一樣覺得自己還做的不夠好的，咱還是努力學習吧，多練練，多用點心肯定更沒問題的。

架構(gòu)

說完程序員開始說架構(gòu)師了：

我們要深刻理解架構(gòu)的核心要素，基于可信導向來進行架構(gòu)與設計。

看到?jīng)]有，又提到可信了，架構(gòu)設計的時候，別再天馬行空，啥新酷用啥，啥流行用啥，一定要“可信導向”，架構(gòu)設計目標先搞清楚！

再是細節(jié)：

在確?？尚诺那疤嵯?，要在性能、功能、擴展性等方面做好權(quán)衡；慎重地定義我們的模塊與接口，真正做到高內(nèi)聚與低耦合；我們要遵循權(quán)限和攻擊面最小化等安全設計原則，科學設計模塊之間的隔離與接口，提升安全性；低階架構(gòu)與設計要遵循高階的架構(gòu)與設計原則，在充分理解原有架構(gòu)與設計的情況下，持續(xù)優(yōu)化；我們要熟悉各種設計模式，重用公共成熟組件和服務，避免重復勞動。

“高內(nèi)聚與低耦合”，“權(quán)限和攻擊面最小化”，“模塊之間的隔離與接口”，“重用公共成熟組件和服務”……道理我都明白，做到可不容易！

技術(shù)債務

華為這些年高速發(fā)展，早些年為了追求速度肯定也沒少走捷徑，這些年下來也肯定沒少欠技術(shù)債務，現(xiàn)在也是一個從追求速度到追求質(zhì)量轉(zhuǎn)型的契機。所以信中說完架構(gòu)開始講技術(shù)債務了：

我們要重構(gòu)腐化的架構(gòu)及不符合軟件工程規(guī)范和質(zhì)量要求的歷史代碼。我們知道，再好的架構(gòu)，其生命力也是有限的。隨著時間的推移、環(huán)境的變化以及新技術(shù)、新功能特性的引入，架構(gòu)也會腐化。面對腐化了的架構(gòu)，要毫不猶豫地去重構(gòu)它。同時主動以可信設計原則為導向，去重構(gòu)不符合軟件工程規(guī)范和質(zhì)量要求的歷史代碼，提升軟件架構(gòu)的生命力。

我們都知道，沒有萬能的架構(gòu)，只有適合當時需求，當時技術(shù)條件和人員的架構(gòu)，時間推移了很多架構(gòu)就滿足不了要求了，就需要重構(gòu)了！作為80后，小時候其實生活挺艱苦的，那時候我們穿衣服都講究的是：“新三年，舊三年，縫縫補補又三年”，架構(gòu)也一樣嘛，不滿足需求我們先修修補補，真要重構(gòu)挑戰(zhàn)還是不小的，但是不去做它會一直成為發(fā)展的一個障礙，這封信也算是推了一把：“面對腐化了的架構(gòu)，要毫不猶豫地去重構(gòu)它?！?，當然你重構(gòu)，也不要忘記“可信”這個根本目標：“同時主動以可信設計原則為導向”。

其實Google在這方面已經(jīng)走在前面了，一直鼓勵重寫代碼，任何軟件每隔幾年就重寫一遍，這樣可以優(yōu)化代碼，采用最新技術(shù)，去掉一些沒有價值的功能，最重要的是讓新員工得到鍛煉，保持高昂的斗志。不知道這點是不是華為在像Google學習！

安全

這些年，互聯(lián)網(wǎng)發(fā)展很快，但是安全事故卻層出不窮：開房記錄被泄漏、密碼被泄漏、比特幣被盜……這暴露出業(yè)界其實對安全是不夠重視的，所以信中也不止一次提到安全問題：

公司已經(jīng)明確，把網(wǎng)絡安全和隱私保護作為公司的最高綱領(lǐng)?！?/p>

“我們要深入鉆研軟件技術(shù)，尤其是安全技術(shù)?！?/p>

“我們要遵循權(quán)限和攻擊面最小化等安全設計原則，科學設計模塊之間的隔離與接口，提升安全性”

“編寫出簡潔、規(guī)范、可讀性強、健壯安全的代碼。

要打造一個“安全”的軟件，就是首先要有安全意識，然后要懂安全技術(shù)，在整個開發(fā)過程中要從架構(gòu)設計、代碼方方面面去注意。

技術(shù)是工具

這些年開發(fā)界一直有些不好的風氣，就是都認為自己的技術(shù)是最牛的，寫后端的看不上前端的，用angular的看不上vue，寫PHP的認為自己的語言是全世界最好的，開發(fā)的還看不上測試的。但是信中這一句話不要忽視呀：“軟件技術(shù)是我們打造產(chǎn)品的基本工具”，技術(shù)只是工具，只是我們用來打造產(chǎn)品的工具！

“技術(shù)是否先進，技術(shù)選擇是否合理，將決定我們軟件的高度；”，技術(shù)的選型，不僅看的是不是先進，還要看是不是適合當前產(chǎn)品項目，并不是什么什么新酷就用什么！

“我們要深入學習架構(gòu)與設計、編碼、測試、安全、可用性、性能、維護性、體驗等技術(shù)，并科學運用這些技術(shù)?！?，既然技術(shù)只是工具，那么我們就沒必要給自己設置各種技術(shù)壁壘障礙。如果開發(fā)就只學編碼，測試就只學測試，認為安全那應該是搞安全的事，這樣的話是非常不利于團體協(xié)作的，每個人都在一個領(lǐng)域能有深入的鉆研，同時對其他領(lǐng)域有一定了解，對個人，對團隊是非常有利的一件事。這樣也不需要DevOps這種為了兼顧開發(fā)、測試、運維三種角色而存在的工種！

一致性

我們做軟件開發(fā)的都知道，也看過很多段子：從客戶的需求，到最終的實現(xiàn)，總是差別很大；我們在項目初始的時候制定了很多規(guī)范，卻總是不了了之，難以執(zhí)行；我們良好的設計，在編碼實現(xiàn)的時候，因為趕進度、開發(fā)人員偷懶等各種原因繞開設計，抄近路，最后設計和編碼無法一致……

一致性在軟件開發(fā)領(lǐng)域一直都是理想美好而現(xiàn)實卻很殘酷，信中也提到：

我們要遵守過程的一致性。遵守適用的法律法規(guī)、遵循業(yè)界共識的標準、規(guī)范，確保規(guī)范到實現(xiàn)的一致性、代碼到二進制的一致性。架構(gòu)要符合架構(gòu)原則，設計要遵循設計模式，代碼要符合編程規(guī)范，最終做到需求與實現(xiàn)一致，達成各項對客戶的承諾。我們只有腳踏實地做好每一步，才能真正打造出可信的高質(zhì)量產(chǎn)品。

無論這個目標有多難，但是從“遵守過程的一致性”開始，在每個階段都去做到一致性，“腳踏實地做好每一步”，還是有希望做到，“真正打造出可信的高質(zhì)量產(chǎn)品”。

改變習慣

在實施軟件工程的過程中，有兩個難題，一個就是轉(zhuǎn)變思想，另一個就是改變習慣了，這種改變的過程也一定是很痛苦的。

為此，我們要改變行為習慣，追求精品。我們要開放透明、積極和勇于揭示問題并主動推動改進。軟件開發(fā)是一種創(chuàng)造性和藝術(shù)性的工作，需要充分發(fā)揮我們的聰明才智和潛力。我們要改變只重視功能結(jié)果、不重視代碼質(zhì)量的行為習慣，要嚴格遵守軟件工程規(guī)范；改變被動的修修補補；改變碎片化知識獲取，主動去學習提升并貢獻經(jīng)驗、代碼，形成共享知識庫。我們需要改變的行為和習慣還有很多，對絕大多數(shù)人來講都將是一個痛苦的轉(zhuǎn)變過程，會脫一層皮，但我相信大家能夠迎接這種挑戰(zhàn)。

從事軟件開發(fā)工作越久，恐怕養(yǎng)成的壞習慣就越多，信中列的幾條都很有代表性：

• “只重視功能結(jié)果、不重視代碼質(zhì)量”
  “功能實現(xiàn)完了就完事了，質(zhì)量那是QA的事”，這種壞習慣不改質(zhì)量是很難有保障的

• “不遵守軟件工程規(guī)范”
  軟件工程的各種規(guī)范不是約束，也不是擺設，而是實實在在為了團隊整體更好的協(xié)作。對于定好的規(guī)范，要嚴格執(zhí)行，不合理的規(guī)范，也要提出來一起改進。

• “被動的修修補補”
  為了能繼續(xù)湊合，繼續(xù)修修補補，而沒有考慮重構(gòu)改進，也是一個不好的習慣。

• “碎片化知識獲取，不主動去學習提升”
  在現(xiàn)在的信息時代，碎片化的知識獲取是容易的，但是像軟件工程這種知識，僅僅通過碎片化的學習還是不夠的，必須的主動的，系統(tǒng)的去學習，雖然這個過程會很辛苦，但是是非常有必要的。

• “不愿意貢獻經(jīng)驗、代碼，不去形成共享知識庫”
  很多人不愿意去分享知識和經(jīng)驗，有的是因為太懶，有的是覺得沒什么好處。但是分享本身就是一個學習和提升的最好手段！知識庫這種事不僅是對別人，對自己也是一個特別好的過程。
  想象下你新加入一個團隊，如果這個團隊有很好的知識庫，你可以通過知識庫很快的上手工作，同樣的，如果你把你的經(jīng)驗寫到知識庫，后面的新人也可以受益你的貢獻！

“軟件工程”和“質(zhì)量工程”需要依靠架構(gòu)技術(shù)

“軟件工程”和“質(zhì)量工程”需要依靠架構(gòu)技術(shù)，而不是依靠CMM和QA管理流程。一切工程問題，首先要思考能否通過技術(shù)解決，當前技術(shù)無法解決的問題，暫時由管理手段代勞，同時不停止尋找技術(shù)手段。

所有的涉及到人的管理最終都要歸結(jié)到人管理還是制度管理的問題上，軟件項目管理也不例外，如果過多的依賴于人的管理，那么項目經(jīng)理的職責就太重了，優(yōu)秀的項目經(jīng)理本身就是稀缺資源，最終會變成一個瓶頸。

所以通過架構(gòu)技術(shù)和工具，把管理流程落實下來是一個非常好的方式。有兩個例子可以很好的說明這點。

早些年軟件項目團隊是非常龐大的，各個服務龐大模塊緊密，所以管理成本很高，后來微服務這種架構(gòu)提出后，將大的服務拆成小的服務，整個組織也從大項目部門拆分成各個小組，各小組可以獨立更新維護。

另一個例子是以前單元測試和代碼審查還有自動部署很難執(zhí)行，后來借助源代碼管理工具和CI（Continuous integration，持續(xù)集成）工具，就可以很容易的進行代碼審查、并且可以確保單元測試測試跑通過后才進行部署。這一點其實信中也有體現(xiàn)：

我們將全面強化以Committer角色為核心的代碼審核和提交機制，代碼經(jīng)過更加嚴格和系統(tǒng)的審核才能合入版本。為此我們將建立一支更高水平的Committer角色群體，負責軟件架構(gòu)的看護、代碼的審核和提交，整體保障合入代碼的高質(zhì)量。我們要變革考核機制，要讓架構(gòu)設計好、代碼寫得好的人脫穎而出，對編程能力不滿足要求的人給予幫助和培訓。但任何人如果編寫的代碼長時間不能合入版本，將會被團隊拋棄。

軟件工程就像一個國家的農(nóng)業(yè)

軟件工程就像一個國家的農(nóng)業(yè)，是最基礎的設施！

很感動，這些年軟件工程被提起的其實不多，大家關(guān)注的更多是各種新酷的技術(shù)，而對于這種軟件開發(fā)最基礎的理論視而不見。還有人一提到軟件工程，就馬上說軟件工程不是銀彈。軟件工程從來不說自己是銀彈，就像現(xiàn)代醫(yī)學，也不會號稱自己包治百病，只會不斷改進，對癥下藥！