老碼農的技術理想

民工精髓發表於2015-01-28

老碼農的技術理想

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

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

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

  • 現在整個世界的資訊化程度是偏高還是偏低?
  • 程式設計師的人數夠用嗎?
  • 軟體行業的生產力是偏高還是偏低?
  • 大部分軟體系統都可靠嗎?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所以,將來的軟體開發方案,一定是會朝著幾個方向發展:

  • 高生產力,單位時間生產效率更高,普通人員也可以參與
  • 高可控性,整個生產過程更加完備可靠

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

相關文章