老碼農的技術理想

小時候，老師問我，你的理想是什麼？我不假思索說是php工程師，於是長大後果然成了工程師。

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

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

現在全世界資訊化的程度是偏高還是偏低？

程式設計師的人數夠用嗎？

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

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

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

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

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

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

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

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

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

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

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

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

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

什麼是DSL和二次開發平台呢，這兩個字聽起來很高端，但其實大家有很常用的東西就屬於這個範疇，比如Excel，它提供了各種各樣的公式，還有VBA，使用這些東西的人絕對大部分不是軟體產業的，Excel就是一個很成功的二次開發平台，公式和VBA就可以算DSL了。

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

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

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

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

我覺得其中的關鍵點在於絕大部分工作的抽象程度嚴重不足，另外有很大一部分效率損失在程式設計平台或程式語言的不完善，例如web前端。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

免費領取LAMP兄弟連原創php教學光碟/《細說PHP》精要版，詳情諮詢官網客服：http://www.lampbrother.net