程序员修炼之路：你该知道的 7 个必经阶段

当我做完设计相关的培训分享过后，有同学来问我：如何才能快速提升自己的设计能力？我觉得这个问题非常有代表性，代表了一大波程序猿在艰辛的修炼路上的心声。现将我对这个问题的思考、心得体会分享出来，供大家参考，也欢迎提出不同的意见与看法，共同探讨。

编码历练

代码行经验是个非常重要的东西，当你还没有 1 万行代码经验的时候，你来问如何提升设计能力的问题，我只能告诉你不要太纠结，理论看看就好，老老实实写代码吧。

据说，一个程序员平均每天码代码的速度是 200~300 行，你可能会说，我一天怎么也要写上 1000 行吧，别忘了，当你码完代码后，你还需要测试、调试、优化、BUG Fix，这些时间你没法一直码代码的。

编码规范就不多说了，如果你的代码还是杂乱无章的状态，就先别谈什么设计与架构了，我会觉得有点扯淡。

另外，作为代码洁癖患者，推荐大家不要把代码写完后，批量格式化处理，或者手工再去整理代码，而是每敲一个字符上去，它都是符合规范的。习惯真的很重要，有时在招聘面试的时候，我真想添加一个环节，现场编写程序完成一个简单但容易出错的任务。

理论学习

简单说就是看书，看博客，你所能得到的资源，质量高的就行。例如：《重构 - 改善既有代码的设计》、《敏捷软件开发：原则、模式与实践》、《UML 和模式应用》、"面向对象设计原则"（五大原则）、《设计模式》等。

《设计模式》这本书是很古老的一本书了，只有短短 200 页，但是，这是最难看懂的一本书，一个月都可能看不完（看小说的话，200 页 3 个小时也许就看完了吧），而且就算看完了，也不会全看懂，很可能看懂不超过 30%。看不懂没关系，看了就行，不用太纠结，这不能说明什么问题。

另外，我想说一下，多线程技术是程序员必须掌握的，而且需要理解透彻，现在的高级技术例如 GCD，会掩盖你对多线程理解不足的问题，因为使用实在太简单了。别说你没写过多线程依然完成了复杂的项目，更别说你随手写出的多线程代码好像也没出什么问题啊，把你的代码给我，我写个 Demo 让它出错乃至崩溃，如果我做不到，恭喜你。

实践

现在，你已经具备了一定的编码经验，而且已经学习了足够的理论知识，接下来就是真正练手的时候了。好好反复思考你学习的这些理论知识，要如何运用到项目中去，身体力行的去实践，一定要把那些理论搞清楚，用于指导你的实践，收起从前的自信，首先否定自己以前的做法，保证每次做出的东西相比以前是有进步有改进的。

重温理论

你已经能看到自己的进步了，发现比以前做的更好了，但是总感觉还不够，好像有瓶颈似的，恭喜你，我已经能看到你未来的潜力了。

重新拿起书本，重温一遍之前看的似懂非懂的东西，你会发现之前没弄懂的东西，现在豁然开朗了，不再是那种难于理解的晦涩感了。就算是以前你觉得已经弄懂的，也再看一遍，通常会有新的收获。

再实践

这个阶段，你已经掌握了较多的东西了，不但实践经验丰富，各种理论也能手到擒来了，但是你发现你的设计依然不够专业。而且你回过头去看你以前写的代码，你会惊讶：天啊，这是谁写的代码，怎么能这样干！然后。。。我就不多说了，你已经进入了自省的阶段，掌握了适合自己的学习方法，再要学习什么新东西，都不再是个事。

总结

先别太得意（不信？那你去做一堂讲座看看），你需要总结了，总结自己的学习方法，总结项目经验，总结设计理论知识。

如果你能有自己独到的理解，而不是停留在只会使用成熟的设计模式什么的，能根据自己的经验教训总结一些设计原则出来，那自然是极好的。

分享

分享是最好的学习催化剂，当你要准备一场培训分享的时候，你会发现你先前以为已经理解的东西其实并没有真正理解透彻，因为你无法把它讲清楚，实际上就是研究不够，这时会迫使你去重新深入学习，融汇贯通，然后你才敢走上讲台。否则当别人提问的时候，你根本回答不上来。

