軟體工程不等於計算機科學

Python部落(python.freelycode.com)組織翻譯，禁止轉載，歡迎轉發。

幾年前，我研究過演算法及其複雜度問題。這個領域特別的清晰，每一個概念都被清楚的定義，每一個結果都建立在先前的證明上。當你研究這個領域的時候，你完全可以放下心來，你所學的東西都與數學嚴絲合縫。即使是像近似演算法和概率演算法這樣不是很完美的結果，人們也對它們的缺陷進行了嚴格的分析。計算的科學中的其他領域，例如網路拓撲學和密碼學也同樣處於這樣一種令人感覺完美的狀態。

現在，我從事軟體工程領域，它則沒有那麼清晰。沒有哪個概念是被精準定義的。結論中充滿了「通常」或者「一般」這樣的字眼。目前的研究對將來可能有幫助，也可能沒有幫助。新的方法經常推翻舊的方法，然後火上一陣子後便會由於其局限性又慢慢變的過時了。人們曾經認為結構化編程是究極答案，隨後轉為第四代編程語言，接下來是面向對象編程，然後是極限編程，現在可能又變為開源編程。

軟體工程就像是戰壕里的士兵。很少多少人僅僅因為這個問題中蘊含的美就去關心 P/NP 問題。計算機領域就是利用計算機來處理問題，這意味著我們需要編寫程序來解決實際問題，然後在一台機器上把程序跑起來。根據邱奇-圖靈猜想，所有的計算機硬體都是等價的。所以當新的計算機架構確定後，計算機科學真正的挑戰在於編寫軟體。我們需要這樣的軟體，它能在有限的時間和預算內，完成我們期望的工作，並且儘可能少出點問題。

雖然有了這樣一個目標，但是依舊有些問題困擾著我（也可能困擾著其他研究人員），那就是為什麼軟體工程不能像其他的計算機領域一樣，存在更加精確嚴格的結論。換句話說就是，有多少軟體設計和軟體架構能夠被正規化、流程化？圖 1 為我們回答了這個問題。

圖 1. 計算機科學中的分割線

紅線上面的話題構成了軟體工程，紅線下面的話題構成了計算機科學。後者的話題具有清晰的且正式的結果。對於計算機科學領域的開放性問題，我們希望新的結論也能夠有正式的規定。這些領域彼此之間也是相關的，例如密碼學基於複雜度，編譯器基於演算法學。更重要的是，我們相信這些領域中已經存在的結論將永遠是真的。

那麼，那條紅線是什麼呢？為什麼沒有一個關於軟體工程的話題位於其下方？這條線是指一種屬性，一種直接涉及人類活動的屬性。軟體工程具有這種屬性，而傳統的計算機科學則沒有這種屬性。人們可以利用那些位於紅線以下的學科的結論，但是這些結論並不以人的意志為轉移。

軟體工程有一個必不可少的部分，那就是人。例如，軟體的可維護性是指人類去理解、發現並修復 Bug 的能力。軟體的可維護性也許會受到一些正規的計算機科學概念的影響，例如軟體控制流圖的循環複雜度。但是其主要還是受人類的影響比較多，受限於人們理解其源代碼意義和目的的程度。像一個軟體系統是否具有很好的可維護性這樣的問題，是不能僅僅靠機器測試來回答的。

同樣的情況適用於軟體安全性問題。研究人員使用了一些正規的方法來研究軟體系統對人類健康和財富的影響。但是在測試的系統中，不考慮人類的這一組成部分的軟體安全性研究不是完整的研究。我們可以想出各式各樣的面談技巧，以便從軟體需求者那裡獲取準確的要求，並且我們可以創造出多種符號系統來記錄我們所了解的東西。但是不論在這方面有多少研究都改變不了一個事實，那就是需求收集經常涉及到與人的交談或者觀察人的行為。有些時候人們跟我們說實話，但是有些時候並不會。有些時候人們可能會為了別的原因而撒謊。有些時候人們可能會真誠的回答問題以便給我們一些正確的信息，但是有些人並不會這麼做。

