作者：徐磊

原文地址：https://smartide.cn/zh/blog/2022-1022-software-engineering/

徐磊

英捷創軟科技（北京）有限公司創始?/?席架構師 / CEO / SmartIDE開源項?創始?。微軟最有價值專家MVP，微軟區域技術總監，華為云MVP，認證Scrum Master，EXIN DevOps Master/Professional 認證講師，中國最?的敏捷精益社區IDCF創始?。專注于軟件?程，敏捷精益商業創新??的管理咨詢。客?涵蓋從電信，能源，傳統?產制造，?融和電商等各?業，從2005年?今已經為超過100家企業提供過軟件?程?案的咨詢和服務，包括：華為、中國農業銀?、招商銀?、興業銀?、中國銀?、斯倫?謝、中國聯通、中國??保險、京東商城、通?汽?等。

一直都想寫這樣一篇文章來聊一聊我對軟件工程的看法，粗略算來我從事軟件工程這件事情已經有將近18個年頭。很多人并不理解軟件工程和軟件開發的區別，用一個簡單的類比來說明一下：如果說軟件開發人員是淘金者，那么從事軟件工程的人員就是賣牛仔褲的。是的，軟件工程就是為軟件開發人員提供最好的方法，工具和實踐的學科。要做好軟件工程這件事情首先要做的就是要理解到底什么是軟件開發，必須對自己所服務的對象有正確理解，才能摸清其中的規律，從而為軟件開發人員提供符合自然規律的方法，工具和實踐 — 這個所謂的規律就是我今天想跟大家聊的內容：軟件工程的第一性原理。

第一性原理這個詞被埃隆馬斯克帶火了，其基本含義就是事物的根本性規律，馬斯克經常說自己對物理學很癡迷就是因為物理其實研究的就是世間萬物的根本性規律，從這個規律出發所做出的判斷和決策就是符合規律的，也是一定可以實現的。相反，如果做不符合規律的事情，那么結果就是被各種困境纏繞，無法脫身。所謂的適者生存，就是這樣一個簡單的道理。

但是，符合規律的做法不一定就是簡單方便的做法，事實上一般的情況恰恰相反，符合自然規律的做法往往都更加困難，違背基本的人性。舉個簡單例子，我們都知道要獲得健康的身體就要堅持規律的作息，持續的鍛煉身體并且科學的飲食；而實際的情況是我們總有理由去熬夜，總會在計劃好的鍛煉時間偷懶，高糖高碳水的冰淇淋和蛋糕也永遠比蔬菜沙拉更加吸引我們，這就是人性。

軟件第一性原理第一定律：

? ? ? ? ? 軟件是虛擬的

軟件是一個虛擬物品，這就是軟件工程的第一性原理，認識到這一點你才能正確理解精益敏捷、理解DevOps和持續交付，理解研發效能，理解平臺工程，理解任何為了軟件而存在的方法，工具和實踐。等等，軟件是一個虛擬物品，這不是廢話嗎？是的，只有符合自然規律的描述才能被稱之為廢話，因為這個第一性原理本來就不神秘，本來就在你的身邊。這就好像牛頓的力學定律一樣，說出來你也會覺得是廢話，但是真的要把它解釋清楚，那么你就成為牛頓了。是的，你和牛頓的距離就是一句廢話。

地下室的故事

話說一家知名的房地產大廠有一位具備500年房地產從業經驗的設計師，他設計大樓的經驗年頭甚至都比大樓存在的時間要長那么幾十年。有一次這位設計師來到一座將要竣工的大樓面前，這座樓有50多層，已經進入到內裝修階段了。設計師在仔細檢查了大樓的各項設施之后提出了自己專業的意見，這個大樓需要增加2層地下室。

你一定可以想象在場的項目經理，施工方和工人們驚嚇的目光，感覺自己遇到了一個瘋子。不過，類似的場景其實只是各個軟件/互聯網大廠的日常而已吧，這樣的瘋子每天都見，早就習慣了。

瘋子錯了嗎？

當然沒有，他只是發現了一個“底層”問題，但是并沒有意識到這是個“底層”問題，因為他根本看不到這棟大樓。這就是軟件，一個虛擬的大樓。

作為程序員，大家都懂軟件的分層，數據/邏輯/界面這是基本的三層架構；實際中的軟件往往比這要復雜的多。但是如果你嘗試去給普通人解釋，這將是一件非常有挑戰的工作，恐怕要從Hello World講起。

因為軟件本身是一件虛擬物品，普通人很難通過常識判斷軟件的復雜性以及內部關系，造成嚴重的信息不對稱，這是軟件工程領域的各種問題的原罪！

軟件第一性原理第二定律：

? ? ?軟件只能被制造一次

復制一款軟件和復制一輛汽車的成本是完全不同的，這也是基于第一定律延續。復制一輛汽車需要重新投入原材料，人工和各種生產資料，但是復制一款軟件只需要Ctrl-C加Ctrl-V就夠了。軟件開發團隊所做的事情嚴格來說不是生產制造軟件，而是在設計軟件，因為生產制造是指重復產出同樣的產品，而軟件開發團隊每次產出的都是不一樣的產品。

瀑布模式就是個錯誤

