小時候，老師問我，你的理想是什么？我不假思索說是工程師，于是長大之后果然成了工程師。

工作這么多年，一直在思考工程師這三個字的意義，終于有一天恍然大悟，原來就是：用技術手段改進世界。

那么，在軟件方面，目前的世界有哪些問題需要解決呢？有這么一些問題可以思考：

現在整個世界的信息化程度是偏高還是偏低？

程序員的人數夠用嗎？

軟件行業的生產力是偏高還是偏低？

大部分軟件系統都可靠嗎？

我想說說自己對這幾個問題的理解。

雖然現在我們的生活與十年前相比，已經發生了巨大變化，比如智能手持設備已經非常普及，可穿戴設備也在蓬勃發展。十年前我們用手機收發短信或者郵件，瀏覽非常簡單而老土的wap頁面，但現在，絕大部分人的手機已經取代了電腦，成為日常生活中不可缺少的工具。

我們用手機交流，購物，欣賞影視，閱讀書籍，玩各類游戲，尤其是飛速發展的移動購物和支付體系，使得我們能在任意場合購買心儀的物品，訂購旅游服務和賓館，叫快餐，打車等等，生活非常美好，那么，整個世界的信息化程度處于什么級別呢？

我覺得，才剛剛相當于小學二年級，整個世界的信息化程度仍然嚴重偏低。從現在算起，往前10年，往后10年，這20年時間中，面向個人的信息化服務處于高速發展期，這個領域非常吸引眼球，因為它與每個人的生活息息相關。可是，另外有一些領域，卻非常需要發展，那就是傳統行業的信息化。

之前有不少傳統行業，進行了一定程度的信息化，但這個信息化僅僅能滿足自身運作的基本要求，當它與整個社會的潮流相對接的時候，就顯得非常落后，遲緩。比如說在網購這個大體系中，普通用戶所能看到的是商品展示，比價，下單的過程，但背后的核心環節卻是配貨與物流。

我還在上學的時候，有老師這么說過，現在計算機行業非常火熱，很可能要飽和了，你們不一定非要從事這方面的工作。現在回頭看這句話，覺得很有趣，人真的很難有眼光看到未來。去年我入職蘇寧培訓的時候，孫為民副總講了當年一個決策失誤的例子。90年代末，公司統計發現全國空調的年銷售量達到數百萬臺，覺得很可怕，這個行業可能要飽和，估計要再想辦法拓展別的商品經營了，但現在，全國空調的保有量為七億臺，即使完全沒有新增，十年換一輪，每年也賣得出去七千萬臺，當年憑什么說這就飽和了？

所以我現在看程序員的狀況，仍然是供不應求，尤其是高端程序員，十分搶手。這個問題的背景就是全社會的信息化進程在加速，之前的程序員人數遠遠跟不上需求量。

那么，如何解決這個問題呢？一方面是繼續培訓，促使更多新人來到這個行業，并且認真做下去，另外還有一些別的手段需要考慮。

我想追問一個問題：世界上懂業務的人多，還是懂技術的人多？很明顯，懂業務的人要多很多，什么叫業務？其實就是行業常識，生活經驗。

比如說，一個有經驗的倉庫保管員，可能文化程度不高，理解不了軟件的運行原理之類，但一定對產品出庫入庫的流程非常熟悉，包括各種審批過程和異常狀況，但這些，程序員是不懂的。那如果要促進這個領域的信息化，必然要在兩者之間尋找一個結合點，程序員可以學業務，業務人員也可以嘗試參與軟件研發過程，目前來說，都是前者比較多，因為程序員相對來說還是比較年輕，學東西快些。但從整體社會效益來說，這其實是不利的，因為程序員是更稀缺資源，而傳統業務人員非常多。

之前見過一個問題：如何讓業務人員更好地參與軟件研發過程。這個問題的根本解決方法是DSL（Domain Specific Language），核心解決方案是二次開發平臺。

什么是DSL和二次開發平臺呢，這兩個詞聽上去很高端，但其實大家有很常用的東西就屬于這個范疇，比如Excel，它提供了各種各樣的公式，還有VBA，使用這些東西的人絕大部分不是軟件行業的，Excel就是一種很成功的二次開發平臺，公式和VBA就可以算DSL了。

很多時候這些東西還不夠直觀，我們可以看到一些圖形化的編程語言，比如Scratch，現在很多小學生的興趣班就會學，這些東西相對學起來就比較容易了，我們也可以做一些類似的抽象，以圖形化的方式讓業務人員能夠參與，比如流程配置等等。圖形化的東西，是最適合非技術人員理解的。

