.net的經驗和心得分享

beifengwang發表於2013-10-15
“授人與魚不如授人以漁”那麼我這個“漁”究竟是什麼呢?大家做軟體也有不少年了對自己擅長的一門或多門技術都有自己的經驗和心得,但總的來說可以分為向內和向外以及擴充套件三個方面(這裡只針對.NET平臺)



一)向外:
會使用ASP.NETWinFormASP.NETMVCWPFSilverlightWFWCF等技術,用這些技術做專案的同時積累了較豐富的經驗,那麼大家就可以形成自己的一套開發知識庫,知道這些技術怎麼能快速搭建企業所需要的應用、知道這些技術在使用中會出現什麼樣的問題以及如何解決。那麼在這個時候你就可能已經在團隊中起到比較核心的作用,如果專案經理給你一個任務,也可以很輕鬆且高效的勝任,同時在專案當中由於你也比較清楚業務邏輯,所以當機會來臨的時候,很快會成為團隊的骨幹,逐漸你就會帶幾個初級一點的工程師一起做專案;如果你不喜歡帶團隊,就會成為資深的高階開發或者架構師。那麼在向外方面我個人認為最重要的積累經驗,對常見的應用要比較熟悉且有自己總結的一套開發庫—比如對普通的網站、電子商務系統、ERPOA 客戶端應用等等有比較豐富的經驗。

二)向內:
前面你使用了這些技術開發專案之後,會遇到很多問題,為了解決這些問題,會逐漸研究一些比較底層次的東西。比如對於ASP.NET會逐漸的去深入理解ASP.NET整個處置過程、頁面的生命週期、自定義控制元件的開發等等,由於自己最初是由CC++Java這樣過渡到.NET所以對一些細節總喜歡鑽牛角尖,這也浪費了不少時間,但同時也得到很多意外之喜。

對於C#語言上,也會逐漸去刨根問底,想看看這些語法糖背後到底隱藏著什麼秘密,很多對.NET技術比較痴迷的人都會選擇對C#1.0語言透過IL程式碼來深層次認識,然後對C#2.0C#3.0C#4.0都編譯為C#1.0來學習,這樣他就能認識到語言的內部到底是怎麼執行的正所謂知道的同時也知道其所以然。

對於WF不只要知道各 Activiti使用,也得知道其內部的原理,比方WF內部就是依靠依賴屬性來在工作流中的各 Activiti間傳送屬性值的如果你細心,還原WF依賴屬性原始碼,會發現它和WPFSilverlight中的依賴屬性大同小異,原理基本一樣、只是針對特定技術進行了適當的調整。

對於資料底層操作也一樣,不論你用的拼接SQL儲存過程、IBA TIS.NETNhibernActiveRecordLinqtosqlEntitiframework還是自己開發的ORM元件,得明白它內部的原理,要知道這些開源的程式碼還是很值得研究的經驗是先熟練使用這些功能,然後再剖析它原始碼,然後自己寫一套自己的框架,現在也在精簡自己的ORM框架,因為之前把重點放在實現儘可能多的功能,所以對效能等細節沒有做過多最佳化,後面也會向大家慢慢學習。

對WPF和Silverlight一樣,不只要知道怎麼用這些技術,要知道它原理,比如對依賴屬性,知道它內部原理,就可以對平時出現的諸如我設定的值怎麼沒有起作用、Bind元素怎麼沒有出現等等問題;對路由事件,也會經常遇到事件怎麼沒有執行、自定義控制元件事件怎麼處置不對、路由傳送怎麼沒有起作用等等,這個時候你如果深入理解了路由事件的內部處置,這些問題就迎刃而解了對WPF和Silverlight新多出來的命令特性,大家很多時候也是比較疑惑,也會遇到命令失效等等問題,其實如果你深入的解了原理,就會知道,其實在內部也是事件,只不過微軟在裡面做了很多封裝而已;對Bind就更是如此,也不想在這篇文章談開去,終究在下面的幾篇文章會詳細的對這些技術進行涉及。

