程式人生之三：從新手到專案管理，五年程式人生路

程式人生之三：從新手到專案管理，五年程式人生路

        很感謝 CSDN 網友 333sunshine 先生的這篇文章。真實記錄了一個平凡程式員，從菜鳥到大蝦，從弱到強，從平凡到閃光的踏踏實實的奮鬥曆程。一步一個腳印，充滿心酸和欣喜，除了奮鬥，我們別無選擇！文章原文部分如下：
        論壇裡很多人都喜歡聊程式人生的話題，我也來發一封文章。給大家一個參考，也讓自己有一翻自省！
        希望更多有經驗的程式員看到後，也能在此記錄一下自己程式生涯，相互學習！
        本人普通院校，非電腦專業本科畢業。從畢業到現在也工作有五年了。回憶起程式人生，也頗有一翻滋味。 
        本人是從大三上學期開始學習電腦的，因為那時電腦突然一下比較普及，本人家裡也有能力買台電腦。買了電腦後，最先看的是 C 語言的資料結構。用電腦調試書裡面的各種程式，那時第一次看資料結構，我接近全力去看，但是沒看懂多少東西。只是把書裡面的代碼敲了一遍，運行後看看是否和書裡面說的結果是一樣。但很多時候，第一次都是沒通過調試的，發現不是這裡抄錯了，就是那裡抄錯了。通過不斷的尋找，最後才能運行正確，那時心裡就會才生少許的成就感，感覺自己寫的程式調通了（雖然只是照著抄了一遍）。看完資料結構（其實有很多東西還是不懂），我去找了本電腦群組成原理來看。結果看得自己更加模糊。因為這本書裡沒有代碼，只有一些抽象概念，當時好像只記得
CPU 有幾個寄存器定址，還有些補碼，反碼什麼的。那個書又厚，硬著頭皮翻了一遍後就沒看了。接著買了本作業系統原理來看。也是很難看，都是些概念的東西，又沒代碼調試。比如什麼 GDT，虛擬記憶體分段，分頁，實模式，保護模式，中斷等等。也是硬著頭皮翻一遍，能懂多少是多少。看完後，接著就看那個編譯原理，因為網上都說懂編譯原理的人都很牛，我也希望變成牛人所以也去搞了本回來看。結果發現，能懂編譯原理的人，確實比較牛。裡面涉及到自動機的概念。屬於用電腦來做人工自能的範疇。我也很想成為牛人，硬著頭皮看，結果還是有心無力。經過這樣一個過程，雖說很多都不懂，但卻使我對編程從一無所知到有了一種模糊的認識。大概懂得了什麼叫做記憶體配置，還有程式的那些字母符號是怎麼被電腦執行的。這時回頭把原來的資料結構翻出來再讀一遍，突然發現這本書比起其他三本都容易，也很好懂。明白了什麼叫做演算法，並且可以嘗試去實現自己想的一些演算法。當時的自豪感油然而生。感覺電腦可以按照我的想法去工作了，非常興奮。雖然那時我並不懂得多少
C 語言，對指標也只大概知道是什麼東西，實際中還是不會應用。但至少可以利用我所知道的，來實現我所想到的。在當時一股衝動之下，寫了幾個自己記憶由心的演算法： 
        1，從 1 到 100，每數到 7 的時候，把該數字提出來，剩下的數字繼續迴圈，問最後剩下的一個數字是多少。我記得好像是 50。 
        2，任意輸入數字，和“+ - * / ( )”幾個符號組成一個算術運算式，計算出值是多少。 
        3，記得看過電腦群組成原理裡面有個磁碟調度演算法，用的是現在電梯常用的電梯演算法。感覺這個演算法很好，就去用C語言實現了一遍。 
        剛開始寫程式，都是一個 main 函數全部搞定。慢慢的，在演算法實現的過程中發現，如果一個演算法太大，一路寫下去，代碼會很長，並且很容易想了前面就忘後面該怎麼寫，或者寫到後面，忘了前面寫的是什麼。 這時，就產生了一種想法，就是剛開始設計演算法的時候，想好哪幾步，然後每一步用一個函數代替。main 函數中只是分步函數的流程式控制制。這樣 main 函數的代碼就大大的減少，邏輯變得非常清晰。然後可以像填空一樣把每個分部函數完成。接著在子函數裡面還可以分成子函數，分到後來，發現很多函數可以被其他的函數調用。達到重用的目的。記得當時發現這個方法後，也是異常的興奮。這種方法居然被自己想到了，感覺自己真是個人才。因為自己是非電腦專業，想找編程的工作，起碼要有一個東西證明自己是學過電腦的。所以在這期間報考了那個進階程式員（高程），因為要考試，所以學習了一些彙編之類亂七八糟的東西。考試好像分為筆試和上機，但是現在已經忘記是哪一個沒過了。鬱悶！沒過之後，不甘心，就去報了個電腦等級考試（3
