【老碼農的技術理想】

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

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

　　那麼，在軟件方面，目前的世界有哪些問題須要解決呢？有這麼一些問題能夠思考：

• 如今整個世界的信息化程度是偏高仍是偏低？

• 
  

• 程序員

• 的人數夠用嗎？

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

• 大部分軟件系統均可靠嗎？

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

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

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

　　我以爲，纔剛剛至關於小學二年級，整個世界的信息化程度仍然嚴重偏低。從如今算起，往前10年，日後10年，這20年時間中，面向我的的信息化服務處於高速發展期，這個領域很是吸引眼球，由於它與每一個人的生活息息相關。但是，另外有一些領域，卻很是須要發展，那就是傳統行業的信息化。

　　以前有很多傳統行業，進行了必定程度的信息化，但這個信息化僅僅能知足自身運做的基本要求，當它與整個社會的潮流相對接的時候，就顯得很是落後，遲緩。好比說在網購這個大致系中，普通用戶所能看到的是商品展現，比價，下單的過程，但背後的核心環節倒是配貨與物流。

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

　　因此我如今看程序員的情況，仍然是供不該求，尤爲是高端程序員，十分搶手。這個問題的背景就是全社會的信息化進程在加速，以前的程序員人數遠遠跟不上需求量。

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

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

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

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

　　什麼是DSL和二次開發平臺呢，這兩個詞聽上去很高端，但其實你們有很經常使用的東西就屬於這個範疇，好比Excel，它提供了各類各樣的公式，還有VBA，使用這些東西的人絕大部分不是軟件行業的，Excel就是一種很成功的二次開發平臺，公式和VBA就能夠算DSL了。

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

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

　　那麼，軟件行業的生產力是偏高仍是偏低呢？我認爲嚴重偏低。什麼叫嚴重偏低？若是以機械力量的變革來對比，軟件行業目前的生產力水平處於蒸汽機發明以前。也就是說，生產力遠遠沒有被解放，你們作的大部分東西未來是會被機械化的，再也不須要這麼多人來作這麼重複的勞動。可能不少人會對這段話不滿，怎麼就重複勞動了，你說說我作的什麼是能夠被機器替代的？

　　換個角度看，爲何幾乎全部外行都以爲軟件貴呢？由於人力成本過高了，他們以爲，作出這麼多東西，應該是不須要這麼多時間。爲何雙方的反差這麼大呢？

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

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

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

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

　　那爲何軟件系統的質量不容易高呢？我以爲主要緣由是流程不完善。那爲何不完善？需求容易變。爲何容易變？是由於不論程序員本身，仍是需求方，其實潛意識都認爲本身作的東西是變動成本較低的。

　　試想一下，爲何沒人在蓋高樓蓋一半變動需求？爲何沒人修大橋修一半變動需求？甚至作衣服作一半的時候變動需求，理髮到一半變動需求，都會被人認爲是不講理。可是在軟件領域，好像這倒成了廣泛現象。

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

　　我見過很多公司是經過增強測試的方式來試圖控制質量，但我的以爲這種方式不划算，並且收效不高。要想很好地應對需求變動，很重要的一點就是不要有這個軟件必定不會改的想法，而後，從架構上作拆分，隔離，組件化等等，力爭作到即便要改，也只改某一塊的內部，不影響別的地方。

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

　　任何一種架構方案，都須要一個良好的管控機制。沒有哪一個蓋大樓的只認真管設計圖紙，不控制施工過程。架構實際上是跟施工過程嚴格相關的，架構並非一張扁平的圖，而是一個立體的東西，做爲整個系統工程的骨架。若是能在開發的時候看到這個骨架逐漸創建，血肉充盈的過程，對整個系統的成功把握必定會大得多，這也就是開發過程當中架構管控的理念，具體實現要依賴於不一樣場景。

　　因此，未來的軟件開發方案，必定是會朝着幾個方向發展：

• 高生產力，單位時間生產效率更高，普通人員也能夠參與

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

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

跟多java,java學習,java面試題  http://techfoxbbs.com/thread-621-1-1.html