記一次失敗的項目經歷

寫在前面：

編碼的道路上，總會遇到形形色色的項目，有困難的，也有容易的；容易的項目沒什麼好留念的，能銘記在心的，除了那些技術上有挑戰、能力上有提高的項目，也還有作的很痛苦的，很失敗的項目。今天我就記錄下年底作的一個在我看來算是失敗的項目吧。

背景：

作一款組織架構的中臺，用於商戶在商家後臺受權微信通信錄權限後，維護銷售推應用通信錄和微信通信錄間的同步。

難點：

我以爲有如下幾點：

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. 態度要端正，尤爲是面對一堆問題的項目，若是態度不端正了，那麼項目只會越作越爛.

最後：

小尾巴走一波，歡迎關注個人公衆號，不按期分享編程、投資、生活方面的感悟:)