以上，便是我认为的程序员修炼道路的必经阶段。

然后，我再说说其他对提升非常重要的几点：

1. 养成先设计，再编码的习惯

几乎所有的程序员，一开始都不太愿意写文档，也不太愿意去精心设计，拿到需求总是忍不住那双躁动的手，总觉得敲在键盘上，一行一行的代码飙出来，才有成就感，才是正确的工作姿势。

没讨论清楚不要编码，不然你一定会返工。

2. 设计重于编码，接口重于实现

制定接口的过程，本身就是设计过程，接口一定要反复推敲，尽量做减法而不是加法，在能满足需求的情况下越简单越好。

另外，不要一个人冥思苦想，先简单做一个雏形出来，然后拿去找使用方沟通，直到对方满意为止。

不要完全根据使用需求去设计接口，参考 MVVM，ViewModel 就是根据 View 的需要而对 Model 进行的再封装，不能将这些接口直接设计到 Model 中。

我目前是在职前端开发，如果你现在也想学习前端开发技术，在入门学习前端的过程当中有遇见任何关于学习方法，学习路线，学习效率等方面的问题，你都可以申请加入我的前端学习交流3000人裙：前面：851 中间：231 最后：348。里面聚集了一些正在自学前端的初学者裙文件里面也有我做前端技术这段时间整理的一些前端学习手册，前端面试题，前端开发工具，PDF文档书籍教程，需要的话都可以自行来获取下载。

3. 不盲从设计模式

设计模式只是一种解决问题的套路方法，你也可以有自己的方法，当然设计模式如果用好了，会让你的设计显得专业与优雅，毕竟前辈们的心血结晶。但是滥用的话，也会导致更严重的问题，甚至可能成为灾难。个人觉得面向对象设计原则更加重要，有些原则是必须遵守的（如单向依赖、SRP 等），而设计模式本身都是遵守这些原则的，有些模式就是为了遵循某原则而设计出来的。

抽象不是万能的，在适当的地方使用，需要仔细推敲。当有更好的方案不用抽象就能解决问题时，尽量避免抽象，笔者见过太多的抽象过火过度设计的案例了，增加了太多维护成本，还不如按照最自然的方式去写。

4. 空杯心态，向身边的同学学习，站在巨人的肩上，站在别人的肩上

有人提意见，先收下它（无论接受与否）。

很多程序猿，也都有一个毛病，就是觉得自己技术牛的不行，不愿意接受别人的意见，尤其是否定意见（文人相轻）。

而无论是理论的学习，还是编码实践，向身边的同学学习将是对自己影响最大的（三人行，必有我师），比刻意参加相关培训要有用的多。

我自己就经常在跟团队同学的讨论中获益，当百思不得解的时候，把问题抛出来讨论一下，通常都能得到一个最佳方案。

另外，跟团队其他人讨论还有一个好处，就是当你的设计有妥协，有些不专业的时候，别人看到代码也不会产生质疑，因为他参与了讨论的，你不用花那么多时间去做解释。

设计期间就一定要找他人讨论，我一直比较反对一个人把设计做完了，把文档写完了，然后才找大家开个评审会那种模式，虽然也有效果，但是效果真的达不到极致，大家没有参与到设计中来，通过一场会议的时间理解不一定有那么深，最关键的是，如果设计有些问题的时候，但也不是致命问题，难道还让打回重新设计么？

等前期讨论足够后，大家都知道你的思路与方案，而且最后也有设计文档，当其他人来阅读你的代码的时候，根本无需你再指引，今后的工作交接都不是很需要了，何乐而不为呢？

最后，我想在此呼吁一下，当你去修改维护别人的代码时，最好找模块负责人做深入的讨论沟通，让他明白你的需求以及你的方案，请他帮忙评估方案是否可行，是否会踩坑、埋坑等。这样我们的项目才不会出现坏味道蔓延，而如果你恰好是某模块负责人，请行使你的权力，拒绝有问题的不符合要求的代码提交入库。

大家共勉。