程序员修炼之路 - 设计能力提高途径

  每当我作一场设计相关的培训分享事后，总会有同窗来问我：如何才能快速提高本身的设计能力？以为这个问题很是有表明性，表明了一大波程序猿在艰辛修炼路上的心声。现将我对这个问题的思考、心得体会分享出来，供你们参考，也欢迎提出不一样的意见与见解，共同探讨。

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等），而设计模式自己都是遵照这些原则的，有些模式就是为了遵循某原则而设计出来的。
  抽象不是万能的，在适当的地方使用，须要仔细推敲。当有更好的方案不用抽象就能解决问题时，尽可能避免抽象，笔者见过太多的抽象过火过渡设计的案例了，增长了太多维护成本，还不如按照最天然的方式去写。

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

  有人提意见，先收下它（不管接受与否）。
  不少程序猿，也都有一个毛病，就是以为本身技术牛的不行，不肯意接受别人的意见，尤为是否认意见（文人相轻）。
  而不管是理论的学习，仍是编码实践，向身边的同窗学习将是对本身影响最大的（三人行，必有我师），比刻意参加相关培训要有用的多。
  我本身就常常在跟团队同窗讨论中获益，当百思不得姐的时候，把问题抛出来讨论一下，一般都能获得一个最佳方案。
  另外，跟团队其余人讨论还有一个好处，就是当你的设计有妥协，有些不专业的时候，别人看到代码也不会产生质疑，由于他参与了讨论的，你不用花那么多时间去作解释。
  设计期间就必定要找他人讨论，我一直比较反对一我的把设计作完了，把文档写完了，而后才找你们开个评审会那种模式，虽然也有效果，可是效果然的达不到极致，你们没有参与到设计中来，经过一场会议的时间理解不必定有那么深，最关键的是，若是设计有些问题的时候，但也不是致命问题，难道还让打回从新设计么？
  等前期讨论足够后，你们都知道你的思路与方案，并且最后也有设计文档，当其余人来阅读你的代码的时候，根本无需你再指引，从此的工做交接都不是很须要了，何乐而不为呢？

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

原创文章，转载请注明出处