“軟件工程”是個老話題了，我以前寫過一篇文章《名不副實的“軟件工程”》，當時還引起了不小的爭議。回頭看，當時更多的思考還是在“軟件工程”本身。我們完全可以把討論的範圍擴得更大一些：“軟件工程”和“工程”有關嗎？如果有，到底有多大的關係？（這裡的“軟件”泛指IT的各種開發，不存在“軟件”和“互聯網”的分別。）
不要以為這些問題很好回答。在大學裡，“計算機/軟件開發”專業到底屬於理科還是工科？似乎一直沒有明確答案。到了社會上，一說起“計算機/軟件”，很多人都覺得它既不同於文科，也不同於傳統的“工程”（硬件）。
那麼，“軟件工程師”和“程序員”究竟有什麼區別？似乎一直也沒有人說清楚，只是名稱不一樣。就我所知，不少搞軟件開發的人認為，軟件是全新的領域，應當有全新的知識體系和工作範式，所以學校教育根本沒啥用。甚至，有些人在內心看不上傳統的工程人員，認為那都是“夕陽行業”的過時經驗。
“軟件工程”真的有這麼特殊，可以大喊“我們不一樣”嗎？中國歷史上有過“白馬非馬”的辯論，“軟件工程”和“工程”之間也是這種關係嗎？
下面結合軟件工程，講幾個“傳統”工程的故事。如果你也好奇“軟件工程”和“工程”的關係，相信可以得到啟發。
工程與理論
在軟件開發的行業，大家爭論不休的問題之一是：數學對於軟件工程師到底重要還是不重要。或者更泛化一點：數學、算法、計算機體系結構等理論知識，對於軟件工程師到底重要還是不重要。
許多人的答案是“不重要”，並且有現身說法：你看我，工作這麼多年，學校學的東西早都忘記了，我不是一樣在寫代碼，交付各種業務功能嗎？沒有理論，並不影響我工作。
說“重要”的也有許多人（我也在內）。理由是：軟件雖“軟”，背後卻是有嚴密的邏輯體系做支撐的。如果凡事都要靠經驗、靠試驗去得到結論，那麼成本未免也太高了。
這裡不爭論這個問題，讓我們看看土木工程的故事。
在那個年代，三位數學家的診斷方法和結論都引發了巨大的爭議，因為這違背了無數工匠的經驗和直覺，他們都積累了豐富的建築經驗。按照三位數學家的結論，拱頂的箍環承受不了水平的推力，必須新增三個帶鏈條和鐵釘的鐵環，才能確保建築的完整。
最終，三位數學家的建議被採納了。今天如果你去羅馬，仍然可以看到完整的聖彼得大教堂。
土木工程師兼歷史學家斯特勞布評論說：這份報告在土木工程史上有劃時代的意義……重要性在於，與所有的傳統和常規相反。從此，所有人都明白了，對建築結構的穩定性的勘測，不應該建立在經驗規則和靜態感覺的基礎之上，而是應當基於科學的分析和研究。
從此大家也相信，建築不再是一門“手藝”，要想建造更復雜、更偉大的建築，誰也離不開科學和研究。今天，如果土木工程師開展工作不依照模型、理論、計算，而是完全按照經驗和直覺，哪怕他的經驗再豐富，也不能稱為“工程師”。
工程與規模
在軟件發行業，“規模”其實是繞不過去的話題。
今天仍然有許多工程師，對“工業開發”的理解就是“改改網絡上現成的示例代碼”，以及“寫一段在本地運行沒有問題”的代碼。軟件開發人員跟人吵架時有句著名的託詞：“你看，在我這是好的”，這可以算是背後的心理根源。
實際上，“在本地運行，實現指定功能，得到正確結果”的代碼很容易。同樣的功能，要在成千上萬臺服務器上運行，每天運行成千上萬遍，挑戰就截然不同。這種挑戰極富技術含量，值得特別重視。
不信的話，讓我們換個角度，看看化學工程的故事。
19世紀直到20世紀早期，德國的化學工業都是相當發達的，遠遠領先世界各國。這是化學工業的早期，在這個階段，把化學反應從實驗室按比例擴大到工業生產的工作，是由與機械工程師合作的化學家完成的。對德國人來說，這種合作方式相當滿意，部分原因在於，他們精通複雜產品。這些複雜、專業、高價值的產品，需要複雜的化學知識，而不是科學技術。用途也限於高價值領域，所以規模並不是問題。
據統計，德國1913年一共生產了13.7萬噸染料，涵蓋上千個品種，其相對高昂的價格能夠帶來足夠的收益，足夠讓德國的化工企業維持運轉。
作為對比，在同一年，美國僅硫酸就生產了225萬噸。美國的化學工業，考慮更多的不是如何精工細作，而是如何利用已有的化學知識，藉助更多的工程技術，按比例擴大到巨大的生產規模。
於是，工業化學家誕生了。他們不是把每種生產看成一套單元，而是將其解析為多個構成部分，並根據其效用概括出一般結論。許多具體的操作，例如增壓和蒸餾，並不屬於嚴格意義上的化學領域，也受到了當時一些“化學家”的鄙視。但是，化學工程師對此毫不在乎，堅持認為這些問題值得科學家關注，因為這些單元操作是化學反應從實驗室規模躍升到工業水平的主要難關。從中暴露出來的各種問題，恰恰是化學工業需要面對和重視的。
1923年，沃克、劉易斯、麥克亞當斯在《化學工程學原理》中寫道：所有重要的單元操作都有許多共通之處，如果領會了理性設計和操作基本類型的工程設備所取決的內在原理，那麼它們能成功應用於製造工業流程，就不再是碰運氣的事情了。
培養工業化學家、發展化學工程學、追求規模的結果是，美國的化學工業迎頭趕上，甚至超過了德國。今天，眾多國際知名的化工和製藥企業都位於美國。
工程與用戶
軟件工程師和用戶之間的矛盾，能引發經久不息的討論。
矛盾的場景往往大同小異：軟件工程師抱怨用戶智商太低、知識太少、腦子轉得慢、看不懂說明書，所以玩不轉高科技的系統；用戶抱怨軟件工程師不說人話，做出來的系統不人性化，不符合直覺。
其它行業的工程師也會遇到這樣的問題嗎？他們是如何解決的？我們看看船舶工程的故事。
人類很早就發明了用來掌控船舶前進方向的船舵。哪怕是沒有操船經驗的人，也很容易感覺到船舵的操作和船舶前進方向之間的關係。稍微加以訓練，就可以基本掌握船舵的操作，保持船舶前進的穩定性。
但是在蒸汽船興起之後，麻煩出現了。對於排水量達到幾千噸的船隻，靠手工轉動船舵已經難以為繼，當時的軍艦在全速行駛時，僅僅轉動扳動船舵就需要上百人。藉助蒸汽的力量轉動船舵當然是很容易的事情，但僅僅機械地“轉動船舵”是不夠的，因為蒸汽不懂得舵手的意志，舵手也沒法獲得直觀的反饋，精確船舶前進方向就成為空談。
船舶工程師們不能抱怨舵手“不懂技術、跟不上時代”，強迫他們“必須學習”，而是必須想出辦法，讓船舵能夠聰明、靈敏地響應舵手的操作，不能機械死板地擺動。
1866年，蘇格蘭工程師麥克法蘭·格雷（J. Macfarlane Gray）發明了具有反饋控制功能的操舵引擎（Steering Engine，今天叫“舵機”）並獲得了專利。這種發動機率先安裝在排水量18915噸的Great Eastern號上，其控制機械能精確跟蹤、匹配舵輪的變化，根據船舵的反饋持續修正。有了舵機，舵手才能真正操控船舵，準確把握船隻的前進方向。
這種大獲成功的自動控制器被稱做“伺服機構”（servomechanism），其名稱源自拉丁文servo，意思是“奴隸”或者“僕人”，它不只是機械執行操作者的意志，而是可以形成閉環，根據實際情況不斷反饋修正，確保實現使用者設定的目標。今天，伺服機構已經被廣泛應用於各種設備。今天的每一臺數碼相機上，你都可以找到“伺服”對焦模式。
工程與生產
我不知道有多少軟件工程師真正去過生產線，但我記得我第一次去到生產車間的感受。
面對著生產線、工位、SOP、物料管理……，我感到震撼。以前我總覺得軟件開發複雜，但現實的生產一點也不比軟件開發簡單。尤其是看到自己開發的軟件被一線用戶真正實用的時候，之前的各種不理解、委屈、抱怨，似乎全都洩了氣。從此我深刻理解了，“深入生產一線”到底是什麼，它有什麼用。
其實不只對軟件工程，對任何高科技工程來說，“深入生產一線”的重要性，怎麼強調都不為過。作為例子，我們可以看看航空工程中的故事。
在航空業大名鼎鼎的“臭鼬工廠”（Skunkworks）是洛克希德公司高級開發項目的官方綽號，由著名飛機設計師克里·約翰遜（Kelly Johnson）創立於1943年。臭鼬工廠以擔任秘密研製任務著稱，先後研製了升限2.4萬米的U-2高空偵察機、空速3馬赫的SR-71偵察機、史上第一架隱身轟炸機F-117等著名飛機。
臭鼬工廠研製出這麼多了不起的飛機，當然聚集了一批了不起的工程師。這些工程師是不是”關起門來攻關“呢？不是。按照約翰遜的規定，工程師在設計過程中，每一個步驟都必須經過反覆的商討和推敲。一旦工作中遇到問題，他們需要與試飛員、機械車間工人、管理人員緊密合作，共通面對。
約翰遜還為臭鼬工廠設定了若干基本規則，其中有兩條是：第一，工程師應當守候與機械車間不應當超過“扔石頭能打到的距離”；第二，“壞消息傳到高層的速度必須和好消息一樣快”。在實際工作中，這兩條規則執行得相當好，設計工程師每天上班至少要花1/3的時間在生產車間待命。
不同職能、不同團隊的緊密協作，呈現出強有力的團隊面貌和高度激勵精神，也形成了多學科、系統化的工作方法，將行政管理上的官僚作風減少到最低限度。員工不會在移交工作之後推卸責任，而是在移交之前拼盡全力。
這樣工作的結果不難想見，突出的例子是F-117。“臭鼬工廠”的F-117隱身轟炸機因為造型太過怪異，一度被行業人士判斷”飛不起來“，事實證明，F-117的性能完全滿足設計需求。
工程與成本
有多少軟件工程師會考慮成本問題？似乎相當部分的軟件工程師沒什麼成本意識。
相當多的軟件工程師在乎的是，寫下代碼，用代碼去實現功能。如果說成本，可能最先想到的是人工成本，也就是寫代碼的時間。至於其它方面的成本，比如運行的資源消耗、維護的難易程度，願意考慮的人並不多。
作為對比，在傳統工程領域，合格的”工程師“大都明白，工程和科學之間的差別。科學問的是”是什麼“和”為什麼“，工程問的是”為了什麼“、”怎樣實現“、”評價好壞的標準是什麼“。正因為這三個問題對工程相當重要，合格的工程師一定清楚意識到，在實現目標價值的情況下，成本越低越好。航天工程的例子，正可以作為註解。
20世紀60年代，美國政府在航天領域持續投入巨資，先後進行了”水星“、”雙子星“、”阿波羅“計劃，將人類送上月球。然而，即便是有天量投入為支撐，航天工程中仍然要時時秉承”節約“的原則。
在阿波羅登月計劃中，指令艙隔熱罩的材料遇到了巨大挑戰。在太空中，它朝向太陽的一面熾熱，背向太陽的一面極冷，重返大氣層時還需要經受極高溫的考驗。如何設計才能解決這個問題，工程師陷入了深深的思索。
最終，工程師們沒有發明某種特異的複雜材料，而是讓指令艙每小時繞自轉軸旋轉一週。在登月往返中，指令艙始終保持這種”翻轉烤肉“的模式，利用太陽的熱量有規律地烘烤，所以再不用考慮低溫的考驗。
儘管航天工程花費巨大，這種”節約成本“的例子卻比比皆是。2003年”哥倫比亞“號航天飛機在返航中失事，事後確認原因是：發射升空過程中，脫落的隔熱瓦撞破了飛機機翼，在重返大氣層過程中，熾熱的氣體灌入飛機內部，最終導致解體。
怎樣發現機身的破損？工程師的辦法並不是給航天飛機全身裝上破損檢測傳感器，而是在返航之前新增一項檢查：航天飛機在返航之前，必須在太空做360度轉體，由太空望遠鏡或空間站觀測，確認機身沒有破損。
工程與人
“軟件工程師”對普通人來說，是怎樣的形象？
看看周圍的媒體就知道，“軟件工程師”（或者叫“程序員”）已經形成了相對固定的刻板印象：木訥、無趣、不善交際、缺乏趣味。軟件工程師似乎默認了這種印象，在自己的亞文化圈子中尋找共鳴。
這種現象，是軟件工程師獨有的嗎？看看工程學的發展就會清楚，“吾道不孤”。
今天的許多人，無論怎麼看工程師，至少都會歸類到“有知識的人”裡。但是在歷史上，“知識”很長時間裡等同於文學、歷史、藝術，與今天大家所說的“知識”有很大不同。
所以，工程師的先驅者們大多都是自學成才的。他們大多來自社會底層，出身學徒，憑藉好奇心和興趣，孜孜不倦地學習，從“工匠”昇華為“工程師”。製造了蒸汽機車的斯蒂芬森是這樣，建造了埃迪斯通燈塔的斯米頓是這樣，愛迪生也是這樣。
因為出身底層，難入上層階級法眼，又清楚學習交流對於促進理解、啟發靈感的作用，工程師們只能自己創建職業協會。英國土木工程師協會成立於1771年，機械工程師協會成立於1846年，德國也在1856年成立了自己的工程師協會，帶動德國綜合技術學校率先上升到大學地位。
行業協會的興起，逐步產生了“工程”專門教育的需求。於是，理工科大學也誕生了。突出的例子就是1794年成立的巴黎綜合工科學校，不僅在工程技術上，而且在一般科學上都是教育突破。在這裡，最優秀的科學家、工程師教授聰明的年輕人各種工程知識。拿破崙甚至希望，在遇到重大危機的緊要關頭，也不要讓學生捲入戰鬥，因為這是“下金蛋的鵝”。
工程技術的飛速發展，重要性不斷提升，改變了普通人的生活，也打破了社會原有的格局。作為回應，原有的“輕視”變成了敵視。工程師們，大概只有兩種形象：一種是科學怪人弗蘭肯斯坦，一種是書呆子、極客。他們不懂高雅藝術、不懂審美、沒有情趣、缺乏交流……
這種印象能站得住腳嗎？起碼工程師們是不贊成的。麻省理工學院工學院創始人威廉·羅傑斯（James Henry Williams, Jr.）在創建新學院的建議中說：
我們提供的教育，雖然就其目的而言價值非凡，但與那種只按經驗慣例進行的教育沒什麼關係；而經驗慣例式的教育，有時被吹噓為對要從事實業來說最合適的教育。相反，我們認為，大多數真正實用的教育，即便按照實業的觀點，也是一種建立在透徹的科學定律與原理的知識基礎上的，而且是一種將縝密觀察、精確推理結合起來的教育，是一種全面的綜合素養。
不只麻省理工學院，已經有越來越多的工程師意識到，工程絕不是冷冰冰的、機械的產物，它一腳踩在科學領地，一腳踏進社會萬象。過分強調一條腿，忽略另一條腿，都是非常危險的。
其實，古代的工匠就已經懂得這個道理，充分懂得並重視人的因素。
古希臘建築大師卡里克拉特要小心翼翼地挑選雅典城牆的承建者，因為他知道城牆的建築並不是簡單機械的勞動。這個故事給普魯塔克留下了深刻的印象，在《希臘羅馬名人傳》裡專門記載。寫下不朽的《建築十書》的古羅馬建築大師維特魯威更是明確說，建築師如果要正確設計建造屋簷和下水道，就必須熟悉城市制定的各種法律法規，懂得並且重視和商界、政界打交道。
現代的優秀工程師也不會忘記這點。普林斯頓大學航天工程畢業，先後在道格拉斯飛機公司擔任研究工程師、總工程師，之後任洛克希德·馬丁公司CEO的諾曼·奧古斯汀（Norman R. Augustine）曾經說過一句話，得到了眾多工程師的認同：合格的工程師，必須能像處理重力和磁力那樣熟練處理社會的和政治的力量。
我知道不少軟件工程師都喜歡稱自己為“手藝人”，都喜歡講“三個石匠“的故事——同樣在幹活，“混飯吃”的石匠一生都在混飯吃，“想做最好石匠”的石匠大概獲得了點名聲，“造大教堂“的石匠最終功成名就。
我以前也喜歡講這個故事，很動聽，但也很給人安慰。後來我終於發現，這個故事的問題就在於，它太簡單了：從來沒有人告訴過第三個石匠，要想造大教堂，可不能專心當石匠，你還得學習很多其它的技能，比如畫圖、計算、選材、算賬、砍價、瞭解天氣和氣候、排生產計劃、檢查質量、化解衝突……
閱讀更多 楓林野叟 的文章
