1. 程序員修煉之路:你該知道的 7 個必經階段

        時間 2020-04-01 08:57

        ?

        圍觀熱度

        阿里妹導讀:數據結構、算法、設計模式被認為是程序員必修的三大內功,你對設計模式有什么理解?你是什么時候意識到自己需要好好學習設計模式的?本文將分享作者多年編程道路上的一些思考和心得,以及對如何提升設計能力的幾點建議。
         
        當我做完設計相關的培訓分享過后,有同學來問我:如何才能快速提升自己的設計能力?我覺得這個問題非常有代表性,代表了一大波程序猿在艱辛的修煉路上的心聲?,F將我對這個問題的思考、心得體會分享出來,供大家參考,也歡迎提出不同的意見與看法,共同探討。
         

        一  編碼歷練

         

        代碼行經驗是個非常重要的東西,當你還沒有 1 萬行代碼經驗的時候,你來問如何提升設計能力的問題,我只能告訴你不要太糾結,理論看看就好,老老實實寫代碼吧。
         
        據說,一個程序員平均每天碼代碼的速度是 200~300 行,你可能會說,我一天怎么也要寫上 1000 行吧,別忘了,當你碼完代碼后,你還需要測試、調試、優化、BUG Fix,這些時間你沒法一直碼代碼的。
         
        編碼規范就不多說了,如果你的代碼還是雜亂無章的狀態,就先別談什么設計與架構了,我會覺得有點扯淡。
         
        另外,作為代碼潔癖患者,推薦大家不要把代碼寫完后,批量格式化處理,或者手工再去整理代碼,而是每敲一個字符上去,它都是符合規范的。習慣真的很重要,有時在招聘面試的時候,我真想添加一個環節,現場編寫程序完成一個簡單但容易出錯的任務。
         

        二  理論學習

         

        簡單說就是看書,看博客,你所能得到的資源,質量高的就行。例如:《重構 - 改善既有代碼的設計》、《敏捷軟件開發:原則、模式與實踐》、《UML 和模式應用》、"面向對象設計原則"(五大原則)、《設計模式》等。
         
        《設計模式》這本書是很古老的一本書了,只有短短 200 頁,但是,這是最難看懂的一本書,一個月都可能看不完(看小說的話,200 頁 3 個小時也許就看完了吧),而且就算看完了,也不會全看懂,很可能看懂不超過 30%??床欢疀]關系,看了就行,不用太糾結,這不能說明什么問題。
         
        另外,我想說一下,多線程技術是程序員必須掌握的,而且需要理解透徹,現在的高級技術例如 GCD,會掩蓋你對多線程理解不足的問題,因為使用實在太簡單了。別說你沒寫過多線程依然完成了復雜的項目,更別說你隨手寫出的多線程代碼好像也沒出什么問題啊,把你的代碼給我,我寫個 Demo 讓它出錯乃至崩潰,如果我做不到,恭喜你。

         

        三  實踐

         

        現在,你已經具備了一定的編碼經驗,而且已經學習了足夠的理論知識,接下來就是真正練手的時候了。好好反復思考你學習的這些理論知識,要如何運用到項目中去,身體力行的去實踐,一定要把那些理論搞清楚,用于指導你的實踐,收起從前的自信,首先否定自己以前的做法,保證每次做出的東西相比以前是有進步有改進的。
         

        四  重溫理論

         

        你已經能看到自己的進步了,發現比以前做的更好了,但是總感覺還不夠,好像有瓶頸似的,恭喜你,我已經能看到你未來的潛力了。
         
        重新拿起書本,重溫一遍之前看的似懂非懂的東西,你會發現之前沒弄懂的東西,現在豁然開朗了,不再是那種難于理解的晦澀感了。就算是以前你覺得已經弄懂的,也再看一遍,通常會有新的收獲。
         

        五  再實踐

         

        這個階段,你已經掌握了較多的東西了,不但實踐經驗豐富,各種理論也能手到擒來了,但是你發現你的設計依然不夠專業。而且你回過頭去看你以前寫的代碼,你會驚訝:天啊,這是誰寫的代碼,怎么能這樣干!然后。。。我就不多說了,你已經進入了自省的階段,掌握了適合自己的學習方法,再要學習什么新東西,都不再是個事。
         

        六  總結

         

        先別太得意(不信?那你去做一堂講座看看),你需要總結了,總結自己的學習方法,總結項目經驗,總結設計理論知識。

         

        如果你能有自己獨到的理解,而不是停留在只會使用成熟的設計模式什么的,能根據自己的經驗教訓總結一些設計原則出來,那自然是極好的。

         

        七  分享

          
        分享是最好的學習催化劑,當你要準備一場培訓分享的時候,你會發現你先前以為已經理解的東西其實并沒有真正理解透徹,因為你無法把它講清楚,實際上就是研究不夠,這時會迫使你去重新深入學習,融匯貫通,然后你才敢走上講臺。否則當別人提問的時候,你根本回答不上來。
          
        以上,便是我認為的程序員修煉道路的必經階段。
         
        然后,我再說說其他對提升非常重要的幾點:
         
        養成先設計,再編碼的習慣
         
        幾乎所有的程序員,一開始都不太愿意寫文檔,也不太愿意去精心設計,拿到需求總是忍不住那雙躁動的手,總覺得敲在鍵盤上,一行一行的代碼飆出來,才有成就感,才是正確的工作姿勢。
         
        沒討論清楚不要編碼,不然你一定會返工。

         

        計重于編碼,接口重于實現

         

        制定接口的過程,本身就是設計過程,接口一定要反復推敲,盡量做減法而不是加法,在能滿足需求的情況下越簡單越好。
         
        另外,不要一個人冥思苦想,先簡單做一個雛形出來,然后拿去找使用方溝通,直到對方滿意為止。
         
        不要完全根據使用需求去設計接口,參考 MVVM,ViewModel 就是根據 View 的需要而對 Model 進行的再封裝,不能將這些接口直接設計到 Model 中。

         

        不盲從設計模式
         
        設計模式只是一種解決問題的套路方法,你也可以有自己的方法,當然設計模式如果用好了,會讓你的設計顯得專業與優雅,畢竟前輩們的心血結晶。但是濫用的話,也會導致更嚴重的問題,甚至可能成為災難。個人覺得面向對象設計原則更加重要,有些原則是必須遵守的(如單向依賴、SRP 等),而設計模式本身都是遵守這些原則的,有些模式就是為了遵循某原則而設計出來的。
         
        抽象不是萬能的,在適當的地方使用,需要仔細推敲。當有更好的方案不用抽象就能解決問題時,盡量避免抽象,筆者見過太多的抽象過火過度設計的案例了,增加了太多維護成本,還不如按照最自然的方式去寫。

         

        空杯心態,向身邊的同學學習,站在巨人的肩上,站在別人的肩上

         

        有人提意見,先收下它(無論接受與否)。
         
        很多程序猿,也都有一個毛病,就是覺得自己技術牛的不行,不愿意接受別人的意見,尤其是否定意見(文人相輕)。

         

        而無論是理論的學習,還是編碼實踐,向身邊的同學學習將是對自己影響最大的(三人行,必有我師),比刻意參加相關培訓要有用的多。
         
        我自己就經常在跟團隊同學的討論中獲益,當百思不得解的時候,把問題拋出來討論一下,通常都能得到一個最佳方案。

         

        另外,跟團隊其他人討論還有一個好處,就是當你的設計有妥協,有些不專業的時候,別人看到代碼也不會產生質疑,因為他參與了討論的,你不用花那么多時間去做解釋。

         

        設計期間就一定要找他人討論,我一直比較反對一個人把設計做完了,把文檔寫完了,然后才找大家開個評審會那種模式,雖然也有效果,但是效果真的達不到極致,大家沒有參與到設計中來,通過一場會議的時間理解不一定有那么深,最關鍵的是,如果設計有些問題的時候,但也不是致命問題,難道還讓打回重新設計么?
         
        等前期討論足夠后,大家都知道你的思路與方案,而且最后也有設計文檔,當其他人來閱讀你的代碼的時候,根本無需你再指引,今后的工作交接都不是很需要了,何樂而不為呢?
         
        最后,我想在此呼吁一下,當你去修改維護別人的代碼時,最好找模塊負責人做深入的討論溝通,讓他明白你的需求以及你的方案,請他幫忙評估方案是否可行,是否會踩坑、埋坑等。這樣我們的項目才不會出現壞味道蔓延,而如果你恰好是某模塊負責人,請行使你的權力,拒絕有問題的不符合要求的代碼提交入庫。
         
        大家共勉。

         

        欧美日韩国产在线人成,久久久久久精品免费免费,翁熄粗大战梦莹