共计 2951 个字符，预计需要花费 8 分钟才能阅读完成。
作者 | 杨长元
起源 | 阿里巴巴云原生公众号
导读：数据结构、算法、设计模式被认为是程序员必修的三大内功，你对设计模式有什么了解？你是什么时候意识到本人须要好好学习设计模式的？本文将分享作者多年编程路线上的一些思考和心得，以及对如何晋升设计能力的几点倡议。
当我做完设计相干的培训分享过后，有同学来问我：如何能力疾速晋升本人的设计能力？我感觉这个问题十分有代表性，代表了一大波程序猿在艰苦的修炼路上的心声。现将我对这个问题的思考、心得体会分享进去，供大家参考，也欢送提出不同的意见与认识，独特探讨。
编码历练
代码行教训是个十分重要的货色，当你还没有 1 万行代码教训的时候，你来问如何晋升设计能力的问题，我只能通知你不要太纠结，实践看看就好，老老实实写代码吧。
据说，一个程序员均匀每天码代码的速度是 200~300 行，你可能会说，我一天怎么也要写上 1000 行吧，别忘了，当你码完代码后，你还须要测试、调试、优化、BUG Fix，这些工夫你没法始终码代码的。
编码标准就不多说了，如果你的代码还是横七竖八的状态，就先别谈什么设计与架构了，我会感觉有点扯淡。
另外，作为代码洁癖患者，举荐大家不要把代码写完后，批量格式化解决，或者手工再去整顿代码，而是每敲一个字符下来，它都是符合规范的。习惯真的很重要，有时在招聘面试的时候，我真想增加一个环节，现场编写程序实现一个简略但容易出错的工作。
实践学习
简略说就是看书，看博客，你所能失去的资源，品质高的就行。例如：《重构 – 改善既有代码的设计》、《麻利软件开发：准则、模式与实际》、《UML 和模式利用》、” 面向对象设计准则 ”（五大准则）、《设计模式》等。
《设计模式》这本书是很古老的一本书了，只有短短 200 页，然而，这是最难看懂的一本书，一个月都可能看不完（看小说的话，200 页 3 个小时兴许就看完了吧），而且就算看完了，也不会全看懂，很可能看懂不超过 30%。看不懂没关系，看了就行，不必太纠结，这不能阐明什么问题。
另外，我想说一下，多线程技术是程序员必须把握的，而且须要了解透彻，当初的高级技术例如 GCD，会覆盖你对多线程了解有余的问题，因为应用切实太简略了。别说你没写过多线程仍然实现了简单的我的项目，更别说你顺手写出的多线程代码如同也没出什么问题啊，把你的代码给我，我写个 Demo 让它出错乃至解体，如果我做不到，祝贺你。
实际
当初，你曾经具备了肯定的编码教训，而且曾经学习了足够的理论知识，接下来就是真正练手的时候了。好好重复思考你学习的这些理论知识，要如何使用到我的项目中去，事必躬亲的去实际，肯定要把那些实践搞清楚，用于领导你的实际，收起从前的自信，首先否定本人以前的做法，保障每次做出的货色相比以前是有提高有改良的。
重温实践
你曾经能看到本人的提高了，发现比以前做的更好了，然而总感觉还不够，如同有瓶颈似的，祝贺你，我曾经能看到你将来的后劲了。
从新拿起书本，重温一遍之前看的似懂非懂的货色，你会发现之前没弄懂的货色，当初恍然大悟了，不再是那种难于了解的艰涩感了。就算是以前你感觉曾经弄懂的，也再看一遍，通常会有新的播种。
再实际
这个阶段，你曾经把握了较多的货色了，岂但实践经验丰盛，各种实践也能手到擒来了，然而你发现你的设计仍然不够业余。而且你回过头去看你以前写的代码，你会诧异：天啊，这是谁写的代码，怎么能这样干！而后。。。我就不多说了，你曾经进入了自省的阶段，把握了适宜本人的学习办法，再要学习什么新货色，都不再是个事。
总结
先别太得意（不信？那你去做一堂讲座看看），你须要总结了，总结本人的学习办法，总结我的项目教训，总结设计理论知识。
如果你能有本人独到的了解，而不是停留在只会应用成熟的设计模式什么的，能依据本人的经验教训总结一些设计准则进去，那天然是极好的。
分享
分享是最好的学习催化剂，当你要筹备一场培训分享的时候，你会发现你先前认为曾经了解的货色其实并没有真正了解透彻，因为你无奈把它讲清楚，实际上就是钻研不够，这时会迫使你去从新深刻学习，融汇贯通，而后你才敢走上讲台。否则当他人发问的时候，你基本答复不上来。
以上，便是我认为的程序员修炼路线的必经阶段。
而后，我再说说其余对晋升十分重要的几点：
1. 养成先设计，再编码的习惯
简直所有的程序员，一开始都不太违心写文档，也不太违心去精心设计，拿到需要总是忍不住那双躁动的手，总感觉敲在键盘上，一行一行的代码飙进去，才有成就感，才是正确的工作姿势。
没探讨分明不要编码，不然你肯定会返工。
2. 设计重于编码，接口重于实现
制订接口的过程，自身就是设计过程，接口肯定要反复推敲，尽量做减法而不是加法，在能满足需要的状况下越简略越好。
另外，不要一个人左思右想，先简略做一个雏形进去，而后拿去找应用方沟通，直到对方称心为止。
不要齐全依据应用需要去设计接口，参考 MVVM，ViewModel 就是依据 View 的须要而对 Model 进行的再封装，不能将这些接口间接设计到 Model 中。
3. 不盲从设计模式
设计模式只是一种解决问题的套路办法，你也能够有本人的办法，当然设计模式如果用好了，会让你的设计显得业余与优雅，毕竟前辈们的心血结晶。然而滥用的话，也会导致更重大的问题，甚至可能成为劫难。集体感觉面向对象设计准则更加重要，有些准则是必须恪守的（如单向依赖、SRP 等），而设计模式自身都是恪守这些准则的，有些模式就是为了遵循某准则而设计进去的。
形象不是万能的，在适当的中央应用，须要认真斟酌。当有更好的计划不必形象就能解决问题时，尽量避免形象，笔者见过太多的形象过分适度设计的案例了，减少了太多保护老本，还不如依照最天然的形式去写。
4. 空杯心态，向身边的同学学习，站在伟人的肩上，站在他人的肩上
有人提意见，先收下它（无论承受与否）。
很多程序猿，也都有一个故障，就是感觉本人技术牛的不行，不违心承受他人的意见，尤其是否定意见（文人相轻）。
而无论是实践的学习，还是编码实际，向身边的同学学习将是对本人影响最大的（三人行，必有我师），比刻意加入相干培训要有用的多。
我本人就常常在跟团队同学的探讨中获益，当百思不得解的时候，把问题抛出来讨论一下，通常都能失去一个最佳计划。
另外，跟团队其他人探讨还有一个益处，就是当你的设计有斗争，有些不业余的时候，他人看到代码也不会产生质疑，因为他参加了探讨的，你不必花那么多工夫去做解释。
设计期间就肯定要找别人探讨，我始终比拟拥护一个人把设计做完了，把文档写完了，而后才找大家开个评审会那种模式，尽管也有成果，然而成果真的达不到极致，大家没有参加到设计中来，通过一场会议的工夫了解不肯定有那么深，最要害的是，如果设计有些问题的时候，但也不是致命问题，难道还让打回从新设计么？
等后期探讨足够后，大家都晓得你的思路与计划，而且最初也有设计文档，当其他人来浏览你的代码的时候，基本无需你再指引，今后的工作交接都不是很须要了，何乐而不为呢？
最初，我想在此呐喊一下，当你去批改保护他人的代码时，最好找模块负责人做深刻的探讨沟通，让他明确你的需要以及你的计划，请他帮忙评估计划是否可行，是否会踩坑、埋坑等。这样咱们的我的项目才不会呈现坏滋味蔓延，而如果你恰好是某模块负责人，请行使你的势力，回绝有问题的不符合要求的代码提交入库。
大家共勉。
