學習
1 學習oop時要結合ood,ooa,否則是很難理解什麼是物件導向設計。
2 了解uml
3 了解設計模式
4 學習開源專案
5 專案比較大時,可以先用uml作圖，問題不清楚時，也要先畫圖。比較清楚解決方案時，可以先寫測試用例，這樣也可以把類的結構考慮清楚，自動解耦。
6 多看書，多去好的blog，msdn，少去論壇
7 數學是計算機的基礎。
8 學校學習的計算機基礎課是你不能忘記的。
9 每天要看些英文的資料，至少要保持住自己的英文水平。
10 合理的安排時間，做好計畫。
如果要成為負責，高效的程式設計師一定要寫測試用例，否則維護**時，需求改變時就是你後悔的時候。
一、對復用你的**的人、維護你的**的人都是莫大的財富，如果沒有測試用例，即使**的結構很完美，耦合性很低，維護起來也是很難的。原因是，沒有方便的測試方法，讀**要比讀測試用例費力的多。
二、對自己以後的維護也方便。如果沒有測試用例，隨著時間的流逝，遺忘的會很多。即使自己維護，也是頭疼的事情。更要命的是會產出對維護的恐懼和惰性。
三、測試用例一定要在寫**前寫，不要試圖為舊**新增測試用例，那是不可能的。
除非看到效能受影響的跡象，否則不要過多考慮效能問題，通常架構的合理性要比效能重要，實現的簡單性也比效能重要。改進效能的前提：
一、效能影響到程式的執行，或者客戶對效能有嚴格的要求。
二、有證據表明此項改進能顯著提高效能。
三、改進效能是比較簡單的工作，如果改進很難實現並且改進後效能提高也很少就不應該花費時間在效能的改進上面。
一、bug要發現乙個解決乙個，不要讓它過夜。自己不要有僥倖的想法，事情總會向壞的方向發展。
二、語言只是工具，不要認為任何一種語言是最優的，只有最合適的。
開始專案前，一定要仔細考慮自己的能力，不要盲目答應專案的完成時間，如果時間緊就要明確的告訴上司，專案不能完成，要求加時間，否則匆匆的開始乙個專案，結果只能是不能完成的任務，推倒重來會浪費更多的時間。
xp提倡的沒有計畫是不可能的，最少要有個簡單的規劃，太細了也是浪費。
專案中最重要的是人，如果大家都沒有了動力，所有的一切都是無源之水。
如果對某種模式還不是太熟悉，就不應該在專案中套用，而應該通過重構回歸到模式。關於設計和設計模式：
一、 應用設計模式的目的是封裝「變化點」，用以達到兩個目的：在需求變化時通過簡單的修改，能使舊的設計適應新的需求，增加了程式的靈活性；改進系統的設計，降低耦合提高復用度。要實現這種靈活性，通常要犧牲系統的效能，並且加大編碼的難度，因此如果系統是穩定的，就沒有必要應用設計模式，那樣不會帶來任何好處。
二、 要正確認識耦合性，完全解耦是不可能的，因此選擇設計模式時要選擇合適的，如果稍大的耦合不會帶來問題，就應該選擇輕量級的模式，雖然它的耦合度較大，但是它比重量級的模式易於實現和維護。合適的就是最好的，過猶不及。
三、 要重視依賴關係，依賴不能形成環，也應該儘量減少傳遞。
四、 要注意uml圖的粒度，細節的東西應該用**表示而不是圖，同樣如果要考察程式的邏輯是否合理也不應該通過讀**而是要通過圖，我認為這是應該用圖還是**的分界點，再比它高的層次，都應該有圖形的表示。
五、 要注意類之間的依賴，盡量做當把類從乙個專案移動到另乙個專案時，此類可以重用，而不必修改此類的內部實現。要如此，首先就應該保證：除了引數不應該允許其他依賴關係存在。
六、異常的拋出點要認真考慮，該被調方法丟擲的，就不要把此異常擴散到每個呼叫者，而讓呼叫者丟擲。
七、每種uml圖都有他要著重表現出的東西，還有他能表現但他不能完美表現的東西，因此不要試圖用一種圖去表現應該用另一種圖表現的內容。
八、要保持**、注釋、uml的一致性。
九、 不要在正進行的專案中加入未來的需求，不要考慮適應未來需求的可擴充套件性，需求的變化永遠要比你想象的劇烈，通常那種需求永遠也不會被用到，這樣做只能加大維護的難度和實現的複雜度。正確的做法應是，抽象出需求，提煉出抽象的介面，如果未來的需求滿足這個介面那麼你就是幸運的，否則也沒有什麼大的損失（dip）。
十、 設計介面時一定要慎重考慮，介面一旦確定，就應該保持穩定，即使介面方法的引數也應該穩定（webservice）。
十一、 如果乙個專案是幾方合做的，最好能定義好介面，並且有虛擬的實現，這樣整合的時候會少很多問題。
十二、 任何專案，都要先把框架搭好，然後再實現細節。
十三、 變數名應該有明確含義，而不要選用沒有明確含義的名詞。如：變數命名為date是不合適的，要用createdate等有明確含義的名字代替
十四、能用強型別，不要用弱型別。讓錯誤盡可能的在編譯時暴露。
程式總會出現bug，因此除錯對程式設計師來說特別重要。
一、vs2005比vs2003的除錯環境要好的多，不僅方便而且能看到更多的資訊
二、在vs2005中，我覺得最常用到的除錯視窗是：監視、區域性變數、呼叫堆疊、命令、輸出這幾個是通用的視窗；反彙編、記憶體、暫存器在分析記憶體資訊，**細節的時候要用到；執行緒、模組、程序在分析資訊的時候也會用到；除錯指令碼的時候會用到指令碼資源管理器。
因為vs2005有自己的web伺服器，如果要用iis觸發除錯就應該設定為「使用自定義伺服器」。
如果想看到更多資訊可以載入sos除錯擴充套件。
好書是不需要太多例子的，例子只起點睛的作用，如果一本書例子很多只有兩個原因：
一、純粹是例子書，如××幾千例，沒有什麼可讀之處。
二、作者不能用語言把自己的想法表達清楚，只能用例子湊數。
一、ultraledit，檔案比較，排序，正規表示式
二、reflector，檢視.net類的內部實現方式，學習微軟的實現。remotesoft,更強大些。
三、nunit，單元測試。
四、log4net，日誌記錄工具。
五、regexdesigner，正規表示式分析工具，小巧實用。regexbuddy，功能更強大
六、code**ith，**生成工具。
七、ilda**，反彙編工具
八、nhibernate，orm絕對是大勢所趨，他讓資料操作變的方便，靈活。目前.net所缺少的就是乙個有權威性的orm產品。
九、xmlspy，xml編輯工具，可以呼叫webservice
十、ndoc，文件生產工具
十一、 ethreal，traceplus抓包工具。
十二、 ea，uml工具
十三、 sos，除錯擴充套件
程式設計師需要的幾個優良品質
善用搜尋引擎 好記性不如爛鍵盤 網路上最多的一類博文就是技術類博文，這些博文幾乎都是程式設計師寫的。程式設計師這個群體每天都在處於學習之中，加上乙個無比熱愛技術和熱於分享的心 裝逼的心 寫些技術博文自然是理所當然了。混跡於各大論壇 民間大神出論壇。如果想找大神，最好的辦法就是去各種技術類論壇，看看大...
漫談程式設計師需要關注的幾個細節
細節決定成敗 劉陽在分析的過程中多次提到 為了能夠讓成千上萬的手機使用者獲得更好的體驗，設計師不僅僅要考慮使用者介面的美觀程度，同時也一定要從心理學的角度去充分考慮手機使用者的使用場景，使用習慣。比如 應提供 一鍵操作 來幫助使用者快速完成最主要的任務，應該讓使用者脫離使用手冊輕鬆地完成相應的操作，...
好的程式設計師和差的程式設計師
好的程式設計師，軟體產品質量高，問題少，維護工作量小 差的程式設計師，產品不斷地出問題，不停地修修補補 所以，專案更離不開差的程式設計師，因為問題不能沒有人解決。好的程式設計師，文件和編碼清晰，工作容易交接給其他人員 差的程式設計師，文件和編碼混亂，那堆可怕的複雜邏輯只有他自己能理解 所以，差的程式...