級，互連網技術），結果不出意外，將認證收入囊中（不過現在想想，一點都沒用上。拿回來後，從來都沒給人看過，現在都不知道放到哪裡去了）。 
        搞完這些，自己大三也差不多結束了。自己也知道到了大四要開始找工作，所以不能自己專門去研究什麼演算法。那個東西當不了飯吃。所以要搞一些比較流行的東西，起碼需要混到一個工作。所以那時就搞了一本“C# 入門經典”。因為那時聽說 .NET 比較流行，好找工作。並且對於一個新的東西，我比較喜歡找一些名字上有“入門”兩個字的書（這樣的書裡面一般都會很詳細的告訴你如何搭建調試環境）。因為程式這個東西，你首先要能夠搭建一個調試環境，光靠看是看不出什麼東西來的。後來感覺這本書還不錯，不枉費我 100 塊大洋。從中學到了一些
.NET 的基本用法。並且對物件導向講得比較詳細。“物件導向”那一章我也很認真的反覆看了好幾遍，因為那時 03 年物件導向非常熱門，網路上面到處是“物件導向”幾個字，感覺編程高手都是會物件導向。我也想成為高手，所以我就抱著一種不搞懂不罷休的氣勢去看。結果，只是記住了物件導向的文法。書中和網上舉得例子也很簡單，多半是些動物是抽象類別，然後，分什麼雞，鴨，鵝之類的去繼承，然後動物都有吃飯的介面，鴨子有遊泳的介面, 此類等等的例子。看了半天，也沒弄明白這些對於我寫程式有多大的作用。後來，從書上抄了一份網站購物車的程式，認識到了
WEB 的開發流程，感覺自己也可以上路了。因為當時才大四上學期，也沒有到處發簡曆。只是在網上留意一些招聘資訊。當時也是在 CSDN 裡面，看到一個本地的公司在招人的文章，公司很小，剛起步。我想應該不會要求很多，我也就去應聘試試，希望自己能夠應聘上，這樣至少能夠證明自己有資格成為程式員。應聘的時候，老闆問了一些問題，多半是 WEB 開發方面的技術問題。由於那時我對 WEB 只是剛剛接觸，懂的不多。好像當時有一半以上都沒回答上來。走的時候，我把我從書上抄的那份程式放到電腦裡運行出來給他看了看。大言不慚的說者是我寫的。他看了看，點了點頭，然後就回去等訊息。我是星期五去面試的，星期天公司打電話讓我星期一去上班。聽到這個訊息後，心裡莫名的激動。請同寢室的哥們大吃了一頓。大家也都為我能這麼早找到工作感到高興。後來，就是白天到公司實習，晚上回寢室睡覺。工作後慢慢的，那種興奮感就消失了，取而代之的是工作壓力，由於做
WEB 開發，服務端的 C# 還好說一點，但是前台用到很多的是 HTML 和 JAVASCRIPT，當時對這個知道的很少，只能一邊翻書，一邊做事。要達到老闆的要求，每天都八點左右才能搞完下班。 

        工作漸漸展開之後，就是平靜如水的生活，每天上班，吃飯，睡覺，日子也過得很快。剛開始，由於懂得東西少，所以每次任務下來後，都是積極的去完成，因為害怕自己做不完。但是漸漸的，當自己清楚該怎麼做的時候，人會產生疲倦，因為每天都做一些差不多的勞動。慢慢的，做事情就喜歡拖拉了。當分配一個任務後，自己先估量一下這個工作自己大概需要多久，一般老闆給的時間會多很多。所以喜歡把工作先放著，去看看網頁，逛逛論壇什麼的，等到剩下的時間差不多了，需要開始工作了，就懶洋洋的進入工作狀態，但是往往完成工作品質都不怎麼好，很多提交後會有些
