從軟件工程的角度解讀任正非的新年公開信

時間 2019-11-05

標籤軟件工程角度解讀新年公開信简体版

原文原文鏈接

昨天被任正非的那封《全面提高軟件工程能力與實踐，打造可信的高質量產品》的公開信刷屏了，做爲一個軟件工程專業科班出身的軟件開發從業者，天然是引發了我（@寶玉xp）的好奇，仔細閱讀之下確實讓我大吃一驚，看似八股官方文，但細看之下是做者對於軟件工程的理解確實很是深入，各類專業術語信手拈來，比喻恰到好處。前端

我對華爲的研發其實一直挺好奇的，從傳統的硬件公司，到如今軟硬件齊頭並進，華爲手機銷量都已經超過了蘋果，可見華爲的軟硬件研發實力早已經是全球領先了。信中的這一句vue

二十年前的IPD變革，重構了咱們的研發模式，實現了從依賴我的、偶然性推出成功產品，到制度化、持續地推出高質量產品的轉變。

也揭示了華爲的軟件研發能作到領先水平的緣由。程序員

華爲是在1999年開始從IBM引進IPD的，到今年2019年正好20年，在過去的20年裏，IPD幫助華爲從游擊隊變成了正規軍，研發隊伍從幾千人到幾萬人，軟件產品也覆蓋到手機操做系統、應用、雲服務。編程

我對IPD是不甚瞭解的，只知道IPD（Integrated Product Development，集成產品開發）是一種產品開發方法，但若是說軟件產品的開發方法，我是比較熟悉的，那就是軟件工程麼！後端

任正非發出的這封信的大背景也很特殊，2018年中美貿易戰開始，中興、華爲首當其衝成爲美國開刀的對象，跟風站隊的澳大利亞、新西蘭、英國也跳出來抵制華爲，說華爲不安全，可能含有間諜軟件，竊聽國家機密，這帽子一扣是很難扯清的！這就是爲何整封信從標題開始，一共17次提到兩個關鍵字：「可信」。設計模式

只有讓客戶以爲華爲的產品「可信」，華爲才能儘快走出這場危機，那麼怎麼才能作到可信？安全

若是你是餐廳老闆，有人造謠你的廚房髒亂差，員工上完廁所不洗手，你怎麼辦？最好的辦法天然是用先進的管理流程，而且讓整個作菜的過程儘量公開透明。網絡

因此信中有這樣一句話：架構

咱們要轉變觀念，追求打造可信的高質量產品，不只僅是功能、特性的高質量，也包括產品開發到交付過程的高質量。

要轉變觀念，再也不只認結果的質量，還要追求過程質量了！而如何追求過程質量呢？那就是要：「全面提高軟件工程能力和實踐」運維

若是信到此爲止，也就是個普通官方八股文了。領導們麼，可不就是喜歡指個大方向，說大家要用軟件工程，要實施軟件工程，至於怎麼用，那是大家的事情，畢竟作領導的哪有幾個真的懂軟件工程的，可貴的是這封信竟然有不少具體怎麼作的內容。

軟件項目管理金三角

先看這一句：

咱們各級管理者和全體員工都不得以進度、功能、特性等爲理由來下降可信的要求，確保可信的要求在執行過程當中不變形。

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

軟件工程裏面早就告訴咱們了：時間、範圍、成本這三個要素直接決定了產品的質量！

點擊此處添加圖片說明文字

但願各位老闆別光學喬布斯，也學學任正非！

點擊此處添加圖片說明文字

程序開發

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

咱們要從最基礎的編碼質量作起，視高質量代碼爲尊嚴和我的聲譽。代碼就像是高樓大廈的一磚一瓦，沒有高質量的代碼，可信的產品就是空中樓閣。咱們要優化並遵循公司各類編程規範，聽從架構與設計原則，熟練使用各類編程庫和API，編寫出簡潔、規範、可讀性強、健壯安全的代碼。

這一段是說給咱們程序員看的，這其實也是對程序員的基本要求，你們看看本身，看看身邊，真能作到的有多少？像我同樣以爲本身還作的不夠好的，咱仍是努力學習吧，多練練，多用點心確定更沒問題的。

架構

說完程序員開始說架構師了：

咱們要深入理解架構的核心要素，基於可信導向來進行架構與設計。

看到沒有，又提到可信了，架構設計的時候，別再天馬行空，啥新酷用啥，啥流行用啥，必定要「可信導向」，架構設計目標先搞清楚！

再是細節：

