恭喜你发现了宝藏，编程习惯-日积月累

总结：

1. 条件查询可在数据库层创建queryDto进行统一操作。

2. 代码复用：若有代码重复出现了三次，很大概率可以重构。（三则重构）

3. dto和entity中的赋值操作，可以写成方法放在dto中。（充血模型）

4. dto中不写id，id是前端另外传过来或后端生成的。（幂等）

5. 取和存数据相同时，可只用entity一个数据传输对象。

6. 使用框架、工具类的代码不可直接在业务层引入（业务就是业务，工具可以包装调用），操作数据需统一通过持久化层进行封装（持久层与业务层代码隔离）。

7. 领域、对象的命名需使用名词，不可有歧义。若命名不理想，需商讨。（软件设计很重要的一点：如何命名）

8. 接口对外暴露地址要语义明确，单词间使用 “-” 分割（简短精确！restful）

9. 当领域中有相似功能实现时，有三种数据库设计方式：

​ （1）将所有字段合并在一张表中，各业务留冗余为空的字段。【不使用】

​ （2）抽离出公共属性字段，独立成表，在使用时关联相关独立业务表查询。【符合第三范式，但在查询时需要扫描连表查询，使用较少】

​ （3）在实际使用中，常常使用水平拆分，降低单库（一张表）的数据量，使用反范式设计来满足不同维度上的查询需求。将两张表中的查询展示数据抽离在一张表中，保留一定的数据冗余，通过标志位区分不同业务。其余的一些下一阶段的查询存放于各自的单表中。实现冗余和查询功能的中和。【使用较多】

10. 前后端有关时间类型的传输要保证准确，统一使用编程语言中的时间类型进行传输，而不采用String，具体使用再进行不同的转化。

11. 每一个实体所包含的字段，应该具有该实体的唯一使用场景。如：游戏中的"预约数"，该字段虽为游戏本身属性，但只针对"预约游戏"，而非所有的游戏（包含已上线的游戏），这时，应将 预约数量独立出来，而非与"游戏"实体的固有属性存放在一张数据库表中。

12. 领域之间的松耦合：一个领域中使用一个service，同一个Repository只在对应领域中的一个service中出现。若两个领域中有业务上的交互，那么应该由被调用方抽离出被调用的方法，提供调用接口（如：GameServiceFacade）给调用方使用。若业务不复杂或交互点不多时，也可直接进行service层的互调。

13. 测试

​ （1）为了利于编码测试，可以在业务层进行改造，改造方式有两种：1、修改repo的注入方式，将mock包裹的repo对象注入service中的repo；2、修改业务层逻辑，将独立的repo逻辑剔出，放在controller统一调用。

​ （2）能不使用mock进行隔离则不进行mock隔离，保证代码在功能上的独立测试性。

关于测试：如果你的代码功能不利于单元测试，那么你的代码多半是有毛病的(很大的重构空间和优化空间)

14. k8s是个好东西，不要拒绝难度高的技术选型。
15. 允许数据结构上的字段冗余，权衡利弊，这个需要经验。
16. 少用继承（extents），多用组合（implement）。其实工作中我几乎不会用继承，徒增复杂度。

引用一下：我的观点没那么极端！之所以“多用组合少用继承”这个口号喊得这么响，只是因为，长期以来，我们过度使用继承。
还是那句话，组合并不完美，继承也不是一无是处。只要我们控制好它们的副作用、发挥它们各自的优势，在不同的场合下，恰当地选使用继承还是组合，这才是我们所追求的境界。

更新：2021-10-19

总结

以上是生活随笔为你收集整理的恭喜你发现了宝藏，编程习惯-日积月累的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。