軟件摩爾定律背后的幾個常識（上）

軟件的“摩爾定律”，是不斷提升軟件生產效率，以降低軟件的開發成本和上市時間。在軟件“摩爾定律”的驅動下，誕生了各種軟件開發的語言、架構、工程和模式。每年都有新的編程語言出現。設計模式，據說已經超過300種。各種眼花繚亂的概念和技術，有些還相互矛盾，真偽難辨。借用政治經濟學的一個說法，符合軟件生產規律的，就促進軟件生產的發展，不符合軟件生產規律的，就阻礙軟件生產的發展。軟件生產的規律是什么？總結了幾點，不敢輕易說是規律，就是常識吧，供大家指正。

減少開發人員之間的等待和依賴

《人類簡史》上說，一個猩猩自然群體中的個體數，一般不超過20-50個。人類，高等一點，增加了八卦等連接力，也不超過150個，再多就要靠文化、制度、意識形態等虛擬的東西來連接了。作為一個軟件開發團體，也不是越大越好。團隊規模越大，開發人員之間的溝通、配合、等待和依賴越多，效率就越低。但開發人員太少也不行，靠什么來解決這個軟件生產上的矛盾呢？

先來回答一個問題，什么是架構？越熟悉的詞，越不好找一個準確的定義，這里拋一個我覺得是最接近的。Architecture一詞最早來自建筑，是在復雜場景下，解決人的分工、溝通和配合問題，以達到更高效率和更高目標。軟件架構就是解決軟件生產過程中人員的分工、溝通和配合問題，以及軟件生命周期中的維護和擴展問題。顯然，解決這個矛盾，架構很關鍵。

架構讓生產人員在技能、工序、配合上充分解耦。蓋一棟樓，先是打地基搭框架的人上，然后是砌墻的人上，最后是裝修的人上。做軟件也一樣，如果每個人能夠在不相互等待和依賴的情況下，把自己負責的部分做好，拼到一起就能Run，那就是最理想的情況。

從模塊化，組件化到服務化，基本也是順著這個思路在發展。一個團隊，接到一個開發任務，先做需求分析，系統分解，每個人分一個模塊，各人先聚焦自己的模塊。在開發階段，基本是可以做到解耦的。但在驗證和運行階段，麻煩就接踵而至。一個模塊的驗證要等待其它相關模塊就緒后才能進行，一個模塊的修改可能會依賴另一個模塊的同步修改，一個模塊的問題可能會導致另一個模塊崩潰。隨著時間的推移，血肉模糊，糾纏不清，無數軟件開發人員的大好青春就耗在這里。

經過血淚教訓，開發人員自然會想到，把一些公共的功能和框架提取出來，做成組件，提前開發并驗證好，確保組件部分沒有問題，然后再基于組件，增加適配代碼去搭建系統。相比初始的模塊化，組件化在效率上肯定有優勢。但組件并不能端到端地獨立驗證和運行，并沒有從根本上解決耦合和依賴問題，組件化本質還是一種模塊化。由于組件共享程度高，依賴大，還容易成為瓶頸。

服務化架構是在此基礎上的進一步發展，不但是在開發階段解耦，而且是在驗證和運行階段解耦。為什么在驗證和運行階段解耦很重要？老開發人員都知道，一個全新系統的開發，耗時最長的往往不是開發階段，而是聯調階段。聯調特別耗時耗力，因為各部分都不能獨立地驗證和運行，需要集成在一起才能驗證和運行，聯調中耗時最多的就是等待。服務化，就是希望每部分盡量都是一個自治的系統，能夠獨立地開發、驗證和運行。一個服務內部的修改不需要其它服務同步修改，一個服務內部的問題對其它服務的影響降到最低，把開發人員之間的配合、等待、依賴和影響降到最低。下面這張圖，可以幫助理解從模塊化到服務化開發模式的區別。

服務化架構（SOA）早就有了，為什么近來微服務很火？道理也很簡單，當前微博比博客流行，微信比信流行。小了之后就能有更多的應用場景。深層次的原因，感興趣的可以去探究。

模塊化，組件化，服務化只是架構的一類模式?；谶m合的場景，盡量減少開發人員之間相互的等待和依賴，就是好架構。

問題的早期暴露和快速修正

寫完一篇作文后就檢查，發現的錯誤立刻修正，效率最高。如果等幾個星期甚至幾個月后再去檢查，靈感和思路全無，效果肯定不好。這是生活中的一個常識，同樣適合于軟件生產。軟件生產很重視代碼Review、UT/IT/ST，生產過程從瀑布模式到迭代模式，這些都是為了問題的早期暴露和修正。但光靠這些還不夠，還是會有缺陷遺留到后端。讓問題在開發過程中早期暴露，快速修正，看似一個常識，但可怕的是，有些開發人員在問題的泥潭中迷失了這個常識，就我們身邊的幾個例子：

1、健康迭代

迭代模式相對瀑布模式的進步，就是問題的早期暴露和修正。如果每個迭代的DI值都很高，那就和瀑布沒有區別，甚至更差（壓縮了前期的Review和DT）?，F在公司所有的產品都號稱迭代，但不健康的迭代開發在基層團隊還非常普遍，我司90%的產品都存在下面幾種亞健康迭代。在進度的壓力下，新需求開發優于問題解決。少數團隊為了讓DI數據不難看，甚至讓測試人員停止測試，掩耳盜鈴。

在迭代快結束時集中解決問題，亞健康

在迭代快結束時試圖解決問題，未達成，很不健康

每個迭代的DI值都很高，極不健康

能夠做到主干持續健康，綠色主干，隨時可發布的產品不到10%。

2、開發人員做SDV

傳統軟件生產分工中，開發人員做Code/DT（UT/IT/ST），測試人員做SDV/SIT/SDV。我2010年帶PDU時，趕上把測試人員納入PDU，當時我就推行開發人員做SDV。出發點只有一個，就是開發人員完成功能驗證后再把代碼交給下個環節，本質也就是問題的早期暴露和快速修正。功能性問題往往阻塞測試，需要一群人來定位，確定是誰的問題，定位出來后，測試再提單，開發人員修改，重新出版本，升級版本，非常影響測試效率。開發人員自己做功能測試，問題小閉環，減少測試阻塞，提升效率?？雌饋砗芎玫氖虑椋菩羞^程中遇到很多阻力，開發人員覺得做了不該做的事情，測試人員覺得被人搶了飯碗?？陀^上也有一些困難，比如開發人員搭SDV驗證環境的效率比較低。但這個目標還是堅持了下來，除了開發人員和測試人員觀念上的改變，軟件工程能力的進步也是一個推動力。持續集成，持續驗證的意識也逐漸深入人心。我不知道現在公司其它產品開發中，能否都做到開發人員自己做功能驗證，把沒有功能性問題的代碼交給測試人員，大家可以自檢一下。

回到出發點，敏捷、健康迭代、持續集成、開發人員做SDV，等等，如果能匹配應用場景，讓問題能早期暴露，快速修正，那就是符合常識的好方法。

春節期間就整理了這些，還有幾點在整理中，下次發表。

軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。