在確保可信的前提下，要在性能、功能、擴展性等方面作好權衡；慎重地定義咱們的模塊與接口，真正作到高內聚與低耦合；咱們要遵循權限和攻擊面最小化等安全設計原則，科學設計模塊之間的隔離與接口，提高安全性；低階架構與設計要遵循高階的架構與設計原則，在充分理解原有架構與設計的狀況下，持續優化；咱們要熟悉各類設計模式，重用公共成熟組件和服務，避免重複勞動。

「高內聚與低耦合」，「權限和攻擊面最小化」，「模塊之間的隔離與接口」，「重用公共成熟組件和服務」……道理我都明白，作到可不容易！

技術債務

華爲這些年高速發展，早些年爲了追求速度確定也沒少走捷徑，這些年下來也確定沒少欠技術債務，如今也是一個從追求速度到追求質量轉型的契機。因此信中說完架構開始講技術債務了：

咱們要重構腐化的架構及不符合軟件工程規範和質量要求的歷史代碼。咱們知道，再好的架構，其生命力也是有限的。隨着時間的推移、環境的變化以及新技術、新功能特性的引入，架構也會腐化。面對腐化了的架構，要絕不猶豫地去重構它。同時主動以可信設計原則爲導向，去重構不符合軟件工程規範和質量要求的歷史代碼，提高軟件架構的生命力。

咱們都知道，沒有萬能的架構，只有適合當時需求，當時技術條件和人員的架構，時間推移了不少架構就知足不了要求了，就須要重構了！做爲80後，小時候其實生活挺艱苦的，那時候咱們穿衣服都講究的是：「新三年，舊三年，縫縫補補又三年」，架構也同樣嘛，不知足需求咱們先修修補補，真要重構挑戰仍是不小的，可是不去作它會一直成爲發展的一個障礙，這封信也算是推了一把：「面對腐化了的架構，要絕不猶豫地去重構它。」，固然你重構，也不要忘記「可信」這個根本目標：「同時主動以可信設計原則爲導向」。

其實Google在這方面已經走在前面了，一直鼓勵重寫代碼，任何軟件每隔幾年就重寫一遍，這樣能夠優化代碼，採用最新技術，去掉一些沒有價值的功能，最重要的是讓新員工獲得鍛鍊，保持高昂的鬥志。不知道這點是否是華爲在像Google學習！

安全

這些年，互聯網發展很快，可是安全事故卻層出不窮：開房記錄被泄漏、密碼被泄漏、比特幣被盜……這暴露出業界其實對安全是不夠重視的，因此信中也不止一次提到安全問題：

公司已經明確，把網絡安全和隱私保護做爲公司的最高綱領。」

「咱們要深刻鑽研軟件技術，尤爲是安全技術。」

「咱們要遵循權限和攻擊面最小化等安全設計原則，科學設計模塊之間的隔離與接口，提高安全性」

「編寫出簡潔、規範、可讀性強、健壯安全的代碼。

要打造一個「安全」的軟件，就是首先要有安全意識，而後要懂安全技術，在整個開發過程當中要從架構設計、代碼方方面面去注意。

技術是工具

這些年開發界一直有些很差的風氣，就是都認爲本身的技術是最牛的，寫後端的看不上前端的，用angular的看不上vue，寫PHP的認爲本身的語言是全世界最好的，開發的還看不上測試的。可是信中這一句話不要忽視呀：「軟件技術是咱們打造產品的基本工具」，技術只是工具，只是咱們用來打造產品的工具！

「技術是否先進，技術選擇是否合理，將決定咱們軟件的高度；」，技術的選型，不只看的是否是先進，還要看是否是適合當前產品項目，並非什麼什麼新酷就用什麼！

「咱們要深刻學習架構與設計、編碼、測試、安全、可用性、性能、維護性、體驗等技術，併科學運用這些技術。」，既然技術只是工具，那麼咱們就不必給本身設置各類技術壁壘障礙。若是開發就只學編碼，測試就只學測試，認爲安全那應該是搞安全的事，這樣的話是很是不利於團體協做的，每一個人都在一個領域能有深刻的鑽研，同時對其餘領域有必定了解，對我的，對團隊是很是有利的一件事。這樣也不須要DevOps這種爲了兼顧開發、測試、運維三種角色而存在的工種！

一致性

咱們作軟件開發的都知道，也看過不少段子：從客戶的需求，到最終的實現，老是差異很大；咱們在項目初始的時候制定了不少規範，卻老是不了了之，難以執行；咱們良好的設計，在編碼實現的時候，由於趕進度、開發人員偷懶等各類緣由繞開設計，抄近路，最後設計和編碼沒法一致……

點擊此處添加圖片說明文字

