--願與勇於正視現實的人共勉
在開始任何其他文字之前,首先有必要正視一個根本現實:國內外軟體開發的水平是有差距的。
這一結論的最直接證據是每一輪新技術的發起者基本上都是國外的人或公司:
從方法論(CMMI,敏捷等)到各種架構(近來很熱的Hadoop等)再到新的程式設計語言都是如此。
總的來看這類差距似乎可以概括為“原創的缺失”,大多時候,我們只是處在一種“跟隨者”的角色上。
RUP出來後我們跟誰RUP,敏捷出來我們跟誰敏捷,雲端運算出來後我們跟隨雲端運算,大致如此。
年紀小的時候,會單純的以為造成這種局面的主要原因是個人技術能力不足或努力不夠。
但現在想來,這反倒是次要原因。
單以單兵能力來看,國內外的程式員群體未必就有很大的差距。
這點可以反過來看,那麼多開源的庫,看過代碼後,那個是國內程式員看不懂並完全寫不出來的?
如果說既能看懂,有足夠的時間也可以自己寫出來,那麼大致上就不是個人技術能力的問題。
這樣事情就變的有些微妙,我們也就需要在更高的視點上審視一下促成一件事情的因子。
一件事情的成敗大致可以用四個維度去考量:
- 有沒有意識去做 -->創新
- 有沒有能力去做
- 有沒有時間去做 -->環境
- 有沒有動力持續去做 -->意願和環境
排除第二點能力之外,其餘三點可以大致概括為:勇為天下先的意識(創新)和創新得以生長的泥土(意願和環境)。
這幾者彼此影響,不可分割。
一提創新,很多人可能會想到其瓶頸是沒有想法,進而認為差距的主要原因是意識問題。
但這很可能是錯的,就我自身的觀感,程式員這個群體裡,現實的情形應該是想法很多,但受種種制約,實踐下來的不多。
現實的需要激發了創新,也提供了實踐創新的場所和養分,脫離實際需要的創新是走不遠的。
這似乎只能寄希望於本土軟體企業的崛起,為程式員提供相應的環境(時間+實踐創新的場所),
接下來如果程式員這個群體再有實踐自身追求的意願,那麼事情將會改觀。
國內外差距的一個間接證據是國內軟體開發的工程化的程度過於薄弱。
軟體這東西過度工程化是不行的,但不工程化也一定是不行的。
先不論CMMI這種大型方法論,就說最簡單的軟體工程資料收集。
在這點上國外比較容易找到各種資料,比如下面這樣的表格:
程式碼/天 最低值-最高值(典型值) |
軟體類型 |
10,000程式碼的項目 |
100,000程式碼的項目 |
250,000程式碼的項目 |
航空電子 |
15-150(30) |
3-45(7) |
3-30(6) |
應用系統 |
120-2,700(450) |
30-1050(90) |
15-750(75) |
命令與控制 |
30-450(75) |
7-90(15) |
6-75(12) |
嵌入式系統 |
15-300(45) |
4.5-75(11) |
3-60(9) |
公眾網際網路 系統 |
90-1500(225) |
15-300(45) |
15-225(30) |
內部內連網 系統 |
225-2700(600) |
45-1050(120) |
30-750(90) |
微代碼 |
15-120(30) |
3-30(6) |
3-15(4) |
過程式控制制 |
75-750(150) |
15-150(45) |
13-130(30) |
即時系統 |
15-225(30) |
3-45(7) |
3-45(6) |
科學系統/ 工程研究 |
75-1125(150) |
15-225(45) |
12-150(30) |
套裝軟體 |
60-750(150) |
15-150(30) |
10-120(30) |
系統軟體/ 驅動程式 |
30-750(90) |
7-150(15) |
6-120(13) |
電信軟體 |
30-450(90) |
7-90(15) |
6-75(7) |
即使是在日本,也有一個叫IPA這樣的機構在定義各種指標,並持續收集資料。而國內似乎還沒人做這類事情。
這樣的話對軟體開發個體而言,負面影響可能並不直觀,但從整體來看卻也是一種切切實實的差距。
這點上很難靠個人來推進和改善,需要有一種組織(軟體協會?)來持續推進才有可能改觀。