说一下自己不喜欢的代码是什么样的 1. 分层混乱，没有分层概念或者不关注每个层之间的解耦合，没有建立数据模型在每个层级，比如持久化层的模型直接被用到了表现层，然后为了隐藏持久化层的一些字段做了很多很分散的字段转换 2. 依赖混乱，对分层架构不清晰，从而对代码目录结构不清晰，每个对象之间依赖随意new出来使用，没有在一个统一的入口管理依赖并且对依赖注入，大部分人会把逻辑层写的非常臃肿并且逻辑层内的每个service之间藕断丝连互相耦合 3. 面向过程，最简单的比如A对象转B对象（字段值1/2转男女等），直接来一段if else还是用适配器的模式对象化？比如消息接收后进行处理，但是处理逻辑多个，直接if else还是改发布订阅模式更合理？如果对程序设计原则理解不清晰建议直接套设计模式 4. 没有单元测试，一个大接口A里面有3个小接口，每个小接口有2种输入和对应2种输出，所以A接口有8种情况，如果只能将整个服务运行后对A接口测试需要验证8种输入下的结果，而单元测试则只是对3个小接口分别验证 5. 没有抽象接口，每个层级由外到内，越往底层的接口颗粒度越细也越通用，但每一层依赖的都是具体实现，抽象接口可以很方便地找出所有可用的接口，以及扩展替换实现 6. 多个git库之间代码冗余，没有很好的使用go.mod 7. 多个服务之间配置混乱没有统一的配置管理平台 8. 日志，可以说既没有告警机制也没有方便查找，也没有统一的调用方式，代码上三个项目就有三个打日志风格 9. 服务可观测性几乎为零 目前不一样的地方 1. 领域驱动模型设计，每一层都会抽象接口，并且建立该层数据模型用于解耦各个层级。 2. 依赖管理，service或者dao等每个层级的对象，依赖固定在私有属性，通过选项模式注入，在项目唯一的入口application.Init注入 3. 单元测试，因为每个对象的依赖都在自己私有属性可见，所以使用IDEA的一键生成的单元测试函数填写依赖和输入case条件非常友好。 4. 设计模式，拦截器过滤器责任链适配器发布订阅等，在实现模块的时候，判定是否有匹配的设计模式去优化代码，因为设计模式实现往往也是最符合程序设计原则。
标签：依赖,每个,代码,单元测试,接口,变高,质量,设计模式 From： https://www.cnblogs.com/xuweiqiang/p/16977596.html