记一次失败的项目经历

写在前面：

编码的道路上，总会遇到形形色色的项目，有困难的，也有容易的；容易的项目没什么好留念的，能铭记在心的，除了那些技术上有挑战、能力上有提高的项目，也还有作的很痛苦的，很失败的项目。今天我就记录下年底作的一个在我看来算是失败的项目吧。

背景：

作一款组织架构的中台，用于商户在商家后台受权微信通信录权限后，维护销售推应用通信录和微信通信录间的同步。

难点：

我以为有如下几点：

1. 员工、部门的同步：有“手动”、“自动”2种同步方式；自动同步只须要接收微信的消息直接同步就行，没什么难点，手动同步的话须要维护一张微信的镜像表，用户点击的时候手动对比，而后把对比的结果同步至另一方；下面咱们就以企业微信到新云为方向，看看如何处理手动同步（说明：本地的镜像表至关于微信的通信录备份，会实时的接收微信的变动消息）

方向：企业微信到新云，A指企业微信，B指新云

在进行对比以前把2方的数据查询出来,分别维护id->detail的映射关系，方便作对比；好比对比新增思路：A的id在B中没有即为新增，那么利用CollectionUtils.subtract(A,B)新增的id，得出的结果就是新增的结果

操做	部门	员工
新增	一、CollectionUtils.subtract(A,B)，二、构造部门树，对1的结果自上而下进行新增	CollectionUtils.subtract(A,B)
变动	一、CollectionUtils.retainAll(A,B) 二、对比1的结果，找出变动的部门	同部门
删除	CollectionUtils.subtract(B,A)	CollectionUtils.subtract(B,A)

2. 为了不消息丢失作出的妥协： 想一想部门的场景：一、同时新增A、B两个部门，而且A是B的父部门，接收微信的消息中间件中A消息丢失了，那么B部门就没有父部门了。

解决方案：定时全量同步部门的数据，丢的消息会在下次参与同步；

过程：

作的过程很痛苦，在此就不表了，下面总结下过程当中出现的问题：

1. 代码规范：

必备的入参校验、代码逻辑的非空判断、和第三方系统接入，第三方的限制(微信那边会对某些操做有限制)、逻辑的自洽性，这些问题都是在上了线以后还存在..

2. 总体设计:

库表分片的合理性：分片前，应对数据量作下评估，合理的分库分表，组织架构自己数据很少，4库8表就够了，咱们这整了16库16表

各个环境的一致性：测试环境和线上环境的分库分表尽可能一致吧，咱们如今qa没分片、线上分片了，容易有坑

3. 单元测试：单元测试及时写，虽然看你们都在吐槽单测，说写单测没用，测不出本身写的bug之类的，但我以为仍是应该写

4. 发现坏味道的代码及时修改（有时候可能时间很紧...）

5. 在需求讨论的时候尽可能多想，在接口设计的时候尽可能通用

6. 合做过程当中，对设计方案有歧义的，而且双方都认为本身是对的状况下，找上级定方案，切记不要憋在内心

7. 态度要端正，尤为是面对一堆问题的项目，若是态度不端正了，那么项目只会越作越烂.

最后：

小尾巴走一波，欢迎关注个人公众号，不按期分享编程、投资、生活方面的感悟:)