zz程序員成長的10個階段

http://news.csdn.net/a/20110602/299186.html

 

我的程序員成長之路

程序員的成長經歷往往很相似,大部分的人走過了最前面相同的一段路,而有的人則走得更遠。總結自己這些年來的歷程,這也許能讓年輕的程序員少走一些彎路,成長得更快;或許更好一些,能讓大家從中得到一些啓發,早日進入優秀程序員的階段,實現夢想,釋放激情。

第一階段最初是在學校裏學習計算機基礎知識,學習經典的程序設計語言,編寫測試用的小程序。這個過程可以說是對計算機和程序設計的入門階段。這個階段主要是培養了自己對計算機軟件的興趣,打下了良好的計算機基礎知識。

第二階段而後參加工作,從事計算機軟件開發工作。按照工作要求,一邊學習,一邊編程,終於可以讓自己的程序投入運行了。在這個階段我突然感覺到了自己的價值,感覺到了軟件的神奇,並且自己編寫的軟件成爲了實用產品。這個階段實現了學習到生產的過渡。

第三階段隨着工作的增加,開始編寫各種程序,開發各種系統,這時候忙於編程知識的積累和應用。應該說在這個階段自我感覺很充實,好像有做不完的事,程序設計水平還處在語言級階段。

第四階段隨着積累了一定編程技巧之後,我開始想這樣的問題:我是不是最好的程序員?我能否編寫出最好的程序?這個過程是一個反思的階段。我對自己的要求是:不但要會編程序,而且要編好程序,從關注程序數量開始轉向關注程序質量。

第五階段開始在提高自己的軟件開發水平上做文章。經過各種系統開發,尤其是大型系統的開發,發現了軟件中有許多功能是重複的。因此,有一段時間把精力花在編制各種庫函數上,通過不同系統調用相同的函數,以便減少重複開發,實現功能共享。當時比較得意的是庫函數不是我一個人在調用,而是整個項目小組都在調用,甚至不同的系統也能調用,從而體會到編寫庫函數特別有價值。這個階段的標誌是庫函數,程序員水平上升到庫函數那一級。

第六階段到了庫函數那一級後,很快就發現,單單實現程序函數級的調用是遠遠不夠的。當你做了很多項目,包括大項目和小項目,尤其是做過跨行業的項目之後,你就會把庫函數的共享思想用於項目開發。你就會想這樣一個問題:爲什麼不同項目不能有相同的架構?如果有相同的架構,那麼開發就有了相對的標準,我們就有可能通過配置的方法實現相同架構的系統。於是我提出了IASG(交互式軟件自動生成器)思想,並在C語言和其他一些語言中實現了IASG實例。記得最快的一次是編寫一個系統(公安部門的自行車信息管理系統,主要用於丟失自行車信息登記)只用了3個小時(從需求到安裝盤)。這個事情對我影響很大。我在這個階段上升了一個很大的臺階,從程序上升到軟件。核心思想就從庫函數共享上升到軟件共享。具體過程是建立一個通用的系統架構,架構中有許多共同的功能,例如,參數設置、用戶權限管理、庫表管理等。另外還提供信息建立查詢開發模板,通過配置和特殊功能的編制就能很快完成了一個系統的開發。現在想起來IASG距離我已經有20年了。

第七階段到了IASG階段後,我發現無論技術如何提高,都無法改變開發落後於需求的現實。通俗地說就是:程序員水平再高,僅僅是拉車水平高,但是,應該在什麼路上拉車程序員並不知道。如果這條路是一條光明的路,則程序員越拉越有勁,有前途;如果這是一條死衚衕,則程序員白費工夫;如果這是一條漫長的路,前途不明,則程序員可能要累倒在路上。現實中程序員水平低、收入低;系統需求不明確,系統開發週期一拖再拖;系統重複開發多,信息甚至不能在一個企業內實現共享,更不用說在企業之間、行業之間實現共享了;各種企業級的軟件ERP、CRM、BI層出不窮,也沒有哪個能滿足中國的市場;各種新技術、新概念不斷出現,卻沒有哪種技術或概念能真正發揮其內在價值,最終還是處於被學習、被運用的階段。

這個過程是程序員脫離技術本身,開始思索、開始求源的階段。在這個階段的程序員的思想有了質的飛躍。以前光拉車不看路,現在要擡頭看路了。

第八階段有了擡頭看路的想法,於是我踏上尋路征程。我首先弄明白了我們腳下的路是什麼樣的,爲什麼這條路那麼不平坦、不寬廣。從軟件生命週期來看,軟件主要由用戶需求發起,用戶需求是軟件生存的根本理由。由於企業、用戶的不同而導致不同的需求——大量的無序的需求,這種需求驅動方式必然造成了我前面介紹的各種現象。這個階段是尋找根源的階段。只要我們找到了根源,就可以有機會解決問題。這個過程相對來說比較困難,這不僅需要編程技術,還需要很多方面的知識。若要了解這個根源,就迫使你學習和積累更多程序以外的知識。

