「我們一直這樣做開發，時間做久了，便忘了當初的本意。」

有關軟件系統開發，我們談些什麼？

我們談過程，編碼規範、開發流程、同行評審、結對編程、持續集成，從瀑布到敏捷再到極限編程。

我們談架構，企業級、J2EE、容器化、SOA（面向服務架構）、Microservices（微服務化）。

我們談規模，大容量、高并發、大數據。

我們還談可靠性、可用率、n個9、響應時間等等。。。

這一切的核心是什麼？

先講個電力行業的一個故事，電力的項目我沒做過，對電廠的原理雖有所了解，但看見那些大規模的電站還是感覺挺複雜的。 故事是這樣開始的：

記得有個給我們上培訓課的主講老師是個須發皆白的老先生，進門後掏出一堆零件放在講台上， 一盞酒精燈、一個小水壺、一個葉片、一個銅光閃閃的小電機、一盞小燈泡。 老先生往壺裡倒了些水，點燃酒精燈，不一會兒水開了，從壺嘴裡噴出了蒸汽，帶動葉片旋轉，然後小燈泡就亮了。

他說：這就是電廠。

他還說：如果燒的是煤炭，這就是燃煤電廠；如果燒的天然氣，這就是燃氣電廠；

如果獲得熱能的方式是核裂變，這就是核電廠；如果帶動葉片的能量來自水從高處流向低處，這就是水電廠。

老先生說：你們或許會問 “那我們看到的電廠怎麼這麼複雜”，答案其實很簡單， 電力項目需要複雜系統的目的，一是為了确保安全（Safety），二是為了提高效率（Efficiency）。

安全和效率的平衡，是所有工程技術的核心。

看完這個故事，我就感覺到所謂 “大道至簡” 大概就是這樣的。

開發軟件系統的根本在于滿足需求，不能滿足需求的系統本身是沒有意義的。 就像一個再安全、有效率的電廠不能發電又有什麼意義呢。 所以軟件系統開發也就是圍繞根本的基礎上确保安全與提高效率。

需求作為軟件的根本差異很大，需求是多樣，需求也是複雜的。 一個大型 ERP 系統，一個大型倉儲系統，一個大型網站系統，到底誰更複雜，沒有一個定量标準，甚至都不好定性分析。 所以前面我們談軟件系統開發那麼多内容都是關于 “安全” 和 “效率” 這兩個圍繞根本的核心。

所有軟件開發的方法論，像瀑布、敏捷到極限編程圍繞的是開發活動的效率問題，而編碼規範、流程制定、同行評審等等則是有關開發的安全問題。 那麼 SOA 化或進一步微服務化其實同時考慮到了安全與效率，服務化拆分有利于大規模開發團隊的并行開發，提升了開發效率， 但上線部署複雜了降低了運維效率，但運維效率可以通過自動化來得到彌補，而開發則不可能自動化。

同理，可靠性、可用性和容災設計這些活動都是圍繞 “安全” 這個核心，而性能優化，提升響應性則是圍繞 “效率”。 有些關鍵的軟件系統必須同時兼顧 “安全” 和 “效率”，例如用在飛機、汽車内用于控制起落、刹車、油門的軟件系統， 不安全或無效率造成事故是會死人的，而另外一大部分軟件系統因為不安全或無效率造成的事故則死的是錢。

沒有人去争論建設電廠到底是不是一門藝術，但肯定有人在争論軟件開發（程序設計）到底是不是一門藝術， 但終究大部分的軟件系統開發還是更偏向于工程技術。