近日任正非的公開信《全面提升軟體工程能力與實踐，打造可信的高質量產品》刷屏了，作為一個軟體工程專業科班出身的軟體開發從業者，自然是引起了我（@寶玉xp）的好奇。仔細閱讀之下確實讓我大吃一驚，看似八股官方文，但細看之下是作者對於軟體工程的理解確實非常深刻，各種專業術語信手拈來，比喻恰到好處。
我對華為的研發其實一直挺好奇的，從傳統的硬體公司，到現在軟硬體齊頭並進，華為手機銷量都已經超過了蘋果，可見華為的軟硬體研發實力早已是全球領先了。公開信中的這一句：
二十年前的 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角色群體，負責軟體架構的看護、程式碼的稽核和提交，整體保障合入程式碼的高質量。我們要變革考核機制，要讓架構設計好、程式碼寫得好的人脫穎而出，對程式設計能力不滿足要求的人給予幫助和培訓。但任何人如果編寫的程式碼長時間不能合入版本，將會被團隊拋棄。
軟體工程就像一個國家的農業
軟體工程就像一個國家的農業，是最基礎的設施！
很感動，這些年軟體工程被提起的其實不多，大家關注的更多是各種新酷的技術，而對於這種軟體開發最基礎的理論視而不見。還有人一提到軟體工程，就馬上說軟體工程不是銀彈。軟體工程從來不說自己是銀彈，就像現代醫學，也不會號稱自己包治百病，只會不斷改進，對症下藥！
希望這封信能帶動軟體工程在國內的更多發展，也希望我這篇淺顯的文章能幫助大家更好的理解一些軟體工程的概念。