市面上有很多教大家如何写好代码的书籍，教会大家通过一些设计模式来设计模块，一些规范来书写代码。
但在实际工作中，我们在编写工程代码时会发现，除了书面上提到的一些最佳实践和代码规范，我们实际上要思考的东西要多得多，但我发现网上很少提及这部分，所以想来聊聊我的经验和感悟。
先说实现一个新功能。
如果刚接手新功能，一开始可能想到的是 "如何实现"，你可能会有如下一些想法：
- 看看别人是怎么实现的
- 套模板，copy and paste
但很可能你不会考虑：
- 是否全部的场景，边界条件都处理了
- 接口设计的是否好用，是否满足需求
- 是否有不符合直觉的设计
虽然可能不考虑，功能大概率也会实现。但它或许会给未来带来深远的坏影响。那么如果希望写出可靠的代码，那么我们首先拥有了正确的态度：对待代码要谨慎。不要抱着："我这样写它可以跑诶，管他是否合理"；"虽然有可能出问题，但是概率太小了，要不就不管了吧！" 这样的态度去做事。
但其实有想要变好的想法，与真的能写出优秀的代码之间，还是有很大区别的。
下面提供一些思考的方向：
- 首先设计模块时，最重要的是定义接口。因为这关系到了其他模块要如何使用你的功能。所以要先明确其他模块需要什么样的功能，基于现状设计，而不是基于所谓的 "common" 模型/设计。
- 不要依赖一些无法保证的，由其他模块决定的条件。即使会让你的代码写起来轻松很多。
- 用户不会按你的想法来使用你的程序，所以如果用户以各种"姿势"来使用，是否都没问题。
但要知道什么样的架构是好的，什么是坏的，还是需要多看 "好架构"， 才能在心里有所判断。不能囫囵吞枣的看，要带着思考看：多想为什么这么设计，是为了解决什么问题，现有的框架解决不了这个问题么？如果是你的话你会怎么设计。
再说说如何在原有的基础上添加一些功能。
一般我们在公司开发需求的时候，大部分都是这种情况。之前的功能可能实现的不完善，可能基于特定的条件实现的方案，那么我们在实现新的需求的时候，如果想要实现的好，考虑的东西就非常多了。
我们需要考虑：
- 先抛掉原有的功能，新功能有会有什么使用场景，需要支持什么限制什么？
- 旧功能实现的逻辑，旧的实现有什么问题，最好心知肚明。
- 加了新逻辑后，各种情况需要考虑全面。
- 切忌想当然。
综上，其实还是要慢，一开始慢慢想，培养深度思考的习惯。不要急躁不要糊弄。慢慢训练，方有所成。