第九階段當我找到軟件是需求驅動方式之後,就開始考慮什麼是用戶需求?用戶爲什麼要提出這些需求?我們可以更深入地分析用戶需求產生的根源,我們能否讓無序需求變成有序需求呢?當然針對這些問題我們都進行了深入分析,其過程也很難在這裏展開說明。我只能說,最後結論是用戶的需求來源於企業的經營。很多人思考問題還是就需求而論,並沒有站在企業經營角度去考慮問題。千萬不要小看這個變化,這個變化最終會產生一個理論。於是我們儘可能地站在企業經營角度看待企業經營方式、企業管理、企業信息化等。但是,我們最終要解決企業經營這個概念問題,如果我們都不能明確企業經營這個概念,或者我們不能科學地定義企業經營這個概念,那一切基於企業經營的各種具體現象就如同無本之源一樣無序氾濫。就像ERP、CRM等所謂企業信息化產品一樣,由於沒有一個企業經營定義的支撐,只能就企業經營的某個方面提出解決方案。這些產品不缺乏需求的支持,缺乏的是最基本的企業經營定義的支持。而這個概念就是EOM。

EOM是從定義企業經營角度入手,把我們今後要開展的各種研究和開發活動都放在一個理論可支持的基礎上。只有定義了企業經營之後,我們纔有可能分析我們需要什麼軟件,我們的軟件採用什麼技術才能實現企業經營的目標。而程序員則通過EOM瞭解到企業經營需要什麼樣的軟件,這個軟件有多大的價值,這個軟件採用什麼技術才能實現,自己要提高哪方面的技術水平才能獲得更大的價值。

這個過程就是EOM階段,通過EOM瞭解軟件的根源和有價值的軟件所在,進而選擇自己未來的方向。

第十階段當我建立了EOM之後,便開始了EOM實現階段。這個實現階段分爲兩部分,通過這兩部分的結合,我們就可以逐步看到EOM軟件產品的實例,看到EOM的真正價值。

第一部分是EOM的業務實現。當我們明確了EOM之後,就可以根據EOM來重新規劃企業信息化的整體架構,可以細分這個架構中的各種平臺產品、通用產品、專業產品,可以細分出這個架構實現的各種技術架構和實現手段,可以細分出這個架構中的各種標準功能和標準信息。通過這樣的分析,我們的程序員就可以根據自己的特長和愛好以及價值的判斷來選擇其中的軟件產品和技術。在明確目標和方向的情形下,通過自己的努力,不斷提高自己的各種技能水平,讓自己的價值和企業經營價值有機地結合在一起,從而實現自己的理想。

第二部分是EOM的技術實現。有了EOM並根據EOM理論構建企業信息化的架構後,我們就必須從技術上實現這個架構,否則這個架構將永遠停留在理論階段,不具有可行性。我們可以採用現有的各種技術來實現這個架構,但是,現有的技術都是基於原有的業務需求而建立和發展的,它適用於原來的應用對象。目前的EOM是一個全新的企業經營理念,因此,我們必須建立一種新的軟件架構來適應和最好地實現這個理念。幸運的是,我們找到了稱作NSS(New Software Structure)軟件新架構的技術,該技術體現了適應企業經營發展方向,將軟件合理分層,用最新的軟件技術按照架構的方式規範軟件開發的模式,可以實現最大範圍的功能共享,實現軟件的可擴展性。

這個階段可以讓程序員在軟件產品業務設計或軟件產品技術實現上等多個方面進行深入鑽研,並且成爲領域專家。這和我們平時涉及的簡單的需求分析和簡單的技術實現有着本質區別。

從我的程序員經歷可以看出,程序員的成長是無止境的,只要有的放矢地努力,就會一步步登高向上。我認爲程序員成長經歷主要有三大階段,即通用技術階段、市場階段、專業技術階段。

1)通用技術階段是程序員專注編程水平提高的階段,也就是說“只拉車不看路”階段。這個程序員能做的事情那個程序員也能做,程序員的替代性很強,程序員市場價值相對較低,程序員只關注編程技術本身。

2)市場階段是程序員跳離技術層面開始考慮爲什麼要開發這個軟件,這個軟件有什麼價值的階段,通過求軟件之源來重新認知自己的方向。

3)專用技術階段是程序員認知了這個軟件和技術有很大的市場價值,全身心投入到這個領域中去,並在這個領域成爲專家的階段。程序員不但要懂技術,更要懂得客戶業務,不同的程序員的技術和業務變得沒有可比性,這種稀缺性造就了程序員極大的價值。

這三個階段其實就是三個過程,每一個過程都是一次飛躍。程序員知道自己可以飛多高,依靠的是程序員的學習和眼界;而程序員能飛到哪裏,那就要靠程序員自身的努力。一個程序員可以沒有能力,但是不可以沒有眼界。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章