BUG。不過我也沒怎麼在意。因為和老闆關係好嘛，像我這樣，再怎麼說也屬於元老層級的。就這樣慢慢的工作了幾年。因為小公司什麼都要做，技術也積累了很多。包括各種主流資料庫的用法，.NET，CSS,JAVASCRIPT,PHP,JAVA,perl,FLASH, 等等，其間，自己獨立開發項目的時候，總想找出一種架構，加快自己下一個項目的開發進度。但是每次開發完後，發現上次設計的架構真垃圾。開發過很多項目，每次都想了一些新的架構方法。到現在沉澱下來的還值得用的架構思想也沒多少。記得在做 JSP 的時候，感覺 JSP
裡面服務端代碼和 HTML 混在一起，很難看。不如 .NET 的事件驅動好用。就去寫個模組，讓 JSP 也實現事件驅動的模式。結果寫到後來，也沒得到什麼好處，並且感覺有點不倫不類， 

        後來項目慢慢做大了，才漸漸明白物件導向的用意。當一個項目很小，邏輯很簡單的時候，用物件導向的方法設計用處不大，反倒是組件用處更大。因為項目小，基本上都是建幾張表，改改 HTML 的工作。但是項目一大，邏輯變複雜了，如果你要理清楚邏輯，這裡就需要一種方法論。我一開始寫演算法的那種方法有點不適用了。原來那種是從頂層開始，向下細分。是一種至上而下的設計方法。而物件導向不是，它是一種由點及面的設計方法。物件導向是先找出一個個對象點，然後再找出每個點之間的關係。在實際的項目中，你很難從上至下的設計。因為項目需求往往剛開始很不全面，很多項目後來改得都是面目全非。從上至下的設計不適合這種平凡的修改。並且當需求很大時，他涉及東西太多，你也很難從一個俯視的角度去全面的看這個系統。所以從上至下的設計不能滿足要求。打個比方，記得一個項目已經做了
80% ，結果客戶覺得用得不方便，要改一下。很多原來做的功能都不需要，並且提了幾個新功能。但這幾個功能也只是對原來的功能稍加改動。但是邏輯上看卻是大相徑庭。人腦不是電腦，如果想著這個代碼，去改那個代碼，勢必到後來讓自己也搞糊塗了。所以需要抽象出幾個對象出來，是按照客戶的思維方式。然後抽象出來的對象裡麵包含原來的功能。這樣做起來就事半功倍。 

        在工作的磨練中，慢慢的發現了普通的程式員與優秀的程式員的一些差別：
        1, 普通的程式員遇到問題喜歡張口就問別人，問之前沒經過大腦想想。這是一個不好的習慣。其一，自己都沒仔細想想，就算別人幫你把問題解決了，你自己不多久就會忘記。下次遇到，照樣是不會。因為這個問題你沒有經過大腦。其二，能夠回答你問題的人，多半是有一定經驗了。他們或許很會安排好自己的事情，管理好自己的時間。如果時常去打斷他們，他們會覺得你很煩。 

        優秀的程式員多半會先到網上尋找一下相關問題，看看網上有沒有相關解決方案。經過一翻尋找，他會把這個問題記得比較牢。
        2，在一個項目的合作開發中，普通程式員往往只瞭解自己開發那方面的東西。項目做完後往往對整個項目有哪些功能都不太清楚。可能會有人抱怨，自己工作都做不完，哪有時間去瞭解整個系統。但現實多半是，花大量的時間去網上閑逛，卻不願花時間去增進知識。 如果總認為項目的設計是設計者的工作，自己沒必要去瞭解。那麼這樣的程式員只能是手工勞動者。
        優秀的程式員會對整個項目有認識，對一些自己感興趣的功能會去做一下瞭解，更優秀一點的，會去對整個項目的架構設計做一下瞭解。自問如果他是項目設計者該怎麼做? 去學習項目設計的優秀之處，去發現設計的不足之處。觸類旁通，把優秀的地方用在自己將來的工作當中。
        3，普通程式員往往有很大的惰性。不能自覺的去學習知識，增進能力。所以每天耗費大量的時間在一些消遣狀態中。所以時間往往白白的浪費掉。
        優秀的程式員往往會安排好自己的工作和學習。在工作中學習，在學習中工作。能夠感覺到自己每天都向著自己的目標在前進，狀態佳，動力足。他們因為每天工作情緒很高，所以研究的東西也多，時間比較寶貴。因此他們會善於利用一些工具來操作自己的電腦，大大來的減少瑣碎的電腦操作時間。更有勝者，會開發一些符合自己的操作習慣的小程式，來提高自己的效率。說不定這些小程式放到網上共用，可能還會有意想不到的收穫。
        我現在做專案系統管理員，看著手下的程式員，時常也讓我想起原來做程式員時候的壞毛病。比如，上班遲到啊，工作時間上網閑逛啊，交上來的程式 BUG 成堆啊...！看到這些，我時常都是會心的笑笑，可以理解! 不過我也時常提醒他們，如果你們想將來成為 IT 界的精英，而不是等到 30 歲感覺自己無路可走，那麼請你們珍惜自己的時間。如果你們自己都不珍惜自己的時間，那麼別人更不會去珍惜你的時間。 

        今天花了兩個多小時，寫了一篇短篇自敘。感覺值得，把自己五年多的光陰回顧了一遍。從前的故事曆曆在目。寫下來過五年後再來回顧一下，說不定會是另一番感受。

原文連結：http://topic.csdn.net/u/20090509/00/c5af1bc2-04a4-4615-be77-de36a79f062d.html。