程式設計師的成長經歷往往很相似，大部分的人走過了最前面相同的一段路，而有的人則走得更遠。總結自己這些年來的歷程，這也許能讓年輕的程式設計師少走一些彎路，成長得更快；或許更好一些，能讓大家從中得到一些啟發，早日進入優秀程式設計師的階段，實現夢想，釋放激情。
第一階段，最初是在學校裡學習計算機基礎知識，學習經典的程式設計語言，編寫測試用的小程式。這個過程可以說是對計算機和程式設計的入門階段。這個階段主要是培養了自己對計算機軟體的興趣，打下了良好的計算機基礎知識。
第二階段，而後參加工作，從事計算機軟體開發工作。按照工作要求，一邊學習，一邊程式設計，終於可以讓自己的程式投入執行了。在這個階段我突然感覺到了自己的價值，感覺到了軟體的神奇，並且自己編寫的軟體成為了實用產品。這個階段實現了學習到生產的過渡。
第三階段，隨著工作的增加，開始編寫各種程序，開發各種系統，這時候忙於程式設計知識的積累和應用。應該說在這個階段自我感覺很充實，好像有做不完的事，程式設計水平還處在語言級階段。
第四階段，隨著積累了一定程式設計技巧之後，我開始想這樣的問題：我是不是最好的程式設計師？我能否編寫出最好的程式？這個過程是一個反思的階段。我對自己的要求是：不但要會程式設計序，而且要編好程式，從關注程式數量開始轉向關注程式質量。
第五階段，開始在提高自己的軟體開發水平上做文章。經過各種系統開發，尤其是大型系統的開發，發現了軟體中有許多功能是重複的。因此，有一段時間把精力花在編制各種庫函式上，通過不同系統呼叫相同的函式，以便減少重複開發，實現功能共享。當時比較得意的是庫函式不是我一個人在呼叫，而是整個專案小組都在呼叫，甚至不同的系統也能呼叫，從而體會到編寫庫函式特別有價值。這個階段的標誌是庫函式，程式設計師水平上升到庫函式那一級。
第六階段，到了庫函式那一級後，很快就發現，單單實現程式函式級的呼叫是遠遠不夠的。當你做了很多專案，包括大專案和小專案，尤其是做過跨行業的專案之後，你就會把庫函式的共享思想用於專案開發。你就會想這樣一個問題：為什麼不同專案不能有相同的架構？如果有相同的架構，那麼開發就有了相對的標準，我們就有可能通過配置的方法實現相同架構的系統。於是我提出了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）專用技術階段是程式設計師認知了這個軟體和技術有很大的市場價值，全身心投入到這個領域中去，並在這個領域成為專家的階段。程式設計師不但要懂技術，更要懂得客戶業務，不同的程式設計師的技術和業務變得沒有可比性，這種稀缺性造就了程式設計師極大的價值。
這三個階段其實就是三個過程，每一個過程都是一次飛躍。程式設計師知道自己可以飛多高，依靠的是程式設計師的學習和眼界；而程式設計師能飛到哪裡，那就要靠程式設計師自身的努力。一個程式設計師可以沒有能力，但是不可以沒有眼界。
本文節選自機械工業出版社《程式設計師成長路線圖：從入門到優秀》一書。該書的作者N216、張磊和吉陽一起回憶和總結了自己幾十年的程式設計師成長經歷，對當前程式設計師關心的熱點、重點、難點問題給出了自己的看法和建議。通過對程式設計師的成長階段進行劃分，使得各個階段的程式設計師都可以“按圖索驥”，解決自己所遇到的問題。
相關文章：《程式設計師的八種級別》
原文：CSDN