綜上所述，我們可以得到康奈爾觀點(Connell"s Thesis)：

「由於人類活動的原因，軟體工程永遠不可能成為一門嚴格的科學，並帶有經過實踐檢驗的真理。」

這是一個關於正式（軟體）系統局限性的超數學論斷。我沒有為這個論斷提供證明，也沒有任何證據能證明它正確。但是事實依舊，軟體工程的核心問題也是人類所關注的問題：

1 這個軟體應該用來幹什麼？（需求性、可用性、安全性）

2 軟體的內部是什麼樣子的，是否容易修復或者修改?(架構問題、設計問題、可測量性，可移植性，可擴展性)

3 軟體開發需要多久？（預算問題）

4 如何進行軟體的開發？（編碼問題、測試問題、測量問題、配置問題）

5 如何組織團隊以便高效開發？（管理問題、流程問題、軟體文檔）

以上所有的問題都跟人相關。

本文闡述了為什麼軟體工程如此的困難和模糊。試驗似的方法可能對某個團隊的程序員管用但是對其他的團隊就不適用了。對過去工程的詳細分析可能不會對下個編程項目起到很好的作用。每一個具有革命性的軟體開發工具都有助於開發，但隨後便只是夸夸其談空有虛表。究其原因在於人類本身就是易變的，遇難而退的，不可預測的。

在我拋磚引玉前，我想先說說三種可能的反對意見：

「這個觀點(Connell"s Thesis)只是可以自圓其說而已，只要軟體工程的某些領域能夠被嚴格的解決，人們就可以重新定義軟體工程，從而避免人為因素的干擾。」

這個反對意見有一定的正確性，但是也有其局限性。我敢肯定，那些通常被稱為軟體工程的學科將繼續從本質上不服從所謂嚴格的解。從局部來看，一些問題可能存在正式且嚴格的解決辦法，但是我認為這種的嚴格解僅僅只存在於軟體工程中心問題的邊緣地帶。

「軟體工程中的概率論結果已經反駁了這一觀點。」

像功能點計數問題（Function Point Counting），第二代構造性成本模型（COCOMO II），PROBE 方法 和其他方法一般是用來解決估算問題的。儘管他們都以數學的形式出現，但是這些方法並沒有被證明或者有一個正式的結論。統計學方法是對舊軟體項目中人類經驗進行量化的一種嘗試，然後將從這些數據得到的結論推廣到未來的工程項目中。這個方法有時候會頂用。實際上，這些看似有嚴格數學公式的方法只是徒有其表，做做樣子罷了。例如在 COCOMO II 中有一個數學公式：PersonMonths = 2.94 × Size^B，其中 B = 0.91 + 0.01 × Σ SF_i，而 SF_i是五個主觀影響因素，例如「開發的靈活性」和「團隊的凝聚力」。這個公式看似嚴謹，其實不然，裡面摻入了人為的影響因素。

「正規的軟體工程過程就像凈室軟體工程（cleanroom engineering）一樣，是為一種為軟體開發而不斷尋找嚴謹的、可證明的方法的過程。這些過程正在抬升圖 1 中的那條紅線並不斷的吞噬先前那些模糊的軟體工程的主題。」

確實，那些正式的軟體研究人員正在各種問題上取得進展。但是他們同樣栽倒在第一種反對意見上：他們在一個狹隘的角度上定義軟體開發，從而使得軟體工程中存在有嚴格的解。形式化的方法抹平了那些以人類為中心的問題。例如，正規的軟體開發方法都試圖去得到一個嚴格且明確的軟體規範。然後使用這個規範去驅動（和證明）下一個環節的軟體開發。一個正規的方法也許確實包含了一個明確的文字說明方案，但是沒有一個正規的方法能夠確切的描述出人們心中那種模糊的想法，也就是想要用軟體做什麼。

和這些反對意見相反，我想說的是，軟體工程完全不同於傳統的、正式計算機科學。前者依靠於人而後者並不需要。我們可得出康奈爾推論（Connell"s Corollary）:

「我們不應該再試圖去證明軟體工程中的那些基本結論，要接受這個領域中那些即將成為一般準則的重大進展。」

舉個例子，戴維·帕納斯（David Parnas）在 1972 年寫了一篇非常出眾的論文：「On The Criteria To Be Used in Decomposing Systems into Modules」。在這篇論文中，帕納斯描述了一個簡單的實驗，提出來可選軟體設計策略，一部分用於隱藏信息，另一部分則公之於眾 。基於這個小實驗，他得出了一些結論並給出一些建議。在這篇論文中，沒有任何證明，帕納斯也沒有聲明能夠保證實驗的可重複性。但是這篇論文卻蘊含哲理並且對面向對象語言的設計產生了巨大的影響。

另一個例子是著名的卡耐基梅隆大學軟體工程研究所關於 CMMI 的大量工作。CMMI 起先只是一個是軟體開發模型，現在已經成為一個包含各種各樣的其他工程的項目。CMMI 大概有 1000 頁的資料，是一千多人一年的工作量，這其中還不包含基礎內容，解釋部分和訓練材料。它被許多大型的組織機構使用，並且顯著改善了他們的軟體開發和產品。但是 CMMI 沒有包含任何永恆的結論。它僅僅只是一系列關於如何組織軟體工程項目的建議，這些建議基於以往的軟體開發。事實上，（卡耐基梅隆大學）軟體工程研究所指出，CMMI 甚至不能稱之為一個完整的軟體開發，它只是一個基本的開發，裡面充斥著了每個組織的詳細開發信息。

像模式設計、體系架構、基於錯誤的重構、敏捷開發和數據可視化這些領域同樣存在這樣的情況，在這些領域中，部分工作可能會包含先前的結論，但是其最終的目標是形成一個以人類行為為基礎的系統。簡單來說就是計算機科學的核心領域（在紅線一下）是軟體工程的重要工具。在設計高性能的應用軟體時，很有必要去了解演算法的前世今生。排隊論有助於設計操作系統的內核。凈室軟體工程中的一些方法則在某些領域中非常有用。以往的經驗總結有助於相同的團隊完成相似的任務。但是對於軟體工程來說，公式化只是一個必要條件而不是充分的條件。為了說明這一點，可以類比結構工程與現實建築（房屋和建築）。

想像一個非常有才的結構工程師，他是建築材料、應力與應變、載荷分布、風切變、抗震強度等方面的世界級專家。每個國家的建築師在對一個項目進行設計與構造之前都會拜訪一下這個人。但是這個神話一般的結構工程師真的會有助於你去設計建築嗎？一點都不會。我們的結構工程師可能乎善於與客戶進行交流，從而沒法設計出人們喜歡居住的房間，也無法想出解決問題的新辦法，同時也缺乏審美觀念。結構工程有助於現實的建築，但這對於好的設計來說它是不夠的。成功的架構應該集創造性、遠見性、多方位思考和人性化於一身。

同樣的道理，經典的計算機科學有助於軟體工程，但卻遠遠不夠。好的軟體工程也是集創造性、遠見性、多方位思考和人性化於一身。這一結論有助於軟體工程的研究者們放飛自我，從而將更多的精力放在應該做的事情上——為未來的軟體工程師們建立一套收集智慧機制。我們不應該試圖將軟體工程擴展為以數學為基礎的計算機科學。那是完全沒用的，並且可能使我們離待發現的進展愈行愈遠。

致謝

感謝史蒂夫·霍默（Steve Homer）與我進行討論，從而使得我對這個問題很感興趣。

英文原文：http://www.drdobbs.com/architecture-and-design/software-engineering-computer-science/217701907
譯者：無

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！