一致性在軟件開發領域一直都是理想美好而現實卻很殘酷，信中也提到：

咱們要遵照過程的一致性。遵照適用的法律法規、遵循業界共識的標準、規範，確保規範到實現的一致性、代碼到二進制的一致性。架構要符合架構原則，設計要遵循設計模式，代碼要符合編程規範，最終作到需求與實現一致，達成各項對客戶的承諾。咱們只有腳踏實地作好每一步，才能真正打造出可信的高質量產品。

不管這個目標有多難，可是從「遵照過程的一致性」開始，在每一個階段都去作到一致性，「腳踏實地作好每一步」，仍是有但願作到，「真正打造出可信的高質量產品」。

改變習慣

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

爲此，咱們要改變行爲習慣，追求精品。咱們要開放透明、積極和敢於揭示問題並主動推進改進。軟件開發是一種創造性和藝術性的工做，須要充分發揮咱們的聰明才智和潛力。咱們要改變只重視功能結果、不重視代碼質量的行爲習慣，要嚴格遵照軟件工程規範；改變被動的修修補補；改變碎片化知識獲取，主動去學習提高並貢獻經驗、代碼，造成共享知識庫。咱們須要改變的行爲和習慣還有不少，對絕大多數人來說都將是一個痛苦的轉變過程，會脫一層皮，但我相信你們可以迎接這種挑戰。

從事軟件開發工做越久，恐怕養成的壞習慣就越多，信中列的幾條都頗有表明性：

「只重視功能結果、不重視代碼質量」
「功能實現完了就完事了，質量那是QA的事」，這種壞習慣不改質量是很難有保障的
「不遵照軟件工程規範」
軟件工程的各類規範不是約束，也不是擺設，而是實實在在爲了團隊總體更好的協做。對於定好的規範，要嚴格執行，不合理的規範，也要提出來一塊兒改進。
「被動的修修補補」
爲了能繼續湊合，繼續修修補補，而沒有考慮重構改進，也是一個很差的習慣。
「碎片化知識獲取，不主動去學習提高」
在如今的信息時代，碎片化的知識獲取是容易的，可是像軟件工程這種知識，僅僅經過碎片化的學習仍是不夠的，必須的主動的，系統的去學習，雖然這個過程會很辛苦，可是是很是有必要的。
「不肯意貢獻經驗、代碼，不去造成共享知識庫」
不少人不肯意去分享知識和經驗，有的是由於太懶，有的是以爲沒什麼好處。可是分享自己就是一個學習和提高的最好手段！知識庫這種事不只是對別人，對本身也是一個特別好的過程。
想象下你新加入一個團隊，若是這個團隊有很好的知識庫，你能夠經過知識庫很快的上手工做，一樣的，若是你把你的經驗寫到知識庫，後面的新人也能夠受益你的貢獻！

「軟件工程」和「質量工程」須要依靠架構技術

「軟件工程」和「質量工程」須要依靠架構技術，而不是依靠CMM和QA管理流程。一切工程問題，首先要思考可否經過技術解決，當前技術沒法解決的問題，暫時由管理手段代勞，同時不中止尋找技術手段。

全部的涉及到人的管理最終都要歸結到人管理仍是制度管理的問題上，軟件項目管理也不例外，若是過多的依賴於人的管理，那麼項目經理的職責就過重了，優秀的項目經理自己就是稀缺資源，最終會變成一個瓶頸。

因此經過架構技術和工具，把管理流程落實下來是一個很是好的方式。有兩個例子能夠很好的說明這點。

早些年軟件項目團隊是很是龐大的，各個服務龐大模塊緊密，因此管理成本很高，後來微服務這種架構提出後，將大的服務拆成小的服務，整個組織也從大項目部門拆分紅各個小組，各小組能夠獨立更新維護。

另外一個例子是之前單元測試和代碼審查還有自動部署很難執行，後來藉助源代碼管理工具和CI（Continuous integration，持續集成）工具，就能夠很容易的進行代碼審查、而且能夠確保單元測試測試跑經過後才進行部署。這一點其實信中也有體現：

咱們將全面強化以Committer角色爲核心的代碼審覈和提交機制，代碼通過更加嚴格和系統的審覈才能合入版本。爲此咱們將創建一支更高水平的Committer角色羣體，負責軟件架構的看護、代碼的審覈和提交，總體保障合入代碼的高質量。咱們要變革考覈機制，要讓架構設計好、代碼寫得好的人脫穎而出，對編程能力不知足要求的人給予幫助和培訓。但任何人若是編寫的代碼長時間不能合入版本，將會被團隊拋棄。