三)擴充套件:
透過前面的向內和向外的修煉以後,接下來要做的就是不時實踐,不時總結經驗,這個過程中更重要的要懂得分享,有分享才會使自己和他人共同提高,有分享才幹讓自己解脫狂妄的井底之蛙思想,還記得自己剛做技術的一兩年裡,天天喜歡提及大型架構、大型資料處置、作業系統底層程式碼如何如何,甚至把AOPIOCSSHOO及設計模式、SOA 等詞語時常掛在嘴邊,生怕他人不知道自己不懂。但隨著自己技術實質上的提高以及經驗的積累,自己也就逐漸幼稚起來,對這些技術逐漸深入理解且理解了其內部實現原理,這樣反而自己變得謙虛起來了對之前的那些思想感到無比的羞愧。同時也明白自己在慢慢生長了現在都習慣戲稱自己為打雜工,其實更多時候用打字員會合理一些,所以希望大家能多多指教,這樣我才幹更快地解脫打字員的生活。這裡也對擴充套件做一點小的總結:

記錄學習:這是學習很重要的一步,不一定要寫技術部落格,也可以做一些例子來記錄,也可以在學習之後寫一個總結,終究人的精力十分有限,很多時候,並不能像硬碟一樣儲存起來就不會丟失,更多的時候它更像一塊記憶體。

同道交流:這一層裡我覺得最重要的就是和一些技術較好的人成為朋友,和他經常探討一些技術,這樣可以縮短學習的週期,同時也能快速的解決問題,終究人的精力十分有限,沒有遇到過的問題,說不定其他人遇到過。這方面自己也體會頗深,也很感謝之前幾個公司及現在公司的同事、社群朋友以及一些志同道合之士,感謝你指點,沒有你指點,也不可能從小鳥進化成逐鹿順序界的菜鳥,也為自己能成為一隻老菜鳥感到自豪!

少考證、多務實擴充套件的這一層裡,要謹記不要為了考證而去考證,那樣是沒有任何實際作用的對MVP也一樣,一切順其自然為好,記得大學時候身邊就有人連續四次榮獲MVP稱號,這叫我當時是相當的佩服,佩服之餘我要切記務實,沒有務實的東西都是很虛擬飄渺的還記得自己當初在大學裡面受到考證風氣的影響,神經兮兮的去考過了什麼國家計算機四級和MCP等一大堆證件,後來到公司面試興高采烈拿著20多張證照,才知道那些東西根本就沒有什麼價值,反而讓自己去學習了最不喜歡的技術,同時也給自己掛上了考證族的名號。所以後來總結就是勞民傷財、徒添傷悲!

技術分享自己公司及其他公司進行一些技術培訓或者討論,其實重要的不是什麼榮譽,而是把這個培訓看成是一些技術交流和分享,因為在這個過程中,可能會重新認識你所掌握的技術、可能會遇到一些志同道合的人、可能會在分享過程中糾正以前的錯誤認識、可能會在各方面得到提高從而完善自己的知識體系,但是最重要的要認真對待每一次培訓,知之為知之不知為不知,不要不能教導他人反而誤導了人。記得有一次在公司培訓OO與設計模式,知道這個專題想在一下午的時間把它講清楚是非常困難的這個不像之後培訓的WPFWCF和Silverlight那麼單純,並且每個人的基礎都不一樣,當中有還沒有畢業的實習生、剛畢業不久的畢業生、工作了數年的工程師及技術大牛們所以如何把這些知識很好的拔出到每個人的知識樹上面成了考慮的重點。同時我心裡也比較矛盾,一方面希望參與培訓的同事多一些,另一方面希望人越少越好。前者則是依照常理來考慮的終究培訓者都希望自己培訓,越受歡迎越好,這樣才幹使自己的思想得到更多人的認可,自己也能實現分享知識的目的後者則是擔心怕講不好,少一點人就少一點罪過。可是恰巧這一次是歷次培訓中最多的一次,來參加培訓的同事有一百多人,不過幸好由於會議室坐不下,才分成了兩批,這樣就可以讓我具備了更充分的時間和更好的心態。總之培訓是向內和向外的提煉與昇華,正所謂“自己理解的知識未必能使人家理解”這不僅考驗的技術,還考驗了一個人的綜合能力。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29212814/viewspace-774413/,如需轉載,請註明出處,否則將追究法律責任。

相關文章