好程式員需要主要的幾個地方

來源:互聯網
上載者:User

學習
1 學習OOP時要結合OOD,OOA,否則是很難理解什麼是物件導向設計。
2 瞭解UML
3 瞭解設計模式
4 學習開源項目
5 項目比較大時,可以先用UML作圖,問題不清楚時,也要先畫圖。比較清楚解決方案時,可以先寫測試案例,這樣也可以把類的結構考慮清楚,自動解耦。
6 多看書,多去好的Blog,Msdn,少去論壇
7 數學是電腦的基礎。
8 學校學習的電腦基礎課是你不能忘記的。
9 每天要看些英文的資料,至少要保持住自己的英文水平。
10 合理的安排時間,做好計劃。   

TDD:

如果要成為負責,高效的程式員一定要寫測試案例,否則維護代碼時,需求改變時就是你後悔的時候。

一、對複用你的代碼的人、維護你的代碼的人都是莫大的財富,如果沒有測試案例,即使代碼的結構很完美,耦合性很低,維護起來也是很難的。原因是,沒有方便的測試方法,讀代碼要比讀測試案例費力的多。
二、對自己以後的維護也方便。如果沒有測試案例,隨著時間的流逝,遺忘的會很多。即使自己維護,也是頭疼的事情。更要命的是會產出對維護的恐懼和惰性。
三、測試案例一定要在寫代碼前寫,不要試圖為舊代碼添加測試案例,那是不可能的。

 效能

除非看到效能受影響的跡象,否則不要過多考慮效能問題,通常架構的合理性要比效能重要,實現的簡單性也比效能重要。改進效能的前提:
一、效能影響到程式的運行,或者客戶對效能有嚴格的要求。
二、有證據表明此項改進能顯著提高效能。
三、改進效能是比較簡單的工作,如果改進很難實現並且改進後效能提高也很少就不應該花費時間在效能的改進上面。

態度

一、bug要發現一個解決一個,不要讓它過夜。自己不要有僥倖的想法,事情總會向壞的方向發展。

二、語言只是工具,不要認為任何一種語言是最優的,只有最合適的。 

項目

開始項目前,一定要仔細考慮自己的能力,不要盲目答應項目的完成時間,如果時間緊就要明確的告訴上司,項目不能完成,要求加時間,否則匆匆的開始一個項目,結果只能是不能完成的任務,推倒重來會浪費更多的時間。

XP提倡的沒有計劃是不可能的,最少要有個簡單的規劃,太細了也是浪費。

項目中最重要的是人,如果大家都沒有了動力,所有的一切都是無源之水。

設計以及實現細節

如果對某種模式還不是太熟悉,就不應該在項目中套用,而應該通過重構迴歸到模式。關於設計和設計模式:
一、    應用設計模式的目的是封裝“變化點”,用以達到兩個目的:在需求變化時通過簡單的修改,能使舊的設計適應新的需求,增加了程式的靈活性;改進系統的設計,降低耦合提高複用度。要實現這種靈活性,通常要犧牲系統的效能,並且加大編碼的難度,因此如果系統是穩定的,就沒有必要應用設計模式,那樣不會帶來任何好處。
二、    要正確認識耦合性,完全解耦是不可能的,因此選擇設計模式時要選擇合適的,如果稍大的耦合不會帶來問題,就應該選擇輕量級的模式,雖然它的耦合度較大,但是它比重量級的模式易於實現和維護。合適的就是最好的,過猶不及。
三、    要重視依賴關係,依賴不能形成環,也應該盡量減少傳遞。
四、    要注意UML圖的粒度,細節的東西應該用代碼錶示而不是圖,同樣如果要考察程式的邏輯是否合理也不應該通過讀代碼而是要通過圖,我認為這是應該用圖還是代碼的分界點,再比它高的層次,都應該有圖形的表示。
五、   要注意類之間的依賴,盡量做當把類從一個項目移動到另一個項目時,此類可以重用,而不必修改此類的內部實現。要如此,首先就應該保證:除了參數不應該允許其他依賴關係存在。
六、異常的拋出點要認真考慮,該被調方法拋出的,就不要把此異常擴散到每個調用者,而讓調用者拋出。
七、每種UML圖都有他要著重表現出的東西,還有他能表現但他不能完美表現的東西,因此不要試圖用一種圖去表現應該用另一種圖表現的內容。
八、要保持代碼、注釋、UML的一致性。
九、   不要在正進行的項目中加入未來的需求,不要考慮適應未來需求的可擴充性,需求的變化永遠要比你想象的劇烈,通常那種需求永遠也不會被用到,這樣做只能加大維護的難度和實現的複雜度。正確的做法應是,抽象出需求,提煉出抽象的介面,如果未來的需求滿足這個介面那麼你就是幸運的,否則也沒有什麼大的損失(DIP)。
十、   設計介面時一定要謹慎考慮,介面一旦確定,就應該保持穩定,即使介面方法的參數也應該穩定(WebService)。
十一、   如果一個項目是幾方合做的,最好能定義好介面,並且有虛擬實現,這樣整合的時候會少很多問題。
十二、   任何項目,都要先把架構搭好,然後再實現細節。
十三、   變數名應該有明確含義,而不要選用沒有明確含義的名詞。如:變數命名為date是不合適的,要用CreateDate等有明確含義的名字代替

十四、能用強型別,不要用弱類型。讓錯誤儘可能的在編譯時間暴露。

調試

程式總會出現Bug,因此調試對程式員來說特別重要。

一、VS2005比VS2003的調試環境要好的多,不僅方便而且能看到更多的資訊

二、在VS2005中,我覺得最常用到的調試視窗是:監視、局部變數、呼叫堆疊、命令、輸出這幾個是通用的視窗;反組譯碼、記憶體、寄存器在分析記憶體資訊,代碼細節的時候要用到;線程、模組、進程在分析資訊的時候也會用到;調試指令碼的時候會用到指令碼資源管理員。

因為VS2005有自己的web伺服器,如果要用IIS觸發調試就應該設定為“使用自訂伺服器”。

如果想看到更多資訊可以載入SOS調試擴充。 

選書和文章

好書是不需要太多例子的,例子只起點睛的作用,如果一本書例子很多隻有兩個原因:

一、純粹是例子書,如××幾千例,沒有什麼可讀之處。

二、作者不能用語言把自己的想法表達清楚,只能用例子湊數。


有用工具軟體

一、UltralEdit,檔案比較,排序,Regex

二、Reflector,查看.net類的內部實現方式,學習微軟的實現。Remotesoft,更強大些。

三、Nunit,單元測試。

四、Log4net,日誌記錄工具。

五、RegexDesigner,Regex分析工具,小巧實用。RegexBuddy,功能更強大

六、CodeSmith,代碼產生工具。

七、IlDasm,反組譯碼工具

八、Nhibernate,ORM絕對是大勢所趨,他讓資料操作變的方便,靈活。目前.net所缺少的就是一個有權威性的ORM產品。

九、XMLSpy,xml編輯工具,可以調用Webservice

十、Ndoc,文檔生產工具

十一、       Ethreal,TracePlus抓包工具。

十二、       EA,Uml工具

十三、       SOS,調試擴充

 

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.