程序員成長的10個階段--看了後頗有感觸

程序員的成長經歷每每很類似，大部分的人走過了最前面相同的一段路，而有的人則走得更遠。總結本身這些年來的歷程，這也許能讓年輕的程序員少走一些彎路，成長得更快；或許更好一些，能讓你們從中獲得一些啓發，早日進入優秀程序員的階段，實現夢想，釋放激情。　
　
第一階段，最初是在學校裏學習計算機基礎知識，學習經典的程序設計語言，編寫測試用的小程序。這個過程能夠說是對計算機和程序設計的入門階段。這個階段主要是培養了本身對計算機軟件的興趣，打下了良好的計算機基礎知識。　
　
第二階段，然後參加工做，從事計算機軟件開發工做。按照工做要求，一邊學習，一邊編程，終於可讓本身的程序投入運行了。在這個階段我忽然感受到了本身的價值，感受到了軟件的神奇，而且本身編寫的軟件成爲了實用產品。這個階段實現了學習到生產的過渡。　
　
第三階段，隨着工做的增長，開始編寫各類程序，開發各類系統，這時候忙於編程知識的積累和應用。應該說在這個階段自我感受很充實，好像有作不完的事，程序設計水平還處在語言級階段。
　　
第四階段，隨着積累了必定編程技巧以後，我開始想這樣的問題：我是否是最好的程序員？我可否編寫出最好的程序？這個過程是一個反思的階段。我對本身的要求是：不但要會編程序，並且要編好程序，從關注程序數量開始轉向關注程序質量。　　

第五階段，開始在提升本身的軟件開發水平上作文章。通過各類系統開發，尤爲是大型系統的開發，發現了軟件中有許多功能是重複的。所以，有一段時間把精力花在編制各類庫函數上，經過不一樣系統調用相同的函數，以便減小重複開發，實現功能共享。當時比較得意的是庫函數不是我一我的在調用，而是整個項目小組都在調用，甚至不一樣的系統也能調用，從而體會到編寫庫函數特別有價值。這個階段的標誌是庫函數，程序員水平上升到庫函數那一級。　
　
第六階段，到了庫函數那一級後，很快就發現，單單實現程序函數級的調用是遠遠不夠的。當你作了不少項目，包括大項目和小項目，尤爲是作過跨行業的項目以後，你就會把庫函數的共享思想用於項目開發。你就會想這樣一個問題：爲何不一樣項目不能有相同的架構？若是有相同的架構，那麼開發就有了相對的標準，咱們就有可能經過配置的方法實現相同架構的系統。因而我提出了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）專用技術階段是程序員認知了這個軟件和技術有很大的市場價值，全身心投入到這個領域中去，並在這個領域成爲專家的階段。程序員不但要懂技術，更要懂得客戶業務，不一樣的程序員的技術和業務變得沒有可比性，這種稀缺性造就了程序員極大的價值。　　這三個階段其實就是三個過程，每個過程都是一次飛躍。 程序員知道本身能夠飛多高，依靠的是程序員的學習和眼界；而程序員能飛到哪裏，那就要靠程序員自身的努力。一個程序員能夠沒有能力，可是不能夠沒有眼界。