軟體開發還遠不是一種“科學”

很多大學裡是把軟體開發相關的專業劃入工科的，這給人一種錯覺，讓人認為軟體開發也是一個工程學科，就像土木建築，動力機械那樣。

但這從根本上錯了，土木建築，動力機械的背後有確實的科學定律作為支撐，而軟體開發的背後基本上什麼都沒有，遠不是一種“科學”。

也正因此，“軟體工程”的現實意義也就遠不如“土木工程”，“動力工程”。

 

每個人對“科學”的定義可能不同，但在這裡，我們可以做一個簡化版的定義：

當有一組在限定條件下顛撲不破的定律做支撐時，相應的知識，我們可以稱之為科學，科學自身可以體現為一種確定性。

比如說：牛頓的力學定律在低速時是不容違反的，是一種鐵則，那基於此的各種知識就可以成為科學。

 

從這個視角出發，我們會發現，在軟體的世界裡，壓根找不到屬於軟體的“牛頓力學定律”，有的只是雜多、紛爭和不確定性。

 

物件導向應該是接受程度最高的分析和設計方法，但即使如此Eric Raymond和Linus也仍然會站出來批判它。

參見：

Eric Raymond談模組化原則，膠合層和物件導向的缺陷 孟岩譯

http://blog.csdn.net/myan/article/details/1924 

C++一無是處

http://news.csdn.net/a/20100612/218785.html 

簡單來講：Eric Raymond認為OO會導致過度分層，Linus認為物件導向解決的是一些小問題，他們不約而同的反對OO。

你能找到如此批判牛頓定律的人嗎？

 

但Eric Raymond他們的觀點又不由得你不重視，除非你認為Eric Raymond和Linus信口雌黃或人品有問題，否則你可以批判，可以不同意，但你不能忽視他們的聲音。

他們的聲音必然基於他們的經曆，代表著特定的現實，而現實本身代表合理性。

 

物件導向之外，各種觀點想法就更多，這導致了軟體的世界是雜多的，不確定的，行業中人大多都為名詞所苦。

隨便看一下吧，有多少人可以精確分辨這些詞間的差異：

架構(Framework)，架構(Architecture)，物件導向分析和設計(Object Oriented Analysis and Design)，設計模式(Design Pattern)，契約式編程（Design by Contract)，測試驅動開發(Test Driven Development)，面向方面的編程（Aspect Oriented Programming)，模型驅動架構（Model Driven Architecture)，基於組件的開發（Component-Based Development），敏捷式軟體開發 (Agile Software Development)(Agile Software Development)，元編程(Meta programming)，服務導向架構（Service-oriented architecture），Feature-oriented programming... ...(程式設計語言就更不要說了，實在不知道有多少個，但反過來想，世界上真需要這麼多種語言嗎？)

 

這些不同的方法（概念或語言）只要存在，即使彼此有衝突，也必然有其合理之根基，這裡無意分析其優劣，

只是想說：軟體開發的定論在那裡？我們究竟又該根據什麼來判定那個是適合的，那個是不適合的？這種眾說紛紜，真是工程學科應該有的狀況嗎？

如果所有這一切都只能歸還給當事人，那就必然紛爭不斷，軟體開發也就一定不是一種科學。

 

在這樣一種情景下，由於任何人都可能是錯的，務實的程式員也就必須選擇相信自己多過相信別人，那怕別人有天大的來頭。

相信自己基於事實和邏輯的分析，即使錯了，也可以成為一種進步的養分；相信別人，錯了不會進步，對了也是別人對了，有什麼意思。

狂妄的程式員則可以挑戰“牛頓”這一角色。

 

楊昌濟先生，曾經說過兩句話，特別有意思，也契合軟體開發的情景，因此把它放在這裡，作為結尾：

橫盡虛空，山河大地無一可恃，而可恃唯我。

豎盡來劫，前古後今無一可據，可據者唯有當前。