所以，要促進社會的信息化程度，最好是能夠想辦法把各行業的業務人員都拖進來一起搞。具體的分工大致是：技術人員和業務人員一起定義DSL，技術人員負責DSL的底層平臺實現，業務人員負責使用它來構建業務模型和業務流程，甚至業務界面。

那么，軟件行業的生產力是偏高還是偏低呢？我認為嚴重偏低。什么叫嚴重偏低？如果以機械力量的變革來對比，軟件行業目前的生產力水平處于蒸汽機發明之前。也就是說，生產力遠遠沒有被解放，大家做的大部分東西將來是會被機械化的，不再需要這么多人來做這么重復的勞動。可能很多人會對這段話不滿，怎么就重復勞動了，你說說我做的什么是可以被機器替代的？

換個角度看，為什么幾乎所有外行都覺得軟件貴呢？因為人力成本太高了，他們覺得，做出這么多東西，應該是不需要這么多時間。為什么雙方的反差這么大呢？

我覺得其中的關鍵點在于絕大部分工作的抽象程度嚴重不足，另外有很大一部分效率損失在編程平臺或編程語言的不完善，比如Web前端。

從第一代到第四代編程語言，每一代都是損失一定運行效率，而大幅提升編寫效率。隨著硬件技術的發展，軟件編程必然越來越粗放，大的趨勢是不特別重視細節效率，只要沒有數量級的性能損耗。

所以我們可以預期，會有越來越多的人使用一些運行效率相對不怎么高的語言或框架，只是為了提高單位時間的生產力。從老板們角度想，也會明白，提升運行機器的性能，要比多雇幾個程序員便宜多了。因此，從整體趨勢看，追求細節性能的程序員們恐怕會離自己的理想越來越遠了，除非是在某些特定領域。

那么，絕大部分軟件系統都可靠嗎？我換一句話來問：各位程序員朋友，如果你們住的房子質量跟你們正在做的軟件一樣，你敢住嗎？感覺大家都在笑，笑是什么意思，我們都懂的。

那為什么軟件系統的質量不容易高呢？我覺得主要原因是流程不完善。那為什么不完善？需求容易變。為什么容易變？是因為不論程序員自己，還是需求方，其實潛意識都認為自己做的東西是變更成本較低的。

試想一下，為什么沒人在蓋高樓蓋一半變更需求？為什么沒人修大橋修一半變更需求？甚至做衣服做一半的時候變更需求，理發到一半變更需求，都會被人認為是不講理。但是在軟件領域，好像這倒成了普遍現象。

因為整個軟件系統的實現，都是虛擬的，看不見摸不著，并不消耗什么物料，所以從這個角度想，變起來當然是容易的。但軟件系統的架構，其實也跟實體的沒本質區別，變更時候要考慮很多關聯因素，并不是就那么孤立的看一小塊地方，當然，也會有一些不影響全局的變更。打個比方說，如果你在蓋房子蓋到一半，那變更外墻顏色肯定是要比變更窗戶大小容易的。要是想變得太多，估計只好拆了重來。

我見過不少公司是通過加強測試的方式來試圖控制質量，但個人覺得這種方式不劃算，而且收效不高。要想很好地應對需求變更，很重要的一點就是不要有這個軟件一定不會改的想法，然后，從架構上做拆分，隔離，組件化等等，力爭做到即使要改，也只改某一塊的內部，不影響別的地方。

很多軟件公司，一方面不注重架構的設計與宣貫，導致變更的時候問題多多，程序員也不能很好領會架構意圖，一方面忽視整個過程中對架構的管控，認為架構只是最初那張靜態圖。

任何一種架構方案，都需要一個良好的管控機制。沒有哪個蓋大樓的只認真管設計圖紙，不控制施工過程。架構其實是跟施工過程嚴格相關的，架構并不是一張扁平的圖，而是一個立體的東西，作為整個系統工程的骨架。如果能在開發的時候看到這個骨架逐漸建立，血肉充盈的過程，對整個系統的成功把握一定會大

得多，這也就是開發過程中架構管控的理念，具體實現要依賴于不同場景。

所以，將來的軟件開發方案，一定是會朝著幾個方向發展：

高生產力，單位時間生產效率更高，普通人員也可以參與

高可控性，整個生產過程更加完備可靠

有時候看現在的小孩子，會覺得他們很幸福，因為等他們這代長大，就不需要像我們現在這樣編寫程序了，那時候，編程已經成了一種令人習以為常的通用技能，就像現在的人用Office軟件一樣，所謂的編程，很可能已經不需要敲代碼了，而是圖形化，設置幾個參數就完事了。