程序员修炼之路 - 设计能力提升途径
每当我做一场设计相关的培训分享过后，总会有同学来问我：如何才能快速提升自己的设计能力？觉得这个问题非常有代表性，代表了一大波程序猿在艰辛修炼路上的心声。现将我对这个问题的思考、心得体会分享出来，供大家参考，也欢迎提出不同的意见与看法，共同探讨。
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等），而设计模式本身都是遵守这些原则的，有些模式就是为了遵循某原则而设计出来的。 抽象不是万能的，在适当的地方使用，需要仔细推敲。当有更好的方案不用抽象就能解决问题时，尽量避免抽象，笔者见过太多的抽象过火过渡设计的案例了，增加了太多维护成本，还不如按照最自然的方式去写。
空杯心态，向身边的同学学习，站在巨人的肩上，站在别人的肩上
有人提意见，先收下它（无论接受与否）。 很多程序猿，也都有一个毛病，就是觉得自己技术牛的不行，不愿意接受别人的意见，尤其是否定意见（文人相轻）。 而无论是理论的学习，还是编码实践，向身边的同学学习将是对自己影响最大的（三人行，必有我师），比刻意参加相关培训要有用的多。 我自己就经常在跟团队同学讨论中获益，当百思不得姐的时候，把问题抛出来讨论一下，通常都能得到一个最佳方案。 另外，跟团队其他人讨论还有一个好处，就是当你的设计有妥协，有些不专业的时候，别人看到代码也不会产生质疑，因为他参与了讨论的，你不用花那么多时间去做解释。 设计期间就一定要找他人讨论，我一直比较反对一个人把设计做完了，把文档写完了，然后才找大家开个评审会那种模式，虽然也有效果，但是效果真的达不到极致，大家没有参与到设计中来，通过一场会议的时间理解不一定有那么深，最关键的是，如果设计有些问题的时候，但也不是致命问题，难道还让打回重新设计么？ 等前期讨论足够后，大家都知道你的思路与方案，而且最后也有设计文档，当其他人来阅读你的代码的时候，根本无需你再指引，今后的工作交接都不是很需要了，何乐而不为呢？
最后
我想在此呼吁一下，当你去修改维护别人的代码时，最好找模块负责人做深入的讨论沟通，让他明白你的需求以及你的方案，请他帮忙评估方案是否可行，是否会踩坑、埋坑等。这样我们的项目才不会出现坏味道蔓延，而如果你恰好是某模块负责人，请行使你的权力，拒绝有问题的不符合要求的代码提交入库。
