你好，我是张绍文，今天我要和你分享我的朋友长元的一篇文章，主题是设计能力的提升途径。专栏已经进入架构演进模块，由于每个人对架构的理解都不同，在工作中也会遇到各种各样的架构设计问题，很多时候我们的架构设计能力都是靠不断的理论学习和在设计实践中不断摸索提高的，因此在成为设计高手的道路上，我们肯定或多或少有些自己的经验和体会，当然也少不了踩坑。今天长元分享的设计能力提升路径，希望可以把他的经验分享给你，你可以参考他的提升路径来强化自己的设计能力，在高手的修炼之路上少走弯路。

每当我做完一次内部设计培训以后，经常有同学来问我：如何才能快速提升自己的设计能力？我觉得这个问题非常有代表性，代表了一大波程序员在艰辛修炼路上的心声。今天我就来分享一下我所理解的程序员设计能力的提升路径，也欢迎你留言写写你的思考与体会。

1. 编码历练

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

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

编码规范就不多说了，如果你的代码还是杂乱无章的状态，就先别谈什么设计与架构了，先把基础的工作做好再谈其他的吧。

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

2. 理论学习

简单说就是看书、看博客，学习你能得到的所有资源，但前提是内容质量要高。例如图书，我推荐：《重构 改善既有代码的设计》《敏捷软件开发：原则、模式与实践》《UML和模式应用》《设计模式》等，其他你还需要学习面向对象设计原则（五大原则）。

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

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

3. 实践

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

4. 重温理论

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

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

5. 再实践

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

6. 总结

先别太得意（不信？那你去给团队分享一次讲座试试），你还需要总结，总结自己的学习方法、总结项目经验、总结设计理论的知识。

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

7. 分享

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

以上，便是我认为的程序员修炼道路的必经阶段。接下来，我再分享几点其他对设计能力提升非常重要的方法。

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

我的建议是，没讨论清楚不要编码，不然你一定会返工。

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

另外，不要一个人冥思苦想。可以先简单做一个雏形出来，然后去找使用方沟通，直到对方满意为止。不要完全根据使用需求去设计接口，参考MVVM，ViewModel就是根据View的需要而对Model进行的再封装，不能将这些接口直接设计到Model中。

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

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

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

很多程序员都有个“毛病”，就是觉得自己技术牛的不行，不愿意接受别人的意见，尤其是否定意见（文人相轻）。 但是无论是理论的学习，还是编码实践，向身边的同学学习是对自己影响最大的（三人行，必有我师）。

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

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

设计期间一定要找其他人一起讨论，我一直比较反对一个人把设计做完、把文档写完，然后才找大家开个评审会那种模式，虽然也有效果，但是效果达不到极致。因为大家没有参与到设计中，通过一次会议的时间理解不一定有那么深，最关键的是，如果在会上发现设计有些问题，但不是致命问题的时候，通常并不会打回重新设计。

相反，如果前期讨论足够，大家都知道你的思路与方案，而且最后也有设计文档，当其他人阅读你的代码的时候，根本无需你再指引，这样今后在工作交接时都会很顺利，何乐而不为呢？

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

欢迎你点击“请朋友读”，把今天的内容分享给好友，邀请他一起学习。

评论