本文共 789 字，大约阅读时间需要 2 分钟。
项目大致分层：业务处理层，基础逻辑层，数据访问层。
业务处理层：处理业务，并调取相关的基础逻辑，进行数据组合和处理。
基础逻辑层：需要从通用性上去保障，保障处理代码唯一性。必要时需要做业务层的灰度开关。以区别逻辑。
数据访问层：拆分可以从维度和业务大块（从基础逻辑层角度，可以包含多个基础逻辑层的数据）的分类。
基础逻辑层如果做到代码唯一性非常高的情况，可以节约很多的开发成本+测试，比如多个人写同样的逻辑代码，后期的维护往往成为噩梦。
但在多个项目周期并行开发的情况下，还是容易造成多人同时开发有冲突，毕竟pm很少会考虑到研发的基础逻辑层的东西，甚至当时在技术评审的过程也不一定发现此类冲突。更多的情况是边开发代码的时候，突然发现或者想到有项目冲突的可能，负责的开发会找对应相关人开会讨论解决同样逻辑代码被不同的人在开发。早先总想着有这么一个人平时很懂业务，直接拿到pm给到的所有需求做一次整体评估，提前预先做好大致的判断，但这种情况并不能完美地解决问题。如果遇到如下类似的情况，还是有办法进行解决，解决的初衷是尽可能让开发人员有效识别出此类的冲突。
1. 还是基础逻辑层做好代码唯一性，如果项目开发上线都在同一个版本分支进行开发，开发人员一定会遇到此类的冲突，届时根据代码的提交者找到对应的人进行讨论，选出一份最优的方案。若不在同样的地方，最多通过git 代码合并，根据代码位置提示冲突，但是解决不了逻辑代码上的冲突。
2.
修改某个函数的入参，特别是入参数量，git 合并主分支的时候，需要额外检查一下。防止最终上线的时候出现问题。
修改服务的检查，需要和调用方沟通清楚，最好底层本验证联调一遍。
若某个项目在迭代过程中某个线上和线下数据表结构不对，或者项目被暂停。
产品需求必须同时同步给研发，测试，确保大家有原始的输入，需求评审的意义。
转载地址：http://kauoi.baihongyu.com/