每當我做一場設計相關的培訓分享過後，總會有同學來問我：如何才能快速提升自己的設計能力？覺得這個問題非常有代表性，代表了一大波程式猿在艱辛修煉路上的心聲。現將我對這個問題的思考、心得體會分享出來，供大家參考，也歡迎提出不同的意見與看法，共同探討。
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等），而設計模式本身都是遵守這些原則的，有些模式就是為了遵循某原則而設計出來的。
抽象不是萬能的，在適當的地方使用，需要仔細推敲。當有更好的方案不用抽象就能解決問題時，儘量避免抽象，筆者見過太多的抽象過火過渡設計的案例了，增加了太多維護成本，還不如按照最自然的方式去寫。
空杯心態，向身邊的同學學習，站在巨人的肩上，站在別人的肩上
有人提意見，先收下它（無論接受與否）。
很多程式猿，也都有一個毛病，就是覺得自己技術牛的不行，不願意接受別人的意見，尤其是否定意見（文人相輕）。
而無論是理論的學習，還是編碼實踐，向身邊的同學學習將是對自己影響最大的（三人行，必有我師），比刻意參加相關培訓要有用的多。
我自己就經常在跟團隊同學討論中獲益，當百思不得姐的時候，把問題丟擲來討論一下，通常都能得到一個最佳方案。
另外，跟團隊其他人討論還有一個好處，就是當你的設計有妥協，有些不專業的時候，別人看到程式碼也不會產生質疑，因為他參與了討論的，你不用花那麼多時間去做解釋。
設計期間就一定要找他人討論，我一直比較反對一個人把設計做完了，把文件寫完了，然後才找大家開個評審會那種模式，雖然也有效果，但是效果真的達不到極致，大家沒有參與到設計中來，通過一場會議的時間理解不一定有那麼深，最關鍵的是，如果設計有些問題的時候，但也不是致命問題，難道還讓打回重新設計麼？
等前期討論足夠後，大家都知道你的思路與方案，而且最後也有設計文件，當其他人來閱讀你的程式碼的時候，根本無需你再指引，今後的工作交接都不是很需要了，何樂而不為呢？
最後，我想在此呼籲一下，當你去修改維護別人的程式碼時，最好找模組負責人做深入的討論溝通，讓他明白你的需求以及你的方案，請他幫忙評估方案是否可行，是否會踩坑、埋坑等。這樣我們的專案才不會出現壞味道蔓延，而如果你恰好是某模組負責人，請行使你的權力，拒絕有問題的不符合要求的程式碼提交入庫。
大家共勉。