我在程式設計師的時候，我一開始追逐這個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、有緊急事務立刻做出果斷解決，繼續前進；
我的團隊終於平靜了下來，但是大家都很疲憊。大家幹的很累，但是由於實施和修改消耗了大量的錢，我們沒有賺錢，大家什麼都沒有得到。團隊很灰心，也很失望。我下了計畫，我自己都很灰心，大家認為再努力也不會再有結果，所以拖拖拉拉，進度和成本已成不可再提的事情。人，缺少了精氣神，就什麼都沒有了。我們就是缺少了這些。我就開始重新建立團隊的精神。我發現有人為了跳槽開始學習新的技術，而這種技術是公司現有產品不需要的，但是他們卻在上班時間作。我先從此下手。我講了技術的方向，讓他們認清他們現在所學將會很快淘汰。我又講了現在市場的實況，讓他們認清外面公司也不好過。我還講了我們所從事的行業多有潛力，我們公司將有新的舉措。人心又開始一點一點收回了。
但是我們仍然需要完成那些未收尾的工作，仍然需要去奔赴新的客戶市場。雖然員工很疲憊，雖然我們剛從飄搖中過來，但是我們不能止步，因為我們為盈利而存在，我們別無選擇。我能夠將**寫的很好，效能很高，產品製造很有計畫和成本控制，團隊很有戰鬥力。但是我發現了乙個問題，我們的產品市場不再擴大了。市場份額大規模開拓已很艱難，因為新產品的新鮮感已經過去了。我們在動盪的日子作的專案給公司帶來了陰影，公司一直沒有大賺錢，投資方很生氣。我明白了。公司畢竟是為利潤而存在的。公司不是為產品製造而存在，不是為了解決別人的問題而存在。賺錢是第一位。不賺錢即使你在**上作的很風光也一文不值。有人靠手賺錢，有人靠嘴賺錢，有人靠腦子賺錢，有人靠身體賺錢，不管黑貓白貓，只要抓住老鼠就是好貓。成在營銷，敗在管理。我開始關注資本運作，聯盟夥伴建設，市場營銷，客戶關係營運。
我知道，生活才剛剛開始。
程式設計師的人生
我始終覺得 低階的程式設計師停留於技術，中級的程式設計師停留於管理，終極的程式設計師 停留於人。因為這個世界的主體畢竟是人，人都有7情6欲，而不是電腦，那些停留於技術的人往往把人想成了電腦，其實人比電腦複雜得多，電腦程式的一卻異常你都能夠catch住，那些異常都不會超過你的意料。但人就不一樣了。人就...
「非」天才女程式設計師的人生
非 天才女程式設計師的人生 天才女程式設計師離開google了。新聞上如是說。很關注她的部落格內容，她一邊稱讚在google的工作，一邊轉身而去 嘗試新鮮事物 我想到三個詞 光榮 風度和瀟灑。看看我們這些人，正如範師傅的名言 同樣都是在電腦上寫程式滴，差別咋就這麼大哩！你有過樣的光榮麼？有人稱你為天...
程式設計師的人生態度
看到別人部落格裡寫的21個故事，其中這個最有感觸，所以也在自己的部落格裡記錄一下。有兩個和尚他們分別住在相鄰的兩座山上的廟裡。這兩座山之間有一條溪，於是這兩個和尚每天都會在同一時間下山去溪邊挑水，久而久之他麼變成為了好朋友。就這樣時間在每天挑水中不知不覺已經過了五年。突然有一天左邊這座山的和尚沒有下...