作者首先提出了一個問題：「我們一直這樣做開發，時間做久了，便忘了當初的本意。」有關軟體系統開發，我們談些什麼？

• 我們談過程，編碼規範、開發流程、同行評審、結對程式設計、持續整合，從瀑布到敏捷再到極限程式設計。
• 我們談架構，企業級、J2EE、容器化、SOA（面向服務架構）、Microservices（微服務化）。
• 我們談規模，大容量、高併發、大資料。
• 我們還談可靠性、可用率、n個9、響應時間等等。。。

這一切的核心是什麼？
然後作者通過一個簡單的故事，來揭示這個問題的答案：

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

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

他說：這就是電廠。

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

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

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

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

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

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

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

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

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

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

讀完這篇博文，我也想說幾句：

是呀，軟體系統大致可以分為兩類：一類是偏向研發性質的工作；一類是偏向軟體工程，應用性質的工作。但無論是研發，還是工程技術應用，其實本質目的都是為了解決現實領域中的問題。即將現實世界中的問題域通過軟體技術來進行求解。那麼自然而然，我們在求解這些問題時，就需要注意兩點：一是效率；而是安全。

所以大到一個軟體組織，小到一個程式設計師，在使用軟體思維去解決問題時，無論你是在做產品，還是在完成一個簡單的軟體程式，時刻都需要銘記我要解決什麼問題？效率和安全如何？在接受或者可控的成本範圍內嗎？穩定嗎？可靠嗎？

一切的技術選型，架構設計，使用者體驗，資料處理都是圍繞著上述問題展開的。

所以，作為一名軟體工程師，我們不能陷入“技術誤區”，無論做什麼系統，無論設計什麼樣的軟體應用都最求最新的技術、最時髦的框架、最流行的軟體開發方法論，99.99999%的高可用性，……。我們不能被技術所綁架。應該是不是回過頭來看看，系統在最初的現實域中要解決什麼樣的問題，隨著現實中業務的不斷髮展或者變化，我們的系統是否能夠滿足這一變化？我們的系統效率和安全是否能夠滿足基本的需要？這一代/版本的軟體系統生命週期會有多久？

如何不能達到這些，技術架構設計的再好，使用的技術再新，系統做的在華麗，也是不會被使用者所接受的。甚至系統剛一上線就會產生一系列的問題。我們不應該犧牲效率（也可以理解為效能），犧牲安全而換取系統早日上線。沒有使用者願意去使用一個效率低、安全性沒有保障、操作極為不方便的軟體系統。

我講一個案例，某公司設計開發的一套ALM (Application Lifecycle Management) 系統，其目的是希望能夠對應用軟體的開發過程能夠能夠進行有效的管理與控制，屬於一個軟體專案過程管理工具。面向的使用者群是軟體企業的工程技術人員。但是這個系統最大的問題在於，在系統中初始化一個專案的資訊，需要輸入大概40多項內容，使用者介面極其複雜。而這些初始化資訊中，有至少一半以上缺少統一的標準（缺少統一的資訊編碼格式，至少可以做成選項讓使用者進行選擇，而不是輸入。）這樣使用者經常輸錯資訊，而且後期導致資料不一致。而且系統在進行專案資源統計計算時，一個頁面上，需要使用者點選超過20次滑鼠，才能夠提交資料表單，進行後續的業務處理。

想想都可怕呀，多麼複雜的業務和多麼複雜的操作呀！（真的有那麼複雜嗎？）這需要使用者處理多大的資訊量呀！

這樣的系統一上線，所有的使用者都在抱怨，這個系統好是好，但是設計的太複雜了，操作上不但沒有提高原來的效率，而且還更加耗費時間了。而且統計的資訊不夠準確。所以，歷時一年多開發系統，最後幾乎成了擺設。維護成本極其昂貴。

我們回過頭來想想，問題出現在哪裡？至少有一點就是軟體的設計者，沒有從使用者的角度其思考，未來使用者使用上的要求。

所以那些產品經理，軟體架構師們，應該“大道至簡”，想想軟體產品的核心是什麼？