原文：
http://m.tkk7.com/calvin/archive/2005/11/03/18024.html
除開五大或者ThoughtWorks這種要什么有什么，進去做打字也能光耀門楣的不談。如果是嫁到一個普通軟件公司，怎樣的環境才能最快的成長呢？
首先基本的
公司項目管理水平是必要的；其次是穩健而不保守的公司技術選型和一班能溝通的同事。
更重要的，是要有一個嚴苛的環境，那些古訓說的都沒錯，越是嚴苛，成長越快。 然后有些引導與助力，讓你在嚴寒中節省體力，過得好些的，就是最佳的成長環境了。
一，最復雜多變的業務規則，最難侍候的客戶
大多數人碰上這兩樣東西都是愁眉苦臉，天天抱怨。其實應該把它視為入門鍛煉的：
第一階是努力用細密的編碼迎合復雜的業務，以金牌服務的態度接受客戶的善變和每樣需求都要24小時有取的bt。充分打磨過的眼耳口心，才是個合格的IT人。如果業務規則都清的像水，項目時時都是以我為主的，反是在做toy application，不算入了IT的門。
打磨之后，如果肯靜下心來總結，設計架構如何適應改變，流程如何做到快速更新部署，就是第二階段的進步了。
一直做ERP，自問有足夠復雜的業務(因為不熟悉業務，有些不復雜的也變復雜了)和麻煩的客戶(自己不是大公司，麻煩的客戶就會很多)，但在第二階段還是不很靜得下心。
二，最嚴格的性能要求，準確性要求，錯誤恢復要求
最好是那種每天N萬人訪問，幾億條數據。還有準確性很嚴格，分分鐘幾十萬上下，如果崩機又要迅速完全恢復狀態的項目。
每天幾萬人訪問的項目沒做過，遺憾。
幾千萬條數據的項目倒是每天面對，優化學了一點，但沒有充分利用嚴格的環境去追求改進，遺憾。
ERP的報表倒是經常會搞到幾十萬上下的差額，但一直重視不足。
崩機恢復是最近的項目要求，更爽是這個項目澳國政府居然有一份規范，我說的助力就是指這些了，不用自己慢慢摸索而且經常摸錯地方。
三，最底層的編碼
不要老是高高在上的搞ERP搞.com，偶然嘗試一下用到起碼C一級的語言，和硬件打打交道，直接寫IO口阿，中斷阿，都是有就不要放過的鍛煉。
沒做過底層編碼，只會純軟件的IT人的感覺是不完整的。
剛好公司最近的項目有要求，捧一本
〈Linux Device Driver〉看看。
四，最高層的設計
設計、框架--技術人一聽就眼紅的字眼。但不是每個公司都搞很產品化的項目，或者在項目里自寫類庫重做輪子。所以，除了剛入行的那段瘋狂日子，很高階的設計其實我也沒做多少，多數時間都是應用層的開發。
雖然自己不寫，但卻經常都要進行框架選型，也算是蒸發智力的一個地方。Pragmatic Programmer里說的critical的態度很重要，Spring好么？一定要想清楚它好在哪里，不要糊里糊涂的看著quick start就入局了，渾忘了without Spring的世界是怎樣的。
另外，因為有時候開源軟件有bug，或者要增強它來吻合項目需求，或者有錯了不明就里時直接讀源碼會更快找到錯誤。這樣就接觸到不少優秀開源項目的源碼，比如Spring，無形中也會學到他的設計。
如果說Java盛產框架型的項目，php的項目則多是熟透了的Web應用。最近發現php不是以前的php了，應該算入python,ruby一類的動態OO語言，它的那些著名項目一樣有著很好的MVC框架。細看之下學到應用設計方面的不少東西。
一陣發呆打了這篇字，其實也是提醒自己，目前的環境可以，應該以更好的心態接受更嚴苛的歷練，那些古訓說的都沒錯。
posted on 2007-09-03 21:56
Ke 閱讀(759)
評論(0) 編輯 收藏