軟體開發究竟是簡單的還是複雜的

軟體開發是個奇妙的行業。

你可以說它複雜，但與此同時，隨便有個人，只要接受點培訓就可以做軟體開發。

你也可以說它簡單，但據統計世界上一半以上的軟體項目會以失敗收場。

 

強調軟體複雜的最有代表性的觀點來自《人月神話》：

Brooks認為複雜性是軟體的根本特質，而非偶然特質。

強調軟體簡單性的觀點則時見於國內某些MIS開發公司以及外包公司：

他們大多時候會把需求分析（業務分析）的權重抬的很高，而把設計編碼的位置壓的很低。

 

這種迷思其實不難打破，但在此之前要對軟體的特質做一點考察。

 

軟體自身是一種固化的思維，其必同時具有思維的特質以及思維承載之物的特質。

這話有點搞，但並不難理解：

思維由概念和邏輯組成，所以軟體必然由概念和邏輯組成---這是思維的特質。

當思維同數學結合時，思維具有數學的特質；當思維與商業邏輯結合時，思維具有商業邏輯的特質---這就是思維承載之物的特質。

這段很搞的話，可以讓我們理解：

 

• 任何人都可以思維，所以只要不是神經病患者，都可以做軟體（好壞暫且不論），當然你要跨過程式設計語言這關。
•  思維的複雜度主要取決於多少和深淺兩個維度。對應到軟體，深淺取決于思維承載的是什麼；而多少則取決於規模。比如：圖形演算法在深度上會比工作流程要深；100萬行的專案管理軟體和10萬行的專案管理軟體的差異則主要是多少。

 

很多時候，很多人談及簡單或複雜的時候過度關注“深淺”這一維度，而忽略“多少”這一維度。

比如說：圖形演算法，TTS演算法，最佳化效能，最佳化可靠性這類東西，很少有人認為其簡單。但即使是很大規模的專案管理軟體，很多人仍然認為它比較簡單---因為這可以通過簡單拼湊剛入行的程式員的工作而獲得。

從結果上看，這種認識是災難性的。

典型表現是：一群人對這一堆垃圾代碼沒人敢動，非修不可的時候，只能祈禱不要出問題。

就像城牆如果足夠堅固，古代時攻城只能用人命來填一樣。搞定牽涉商業利益的垃圾代碼也只能用人月去填。這時候垃圾代碼就像黑洞，吞噬人力的同時，也吞噬利潤空間。

結局可以形容為：程式員沒希望，公司沒未來。

這是把業務分析抬得過高，把設計編碼壓得過低的必然結果。

所以，“認為上了規模的軟體（暫訂20萬行吧）是簡單的”是好像有道理，但其實十分危險的想法。