写在前面：
编码的道路上，总会遇到形形色色的项目，有困难的，也有容易的；容易的项目没什么好留念的，能铭记在心的，除了那些技术上有挑战、能力上有提升的项目，也还有做的很痛苦的，很失败的项目。今天我就记录下年末做的一个在我看来算是失败的项目吧。
背景：
做一款组织架构的中台，用于商户在商家后台授权微信通讯录权限后，维护销售推应用通讯录和微信通讯录间的同步。
难点：
我觉得有以下几点：
- 员工、部门的同步：有“手动”、“自动”2种同步方式；自动同步只需要接收微信的消息直接同步就行，没什么难点，手动同步的话需要维护一张微信的镜像表，用户点击的时候手动对比，然后把对比的结果同步至另外一方；下面我们就以企业微信到新云为方向，看看如何处理手动同步（说明：本地的镜像表相当于微信的通讯录备份，会实时的接收微信的变更消息）
方向：企业微信到新云，A指企业微信，B指新云
在进行对比之前把2方的数据查询出来,分别维护id->detail的映射关系，方便做对比；比如对比新增思路：A的id在B中没有即为新增，那么利用CollectionUtils.subtract(A,B)新增的id，得出的结果就是新增的结果
| 操作 | 部门 | 员工 |
|---|---|---|
| 新增 | 1、CollectionUtils.subtract(A,B)，2、构造部门树，对1的结果自上而下进行新增 | CollectionUtils.subtract(A,B) |
| 变更 | 1、CollectionUtils.retainAll(A,B) 2、对比1的结果，找出变更的部门 | 同部门 |
| 删除 | CollectionUtils.subtract(B,A) | CollectionUtils.subtract(B,A) |
- 为了避免消息丢失做出的妥协： 想想部门的场景：1、同时新增A、B两个部门，并且A是B的父部门，接收微信的消息中间件中A消息丢失了，那么B部门就没有父部门了。
解决方案：定时全量同步部门的数据，丢的消息会在下次参与同步；
过程：
做的过程很痛苦，在此就不表了，下面总结下过程中出现的问题：
- 代码规范：
必备的入参校验、代码逻辑的非空判断、和第三方系统接入，第三方的限制(微信那边会对某些操作有限制)、逻辑的自洽性，这些问题都是在上了线之后还存在..
- 整体设计:
库表分片的合理性：分片前，应对数据量做下评估，合理的分库分表，组织架构本身数据不多，4库8表就够了，我们这整了16库16表
各个环境的一致性：测试环境和线上环境的分库分表尽量一致吧，我们现在qa没分片、线上分片了，容易有坑
-
单元测试：单元测试及时写，虽然看大家都在吐槽单测，说写单测没用，测不出自己写的bug之类的，但我觉得还是应该写
-
发现坏味道的代码及时修改（有时候可能时间很紧...）
-
在需求讨论的时候尽量多想，在接口设计的时候尽量通用
-
合作过程中，对设计方案有歧义的，并且双方都认为自己是对的情况下，找上级定方案，切记不要憋在心里
-
态度要端正，尤其是面对一堆问题的项目，如果态度不端正了，那么项目只会越做越烂.
最后：
小尾巴走一波，欢迎关注我的公众号，不定期分享编程、投资、生活方面的感悟:)
