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

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

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

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

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

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

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

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

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

所以信中有這樣一句話：

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

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

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

軟件項目管理金三角

先看這一句：

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

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

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

希望各位老板別光學(xué)喬布斯，也學(xué)學(xué)***！

程序開發(fā)

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

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

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

架構(gòu)

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

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

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

再是細(xì)節(jié)：

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

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

技術(shù)債務(wù)

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

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

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

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

安全

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

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

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

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

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

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

技術(shù)是工具

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

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

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

一致性

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

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

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

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

改變***慣

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

希望這封信能帶動軟件工程在國內(nèi)的更多發(fā)展，也希望我這篇淺顯的文章能幫助大家更好的理解一些軟件工程的概念。