google了一下
已經被廣泛ZT了:)
一個程序員的一生
----------------------------------------------------
作者:佚名
我在程序員的時候，我一開始追逐這個API怎么用，數據庫SQL怎么寫更優化，Dcom技術的細節，然后我發現我寫出來的產品為了符合客戶需求必須要大量修改，但是我的代碼卻粘在了一起，
第一個感覺就是一個函數太長，一看就頭痛，而且一個函數干了好多事。這些事本來可以一段一段的，每段寫上注釋，然后有意義命名，自己管理錯誤和內存，然后把這些函數連在一起，
然后我作了這些：
1、小函數；
2、寫上注釋；
3、有意義命名；
4、自己管理錯誤和內存；
5、流程函數；
最后我發現我這些函數可以組合成各種各樣的流程，我的程序終于好修改了，我很高興。但是我又發現，我的界面和我的流程混在了一起，另一個程序也想使用我的函數，但是我的函數中有對我的特定界面關聯的代碼，我不能連界面一起都給他，因為他有他的界面，但作的事我已經實現了，于是我把功能函數和界面控制分開了
我就作了這些，我的代碼很容易理解，即使新員工，只要他看完業務手冊和數據結構，他就明白我代碼為什么這么寫。而且我的函數由于都是自己負責輸入參數和輸出參數的校驗，有明確和統一的報錯信息，所以很容易找到錯誤進行BUG修復。由于我的程序都是小函數組成的，都有明確報錯，所以錯誤很容易找到，經過測試組的專業測試后，我的代碼很穩定，即使出錯，也擴散不大，都是小bug，對系統整體沒有大影響
雖然我在前進的過程中也經歷過困惑，一心鉆在OOP和設計模式中。但是有可能是功力不夠，不得其解。看著Delphi的源碼,應用了很多的OOP和模式，并且他的類庫多年發展也沒有多大的改變，所以深信OO和模式的威力，而對自己的能力很灰心。但是代碼還得繼續寫，還想進一步提高，于是才摸索出現在的一套做法。既實用又簡單應用，每個人都能辦到。
我認為我的代碼方法已經可以滿足現在的產品制造，并且在軟件性能調整上也積累了一些珍貴的經驗。我發現性能最容易提高也效果最明顯的就是用SQL profilter，優化SQL。優化代碼，因為涉及到業務，很不好著手。優化數據庫結構，由于代碼都是構建在特定數據表之上，所以這是最難改的地方，但是我高興了沒多久，我又遇到問題了。因為我的程序即使再好改，但是客戶的需求真是千奇百怪，我每天在接聽用戶的電話，并且修改用戶千奇百怪的問題。我很煩。于是我作了實施員。我想真正看看客戶到底怎么回事。于是我理解了很多。我明白了很多的事情不是技術和軟件所能解決的，而是現實環境的弊病。但是這個弊病還不是一個工程就能解決的，這是一個復雜的網。所以這些問題我就說服用戶不要用軟件來處理，因為軟件是死的，而人的做法是靈活的。而且我發現用戶雖然提了很多需求，但是有的需求他一個月用不了一次，但是修改起來卻不容易。有的需求修改完，在實際應用中卻發現不可行，那個需求只是客戶想解決過去的問題而想的一個辦法根本沒有經過實際的校驗。有的需求修改來修改去都是表面問題，在實際應用中才發現重點問題沒有提需求所以上線又擱下了，我作了總結：
1、軟件擅長大數據量計算和查詢，還有數據聯網共享，如果需求不能發揮軟件特點，就不讓軟件實現。這樣我少修改了一些；
2、有的需求都是表面需求，修改了也用處不大，反而耽誤了重點需求的提出和修改，所以告訴用戶只修改核心功能。但是用戶提了很多需求，不修改完不上線。后來發現，由于他們沒有深刻理解我們系統的整體思想，所以沒有上線實際用，根本不知道新改的功能是否好用。用戶只是脫離了整體，單獨思考想怎么就怎么，沒上線根本他不知道后果，怎么說也不行，就得讓他看見教訓他才反悔，但是已經修改了。往往出現這樣的情況。最后得出一個結論：一次只提三個需求，并且用書面提出，免的說了不算算了不說。核心功能的需求修改可以滿足80％的日常使用就上線。這樣我少修改了很多；
3、并且我在實際做工程中，積累了大量的經驗，寫成FAQ，各種成功案例，讓用戶在沒有提需求之前先看看自己到底有多少老軟件實在不能解決而才買新軟件幫助的事。新軟件就是解決你過去解決不了的事。如果你沒有解決不了的事，提什么需求；
我的產品終于可以很快完成上線，所以可以大規模推廣市場了，但是我們的產品制造又出問題了。因為客戶越來越多，客戶的需求越來越多。我們需要開發更多的系統，但是我們的時間有限，我們的人手有限，而且我們的人手大多是新手。怎么辦。我們遇到了災難。我們的代碼質量因人而異。我們的版本管理混亂。我們的文檔沒有人編寫，大家都被分配到用戶處去上線。怎么準備數據字典，怎么切換系統，怎么記錄客戶需求，怎么管理系統，怎么修改代碼，我們沒有任何記錄。現場不能離開程序員一步，一離開用戶出事了就不知怎么辦，沒有任何可查的資料。于是我又做了項目管理，我們缺少很多規范。事有千萬，先從緊處來。寫文檔費時間，就開會給大家講做事的經驗。實施和代碼修改需要什么必要規范就制定什么規范。在這期間最容易犯的錯就是中央集權，什么事都必須自己做主。下屬不管大事小事都請示你。我被搞的什么都干不了，都成了救火隊員。我的團隊陷入了混亂之中，因為我煩亂之中作了很多飲鴆止渴的決定。我于是又犯了一個錯誤，我說你們能決定的事盡量自己決定，不要問我，我權利下放。結果是：各自作各自的事，互相不通知。有的事沒人管，有的事多人修改，各有一套。
我終于明白了，我作了以下總結：
1、項目經理是找到得力的人，指導他們做事的方向。如果下屬不知如何作時，及時提供給下屬做事方法；
2、制定規范，其實也就是做事方法；
3、制定計劃，分配人力去作。檢查結果；
4、有緊急事務立刻做出果斷解決，繼續前進；
我的團隊終于平靜了下來，但是大家都很疲憊。大家干的很累，但是由于實施和修改消耗了大量的錢，我們沒有賺錢，大家什么都沒有得到。團隊很灰心，也很失望。我下了計劃，我自己都很灰心，大家認為再努力也不會再有結果，所以拖拖拉拉，進度和成本已成不可再提的事情。人，缺少了精氣神，就什么都沒有了。我們就是缺少了這些。我就開始重新建立團隊的精神。我發現有人為了跳槽開始學習新的技術，而這種技術是公司現有產品不需要的，但是他們卻在上班時間作。我先從此下手。我講了技術的方向，讓他們認清他們現在所學將會很快淘汰。我又講了現在市場的實況，讓他們認清外面公司也不好過。我還講了我們所從事的行業多有潛力，我們公司將有新的舉措。人心又開始一點一點收回了。
但是我們仍然需要完成那些未收尾的工作，仍然需要去奔赴新的客戶市場。雖然員工很疲憊，雖然我們剛從飄搖中過來，但是我們不能止步，因為我們為盈利而存在，我們別無選擇。我能夠將代碼寫的很好，性能很高，產品制造很有計劃和成本控制，團隊很有戰斗力。但是我發現了一個問題，我們的產品市場不再擴大了。市場份額大規模開拓已很艱難，因為新產品的新鮮感已經過去了。我們在動蕩的日子作的項目給公司帶來了陰影，公司一直沒有大賺錢，投資方很生氣。我明白了。公司畢竟是為利潤而存在的。公司不是為產品制造而存在，不是為了解決別人的問題而存在。賺錢是第一位。不賺錢即使你在媒體上作的很風光也一文不值。有人靠手賺錢，有人靠嘴賺錢，有人靠腦子賺錢，有人靠身體賺錢，不管黑貓白貓，只要抓住老鼠就是好貓。成在營銷，敗在管理。我開始關注資本運作，聯盟伙伴建設，市場營銷，客戶關系營運。
我知道，生活才剛剛開始。