推薦序3

在讀到書中那些經典軟件工程原則的那一刻，我不禁回憶起那塵封已久的學習編程和開發軟件的歲月，看的內容越多，腦海中的影像就越清晰。1995年，我開始攻讀博士學位，論文方向是軟件過程改進，就是研究如何從過程管理的角度來提升軟件質量。關于軟件質量，業界普遍認為有3個決定性要素：人、過程和工具。如何基于這些要素提升代碼的質量和開發效率，是軟件工程研究者和實踐者一直在努力的方向?；仡欉@二十幾年的軟件工程演進歷程，會發現其經歷了很多有趣的變化和反轉。

20世紀90年代中期是軟件過程成熟度模型（CMM）興起的年代，研究者們堅信，好的過程管理可以得到高質量的軟件；反過來講，糟糕的軟件一定沒有好的過程管理。同時“軟件工廠”的概念也大行其道，各種CASE工具層出不窮。我們還進一步提出了以過程為中心的軟件工程環境（PSEE），試圖將CMM和CASE工具整合在一起，以便固化工具和流程，從而把精力放到人身上。但正如Alan在前言中提到的那樣：事情并沒有按照研究者的預期方向發展。我認為，IT技術的高速演進是最重要的原因，新技術和新架構在不斷摧毀研究者費盡千辛萬苦建立起來的各種過程改進標準、各種CASE工具和代碼生成器。

2000年前后，以人為本的“敏捷”運動成為軟件工程領域的新勢力。書中介紹的第131個和第141個原則揭示了背后的原因：好的軟件工程師和差的軟件工程師的研發效率可能差25倍，質量可能差10倍。軟件工程師并不是“新時代農民工”，而是高科技腦力工作者。人超越了過程和CASE工具，重新回到軟件工程的“C位”。但敏捷開發工程師并不等同于早期的軟件英雄：敏捷運動的實踐者們強調的是全能內聚團隊，而非英雄個體。敏捷實踐者們也非常關注流程和工具的作用：重視過程管理的SCRUM最終勝出，2001年出現了第一種持續集成（CI）工具。作為整個過程的親歷者，我非常有幸獲評為敏捷運動杰出貢獻者。正當大家以SCRUM為中心重新構建整套軟件工程體系的時候，寬帶和3G悄然興起，互聯網開始席卷軟件行業。

2005年前后，Web 2.0技術崛起，面向消費者的網上社區、電子商務、社交網絡等開發逐漸成為主流。2009年，4G通信網絡商用進一步推動了“互聯網+App”的開發模式。激烈競爭使從持續集成（CI）演進而來的持續交付（CD）開始在2010年前后興起。2017年，中國率先制定DevOps的評定標準并開展評定，研發和運維從此接軌。DevOps和敏捷開發的最大區別在于：工具鏈成為軟件工程管理的核心，過程和工具鏈配套，軟件工程師利用工具鏈提升開發效率和質量。與此同時，成熟的軟件框架讓內聚和耦合原則不再重要，復用成為主旋律。

從以過程為中心到以人為中心，再到以工具鏈為中心，這些年軟件工程經歷了令人眼花繚亂的變革。未來，軟件新技術、新架構和新業務還會不斷涌現，軟件工程仍然會變革，但不變的是Alan這本書中介紹的201個原則。

錢嶺

中國移動云能力中心首席科學家

2021年8月17日