設計是一項創造性活動，創造性活動的目標是無法被預先定義的，其最大的風險是創造了無用的產品，如果方向錯了，所有的努力都只會加速死亡。既然生死未知，計劃的意義何在，你在計劃更好的生，還是計劃更快的死？現實中的表現是軟件經常延期，工作量估算不準確，開發過程經常遇到不可見問題，輕則延期重則推翻重做。這也是瀑布式開發模式為什么從根本上就是錯的，瀑布式開發的一個基本假設就是目標是確定的。

既然瀑布本身就是錯誤，為什么有那么多組織和團隊在使用這種模式呢？其實在本文一開始已經解釋了原因，這就是蔬菜沙拉和奶油蛋糕的區別。瀑布模式雖然不符合軟件工程的基本規律，但是它更加符合懶惰和規避變化的人性特點，因此大家會不自覺的選擇奶油蛋糕。如果再考慮組織中僵化的流程，官僚的氛圍以及各種利益的驅使因素，那么瀑布這種更加容易管理，更省心輕松的方式自然會受到歡迎，至于產出的軟件是否有用，是否浪費了資源，開發人員是否痛苦不堪，這些都不重要。當然，前提是這個組織本身不依賴軟件生存，對于一個數字化的組織或者強烈依賴軟件運作的組織而言，產出無用的軟件這一點就已經足夠驅動他們選擇蔬菜沙拉了。那些選擇了奶油蛋糕的組織早就死于高血脂引發的心血管和腦梗了。

敏捷只是個標簽

倡導迭代式的敏捷開發模式為什么現在被大多數開發團隊認可，原因就是敏捷從根本上承認了軟件開發目標的不確定性，而不像瀑布模式那樣非要去定義一個無法被定義的東西。精益思想里面的核心Build-Measure-Learn強調的也是在目標不確定的前提下，怎樣通過不斷的檢視來識別問題，調整方向，最終達到目標。DevOps的三步工作法 1）建立流和系統化思維 2）建立反饋 3）建立持續實驗和學習的文化，看上去是不是也異曲同工？這些方法和實踐都誕生于軟件工程領域，現在已經在很多非軟件行業使用，其思想根基都是以上所述的軟件第一性原理，都是為了應對客觀規律而被總結出來，又在實際工作中被驗證的方法。

軟件工程的基本工作思路 -?

? ? ? ? ? ? 粒度和解耦

軟件這件事情，現在變得越來越重要。現在火熱的所謂數字化，研發效能，平臺工程，其根本都是在尋找最大化軟件價值的方法而已，只不過關注的層面有所不同。數字化更加關注用戶側和業務價值，研發效能更加關注開發過程，而平臺工程則強調用一個內部開發者平臺（Internal Developer Platform, IDP）來承載具體的方法和實踐。1993年，被稱為是互聯網點火人的馬克安德森（Marc Andreessen）開發出了Mosaic瀏覽器，后來加入網景（Netscape）公司，開創了互聯網時代。可以說，軟件這件事情只有到了互聯網出現以后才真正開始進入普通人的生活。2011年，馬克安德森提出了 軟件正在吞噬世界（software is eating the world） 的說法，同一年的1月21日騰訊推出了一款為智能終端提供的即時通訊軟件，叫做微信。

隨著軟件規模的不斷擴大，早期幾個人就可以搞定的軟件現在需要幾百上千人協同完成，軟件開發過程本身的問題也被放大，變成了影響組織生存發展的大問題。從研發效能的層面，從軟件第一性原理出發，我們需要確保在目標不確定，方法不確定，系統越來越復雜的前提下幫助企業取得成功，其基本思路只有2個：就是粒度和解耦。面對不確定目標最簡單的應對方式就是將復雜問題簡單化，對問題進行拆解，然后逐個攻克。但是在拆解的過程中會帶來一個副作用就是拆解后的單個問題確實簡單了，但是問題的數量增加了，同時不同問題之間的依賴會造成副作用。因此我們需要解耦，采用各種管理和技術手段，讓拆解后的問題可以被獨立解決，而不是依賴其他問題。有關粒度和解耦的話題，請參考我的另外一篇文章 DevOps實施落地的2大法寶——粒度&解耦（點擊查看）

解耦是一個非常難的話題，在軟件工程領域，對這個問題的解決方式就是 基礎設施即代碼 （Infrastructure as Code, IaC）,IaC本身看上去是一個純粹的工程方法/工具，實際其背后隱含了一個重要邏輯，就是如果要降低AB系統耦合，就要從他們依賴中提取共性，然后由第三方C來解決這個問題，如下圖：

如果想詳細了解IaC的概念以及落地方法，請參考我的另外一篇博客 沒有使用IaC的DevOps系統都是耍流氓（點擊查看） 。

軟件工程隨著軟件在我們生活中變得日益重要而開始引起了越來越多人的關注，這個行業也非常善于創造概念，因此你會聽到各種新鮮的詞匯，包括在本文中提到的敏捷，精益，DevOps，平臺工程，研發效能等等。但只要做的還是軟件，就無法背離軟件工程第一性原理的2條定律，記住粒度和解耦，落實IaC的工作方法，你就一定能找到適合自己的模式，應對好自己的問題，在自己的領域中取得成就。

最后還想說一句話：這些方法都會幫助你登上高峰，但一定不是別人的那座。