大厂五年经历,教我如何写好工程代码

市面上有很多教大家如何写好代码的书籍,教会大家通过一些设计模式来设计模块,一些规范来书写代码。

但在实际工作中,我们在编写工程代码时会发现,除了书面上提到的一些最佳实践和代码规范,我们实际上要思考的东西要多得多,但我发现网上很少提及这部分,所以想来聊聊我的经验和感悟。

先说实现一个新功能。

如果刚接手新功能,一开始可能想到的是 “如何实现”,你可能会有如下一些想法:

  • 看看别人是怎么实现的
  • 套模板,copy and paste

但很可能你不会考虑:

  • 是否全部的场景,边界条件都处理了
  • 接口设计的是否好用,是否满足需求
  • 是否有不符合直觉的设计

虽然可能不考虑,功能大概率也会实现。但它或许会给未来带来深远的坏影响。那么如果希望写出可靠的代码,那么我们首先拥有了正确的态度:对待代码要谨慎。不要抱着:“我这样写它可以跑诶,管他是否合理”;“虽然有可能出问题,但是概率太小了,要不就不管了吧!” 这样的态度去做事。

但其实有想要变好的想法,与真的能写出优秀的代码之间,还是有很大区别的。

下面提供一些思考的方向:

  • 首先设计模块时,最重要的是定义接口。因为这关系到了其他模块要如何使用你的功能。所以要先明确其他模块需要什么样的功能,基于现状设计,而不是基于所谓的 “common” 模型/设计。
  • 不要依赖一些无法保证的,由其他模块决定的条件。即使会让你的代码写起来轻松很多。
  • 用户不会按你的想法来使用你的程序,所以如果用户以各种“姿势”来使用,是否都没问题。

但要知道什么样的架构是好的,什么是坏的,还是需要多看 “好架构”, 才能在心里有所判断。不能囫囵吞枣的看,要带着思考看:多想为什么这么设计,是为了解决什么问题,现有的框架解决不了这个问题么?如果是你的话你会怎么设计。

再说说如何在原有的基础上添加一些功能。

一般我们在公司开发需求的时候,大部分都是这种情况。之前的功能可能实现的不完善,可能基于特定的条件实现的方案,那么我们在实现新的需求的时候,如果想要实现的好,考虑的东西就非常多了。

我们需要考虑:

  • 先抛掉原有的功能,新功能有会有什么使用场景,需要支持什么限制什么?
  • 旧功能实现的逻辑,旧的实现有什么问题,最好心知肚明。
  • 加了新逻辑后,各种情况需要考虑全面。
  • 切忌想当然。

综上,其实还是要慢,一开始慢慢想,培养深度思考的习惯。不要急躁不要糊弄。慢慢训练,方有所成。


这是一个从 https://juejin.cn/post/7368640074383589427 下的原始话题分离的讨论话题