小時候，老師問我，你的理想是什麼？我不假思索說是工程師，於是長大之後果然成了工程師。
工作這麼多年，一直在思考工程師這三個字的意義，終於有一天恍然大悟，原來就是：用技術手段改進世界。
那麼，在軟體方面，目前的世界有哪些問題需要解決呢？有這麼一些問題可以思考：
- 現在整個世界的資訊化程度是偏高還是偏低？
- 程式設計師的人數夠用嗎？
- 軟體行業的生產力是偏高還是偏低？
- 大部分軟體系統都可靠嗎？
我想說說自己對這幾個問題的理解。
雖然現在我們的生活與十年前相比，已經發生了巨大變化，比如智慧手持裝置已經非常普及，可穿戴裝置也在蓬勃發展。十年前我們用手機收發簡訊或者郵件，瀏覽非常簡單而老土的wap頁面，但現在，絕大部分人的手機已經取代了電腦，成為日常生活中不可缺少的工具。
我們用手機交流，購物，欣賞影視，閱讀書籍，玩各類遊戲，尤其是飛速發展的移動購物和支付體系，使得我們能在任意場合購買心儀的物品，訂購旅遊服務和賓館，叫快餐，叫車等等，生活非常美好，那麼，整個世界的資訊化程度處於什麼級別呢？
我覺得，才剛剛相當於小學二年級，整個世界的資訊化程度仍然嚴重偏低。從現在算起，往前10年，往後10年，這20年時間中，面向個人的資訊化服務處於高速發展期，這個領域非常吸引眼球，因為它與每個人的生活息息相關。可是，另外有一些領域，卻非常需要發展，那就是傳統行業的資訊化。
之前有不少傳統行業，進行了一定程度的資訊化，但這個資訊化僅僅能滿足自身運作的基本要求，當它與整個社會的潮流相對接的時候，就顯得非常落後，遲緩。比如說在網購這個大體系中，普通使用者所能看到的是商品展示，比價，下單的過程，但背後的核心環節卻是配貨與物流。
我還在上學的時候，有老師這麼說過，現在計算機行業非常火熱，很可能要飽和了，你們不一定非要從事這方面的工作。現在回頭看這句話，覺得很有趣，人真的很難有眼光看到未來。去年我入職蘇寧培訓的時候，孫為民副總講了當年一個決策失誤的例子。90年代末，公司統計發現全國空調的年銷售量達到數百萬臺，覺得很可怕，這個行業可能要飽和，估計要再想辦法擴充別的商品經營了，但現在，全國空調的保有量為七億臺，即使完全沒有新增，十年換一輪，每年也賣得出去七千萬臺，當年憑什麼說這就飽和了？
所以我現在看程式設計師的狀況，仍然是供不應求，尤其是高階程式設計師，十分搶手。這個問題的背景就是全社會的資訊化程式在加速，之前的程式設計師人數遠遠跟不上需求量。
那麼，如何解決這個問題呢？一方面是繼續培訓，促使更多新人來到這個行業，並且認真做下去，另外還有一些別的手段需要考慮。
我想追問一個問題：世界上懂業務的人多，還是懂技術的人多？很明顯，懂業務的人要多很多，什麼叫業務？其實就是行業常識，生活經驗。
比如說，一個有經驗的倉庫保管員，可能文化程度不高，理解不了軟體的執行原理之類，但一定對產品出庫入庫的流程非常熟悉，包括各種審批過程和異常狀況，但這些，程式設計師是不懂的。那如果要促進這個領域的資訊化，必然要在兩者之間尋找一個結合點，程式設計師可以學業務，業務人員也可以嘗試參與軟體研發過程，目前來說，都是前者比較多，因為程式設計師相對來說還是比較年輕，學東西快些。但從整體社會效益來說，這其實是不利的，因為程式設計師是更稀缺資源，而傳統業務人員非常多。
之前見過一個問題：如何讓業務人員更好地參與軟體研發過程。這個問題的根本解決方法是DSL（Domain Specific Language），核心解決方案是二次開發平臺。
什麼是DSL和二次開發平臺呢，這兩個詞聽上去很高階，但其實大家有很常用的東西就屬於這個範疇，比如Excel，它提供了各種各樣的公式，還有VBA，使用這些東西的人絕大部分不是軟體行業的，Excel就是一種很成功的二次開發平臺，公式和VBA就可以算DSL了。
很多時候這些東西還不夠直觀，我們可以看到一些圖形化的程式語言，比如Scratch，現在很多小學生的興趣班就會學，這些東西相對學起來就比較容易了，我們也可以做一些類似的抽象，以圖形化的方式讓業務人員能夠參與，比如流程配置等等。圖形化的東西，是最適合非技術人員理解的。
所以，要促進社會的資訊化程度，最好是能夠想辦法把各行業的業務人員都拖進來一起搞。具體的分工大致是：技術人員和業務人員一起定義DSL，技術人員負責DSL的底層平臺實現，業務人員負責使用它來構建業務模型和業務流程，甚至業務介面。
那麼，軟體行業的生產力是偏高還是偏低呢？我認為嚴重偏低。什麼叫嚴重偏低？如果以機械力量的變革來對比，軟體行業目前的生產力水平處於蒸汽機發明之前。也就是說，生產力遠遠沒有被解放，大家做的大部分東西將來是會被機械化的，不再需要這麼多人來做這麼重複的勞動。可能很多人會對這段話不滿，怎麼就重複勞動了，你說說我做的什麼是可以被機器替代的？
換個角度看，為什麼幾乎所有外行都覺得軟體貴呢？因為人力成本太高了，他們覺得，做出這麼多東西，應該是不需要這麼多時間。為什麼雙方的反差這麼大呢？
我覺得其中的關鍵點在於絕大部分工作的抽象程度嚴重不足，另外有很大一部分效率損失在程式設計平臺或程式語言的不完善，比如Web前端。
從第一代到第四代程式語言，每一代都是損失一定執行效率，而大幅提升編寫效率。隨著硬體技術的發展，軟體程式設計必然越來越粗放，大的趨勢是不特別重視細節效率，只要沒有數量級的效能損耗。
所以我們可以預期，會有越來越多的人使用一些執行效率相對不怎麼高的語言或框架，只是為了提高單位時間的生產力。從老闆們角度想，也會明白，提升執行機器的效能，要比多僱幾個程式設計師便宜多了。因此，從整體趨勢看，追求細節效能的程式設計師們恐怕會離自己的理想越來越遠了，除非是在某些特定領域。
那麼，絕大部分軟體系統都可靠嗎？我換一句話來問：各位程式設計師朋友，如果你們住的房子質量跟你們正在做的軟體一樣，你敢住嗎？感覺大家都在笑，笑是什麼意思，我們都懂的。
那為什麼軟體系統的質量不容易高呢？我覺得主要原因是流程不完善。那為什麼不完善？需求容易變。為什麼容易變？是因為不論程式設計師自己，還是需求方，其實潛意識都認為自己做的東西是變更成本較低的。
試想一下，為什麼沒人在蓋高樓蓋一半變更需求？為什麼沒人修大橋修一半變更需求？甚至做衣服做一半的時候變更需求，理髮到一半變更需求，都會被人認為是不講理。但是在軟體領域，好像這倒成了普遍現象。
因為整個軟體系統的實現，都是虛擬的，看不見摸不著，並不消耗什麼物料，所以從這個角度想，變起來當然是容易的。但軟體系統的架構，其實也跟實體的沒本質區別，變更時候要考慮很多關聯因素，並不是就那麼孤立的看一小塊地方，當然，也會有一些不影響全域性的變更。打個比方說，如果你在蓋房子蓋到一半，那變更外牆顏色肯定是要比變更窗戶大小容易的。要是想變得太多，估計只好拆了重來。
我見過不少公司是通過加強測試的方式來試圖控制質量，但個人覺得這種方式不划算，而且收效不高。要想很好地應對需求變更，很重要的一點就是不要有這個軟體一定不會改的想法，然後，從架構上做拆分，隔離，元件化等等，力爭做到即使要改，也只改某一塊的內部，不影響別的地方。
很多軟體公司，一方面不注重架構的設計與宣貫，導致變更的時候問題多多，程式設計師也不能很好領會架構意圖，一方面忽視整個過程中對架構的管控，認為架構只是最初那張靜態圖。
任何一種架構方案，都需要一個良好的管控機制。沒有哪個蓋大樓的只認真管設計圖紙，不控制施工過程。架構其實是跟施工過程嚴格相關的，架構並不是一張扁平的圖，而是一個立體的東西，作為整個系統工程的骨架。如果能在開發的時候看到這個骨架逐漸建立，血肉充盈的過程，對整個系統的成功把握一定會大
得多，這也就是開發過程中架構管控的理念，具體實現要依賴於不同場景。
所以，將來的軟體開發方案，一定是會朝著幾個方向發展：
- 高生產力，單位時間生產效率更高，普通人員也可以參與
- 高可控性，整個生產過程更加完備可靠
有時候看現在的小孩子，會覺得他們很幸福，因為等他們這代長大，就不需要像我們現在這樣編寫程式了，那時候，程式設計已經成了一種令人習以為常的通用技能，就像現在的人用Office軟體一樣，所謂的程式設計，很可能已經不需要敲程式碼了，而是圖形化，設定幾個引數就完事了。