程序員修煉之路 - 設計能力提高途徑

  每當我作一場設計相關的培訓分享事後，總會有同窗來問我：如何才能快速提高本身的設計能力？以爲這個問題很是有表明性，表明了一大波程序猿在艱辛修煉路上的心聲。現將我對這個問題的思考、心得體會分享出來，供你們參考，也歡迎提出不一樣的意見與見解，共同探討。

1. 編碼歷練

  代碼行經驗是個很是重要的東西，當你尚未1萬行代碼經驗的時候，就來問如何提高設計能力的問題，我只能告訴你不要太糾結，理論看看就好，老老實實寫代碼積累編碼經驗吧。
  聽說，一個程序員平均天天碼代碼的速度是200~300行，你可能會說，我一天怎麼也要寫上1000行吧，別忘了，當你碼完代碼後，你還須要測試、調試、優化、BUG Fix，這些時間你無法一直碼代碼的。
  編碼規範就很少說了，若是你的代碼仍是雜亂無章的狀態，就先彆着急談什麼設計與架構了，我會以爲有點扯淡，固然有這樣的設計意識，能看到本身的不足這是好事。必須去閱讀一些編碼規範的文檔，深刻語言特色的書籍等，而後歷練。
  另外，做爲代碼潔癖患者，推薦你們不要把代碼寫完後，批量格式化處理，或者手工再去整理代碼。而是每敲一個字符上去，它都是符合規範的。習慣真的很重要，有時在招聘面試的時候，我真想添加一個環節，現場編寫程序完成一個簡單但容易出錯的任務。

2. 理論學習

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

3. 實踐

  如今，你已經具有了必定的編碼經驗，並且已經學習了足夠的理論知識，接下來就是真正練手的時候了。好好反覆思考你學習的這些理論知識，要如何運用到項目中去，身體力行的去實踐，必定要把那些理論搞清楚，用於指導你的實踐，收起從前的自信，首先否認本身之前的作法，保證每次作出的東西相比之前是有進步有改進的。

4. 重溫理論

  你已經能看到本身的進步了，發現比之前作的更好了，可是總感受還不夠，好像有瓶頸似的，恭喜你，我已經能預見到你將來的潛力了。
  從新拿起書本，重溫一遍以前看的似懂非懂的東西，你會發現以前沒弄懂的東西，如今豁然開朗了，再也不是那種難於理解的晦澀感了。就算是之前你以爲已經弄懂的，也再看一遍，一般會有新的收穫。

5. 再實踐

  這個階段，你已經掌握了較多的東西了，不但實踐經驗豐富，各類理論也能手到擒來了，可是你發現你的設計依然不夠專業。並且你回過頭去看你之前寫的代碼，你會驚訝：天啊，這是誰寫的代碼，怎麼能這樣幹！而後。。。我就很少說了，你已經進入了自省的階段，掌握了適合本身的學習方法，再要學習什麼新東西，都再也不是個事。

6. 總結

  先別太得意（不信？那你去作一堂講座看看），你須要總結了，總結本身的學習方法，總結項目經驗，總結設計理論知識。
  若是你能有本身獨到的理解，而不是停留在只會使用成熟的設計模式什麼的，能根據本身的經驗教訓總結一些設計原則出來，那天然是極好的。

7. 分享

  分享是最好的學習催化劑，當你要準備一場培訓分享的時候，你會發現你先前覺得已經理解的東西其實並無真正理解透徹，由於你沒法把它講清楚，實際上就是研究不夠，這時會迫使你去從新深刻學習，融匯貫通，而後你纔敢走上講臺。不然當別人提問的時候，你根本回答不上來。

  以上，即是我認爲的程序員修煉道路的必經階段。
  而後，我再說說其餘對提高很是重要的幾點：

養成先設計，再編碼的習慣

  幾乎全部的程序員，一開始都不太願意寫文檔，也不太願意去精心設計，拿到需求老是忍不住那雙躁動的手，總以爲敲在鍵盤上，一行一行的代碼飆出來，纔有成就感，纔是正確的工做姿式。
  沒討論清楚不要編碼，否則你必定會返工。

設計重於編碼，接口重於實現

  制定接口的過程，自己就是設計過程，接口必定要反覆推敲，儘可能作減法而不是加法，在能知足需求的狀況下越簡單越好。
  另外，不要一我的左思右想，先簡單作一個雛形出來，而後拿去找使用方溝通，直到對方滿意爲止。
  不要徹底根據業務需求去設計接口，參考MVVM，ViewModel就是根據View的須要而對Model進行的再封裝，不能將這些接口直接設計到Model中。

不盲從設計模式

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

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

  有人提意見，先收下它（不管接受與否）。
  不少程序猿，也都有一個毛病，就是以爲本身技術牛的不行，不肯意接受別人的意見，尤爲是否認意見（文人相輕）。
  而不管是理論的學習，仍是編碼實踐，向身邊的同窗學習將是對本身影響最大的（三人行，必有我師），比刻意參加相關培訓要有用的多。
  我本身就常常在跟團隊同窗討論中獲益，當百思不得姐的時候，把問題拋出來討論一下，一般都能獲得一個最佳方案。
  另外，跟團隊其餘人討論還有一個好處，就是當你的設計有妥協，有些不專業的時候，別人看到代碼也不會產生質疑，由於他參與了討論的，你不用花那麼多時間去作解釋。
  設計期間就必定要找他人討論，我一直比較反對一我的把設計作完了，把文檔寫完了，而後才找你們開個評審會那種模式，雖然也有效果，可是效果然的達不到極致，你們沒有參與到設計中來，經過一場會議的時間理解不必定有那麼深，最關鍵的是，若是設計有些問題的時候，但也不是致命問題，難道還讓打回從新設計麼？
  等前期討論足夠後，你們都知道你的思路與方案，並且最後也有設計文檔，當其餘人來閱讀你的代碼的時候，根本無需你再指引，從此的工做交接都不是很須要了，何樂而不爲呢？

  最後，我想在此呼籲一下，當你去修改維護別人的代碼時，最好找模塊負責人作深刻的討論溝通，讓他明白你的需求以及你的方案，請他幫忙評估方案是否可行，是否會踩坑、埋坑等。這樣咱們的項目纔不會出現壞味道蔓延，而若是你剛好是某模塊負責人，請行使你的權力，拒絕有問題的不符合要求的代碼提交入庫。
  你們共勉。

原創文章，轉載請註明出處