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