业务代码还需要优秀的设计吗

[young_ao]

业务代码每隔几个月或一年，原有逻辑就会发生翻天覆地的变化。这种情况下，在代码维度是否还需要做精细的设计？

举个例子：

1、两个服务有依赖，a服务为上游，b服务为下游。为了解耦采用mq方式进行通信（仅很小流量的通信），这样做的缺点是服务在业务上的关联不清晰。当一个服务中有较多这样的代码，后续接手的人会感到恶心，完全不知道上游业务是谁，且当消息出现问题（尤其是内部mq平台建设不成熟、环境差时），增大了排查成本。

所以是否可以采用接口的方式来通信，做好超时熔断等策略，尽管增加了耦合，但是开发效率会提升。而且过不了多久，需求本身就会变化、维护者就会换一批人，这样既便于后人修改，又节省了开发时间，又避免了异构。

2、有如下操作，先从缓存查找，如果没有则查找数据库，最后放到缓存中。有人说应把这个操作放到dao层中，对service透明。但是我却不认同：因为需求变化非常快，下一位开发者可能觉得你封装的dao方法不适合他，所有又写了一套极其类似的方法。这样的后果是代码大大冗余、混乱，最终出线上bug。

所以是否可以在dao层把查数据库、查缓存、写缓存写成独立的方法，上层servcie做组合。

 

以上例子是我在工作中切实遇到过的，并且与一些同事上级沟通过，但是他们丝毫不在乎，依旧坚持去设计‘精细’的代码，我的这种想法被他们理解为代码上无追求，但反问他们，却给不出切实的解决办法，只能依靠代码review来强制后人去修改历史屎山。

 

此时我陷入深深的疑惑中，不知是我层次过低， 不能体会精细代码在软件工程中的重要作用，还是同事们死搬教条，不知变通。还请各位大佬解惑！

[hnzsly]

看时间成本写代码

[weixin_41711560]

2. 我赞同你的做法，无论是从时间成本还是代码设计出发：
   时间成本：查数据库，查写缓存都应该是dao层已有的方法，例如redis的set(key， value)。
   代码设计：dao层是对数据操作的层面 ，不应该写入过多的逻辑。并且即使之后需求变更，service也可以重复利用dao层提供的方法，而不是一直在dao层叠*山。