這是作者第一次主導(dǎo)系統(tǒng)級(jí)的產(chǎn)品項(xiàng)目總結(jié)，與大家分享，也希望可以給大家?guī)硪恍┙梃b、參考。

背景

從2016年年初開始，我們內(nèi)部一直在討論將原來商城代碼逐步模塊化的構(gòu)想以及可行性。我們?cè)?9年初創(chuàng)，是當(dāng)時(shí)國內(nèi)第一批第三方醫(yī)藥電商平臺(tái)，當(dāng)年的技術(shù)團(tuán)隊(duì)用了一套開源的平臺(tái)電商代碼來二開搭建了這套系統(tǒng)，并一直沿用至今。這七八年時(shí)間，電商行業(yè)的技術(shù)已經(jīng)飛速發(fā)展了，隨著多年的業(yè)務(wù)發(fā)展和多次的團(tuán)隊(duì)更迭之后，再加上中間的管理不善問題，我們?cè)瓉硐到y(tǒng)的代碼耦合度很高，拓展性和可讀性不足，導(dǎo)致很多時(shí)候修改一個(gè)問題會(huì)引發(fā)更多的問題，團(tuán)隊(duì)效率很低，另外在功能和流程上也不滿足現(xiàn)有和未來的業(yè)務(wù)需求。所以當(dāng)時(shí)我們內(nèi)部討論了很長時(shí)間，需要從不停修補(bǔ)丁的做法上抽離出來，從系統(tǒng)底層上進(jìn)行改造，剛好經(jīng)歷了團(tuán)隊(duì)換血，這件事似乎就更順理成章了。

對(duì)此我們討論了不同的做法，包括購買新系統(tǒng)二開還是在原來系統(tǒng)上重構(gòu)等等，最后決定對(duì)現(xiàn)有系統(tǒng)的重點(diǎn)模塊直接進(jìn)行重構(gòu)，首先從商品管理系統(tǒng)開始。（為什么從商品管理系統(tǒng)開始？這里就不作解釋了，文末會(huì)補(bǔ)充有興趣的童鞋可以最后看一下~）

當(dāng)時(shí)團(tuán)隊(duì)進(jìn)行了很多次討論，這個(gè)決定也反反復(fù)復(fù)變了多次，最常被提到的問題是“現(xiàn)在的系統(tǒng)是不是真的爛到用不了了？為什么要搞這么大動(dòng)作？重構(gòu)完就保證一定比現(xiàn)在的好嗎？這是一個(gè)深不見底的坑呀！資源夠嗎？中間有其他緊急項(xiàng)目怎么辦？”… … 我相信這是很多團(tuán)隊(duì)在推動(dòng)重構(gòu)性的項(xiàng)目時(shí)候被問到最多的問題之幾，但其實(shí)這中間沒有必然的對(duì)與錯(cuò)，也沒有標(biāo)準(zhǔn)答案，只是選擇的問題。如果在充分評(píng)估過技術(shù)方案、團(tuán)隊(duì)實(shí)力、可能帶來的風(fēng)險(xiǎn)等因素之后，仍然認(rèn)為進(jìn)行重構(gòu)能夠帶來更大的可預(yù)見收益，那么就開干吧。我很開心，當(dāng)時(shí)我們團(tuán)隊(duì)對(duì)于要做這件事還是比較有共識(shí)的（可能出于程序猿天生不愛看別人代碼），所以即使出現(xiàn)了一些波折，后續(xù)也都一一解決了。

但是不得不說，在商品管理系統(tǒng)重構(gòu)完之后，確實(shí)出現(xiàn)了很多問題，尤其是新舊數(shù)據(jù)庫兼容同步的問題，這或多或少給業(yè)務(wù)方和系統(tǒng)穩(wěn)定性上帶來了一些影響，有一些還是不可逆的影響，這是我們非常抱歉的。具體下面會(huì)說到。

下面來進(jìn)行介紹這套系統(tǒng)的設(shè)計(jì)思路。

現(xiàn)有系統(tǒng)問題

1. 商品結(jié)構(gòu)與規(guī)范的藥品管理信息結(jié)構(gòu)不匹配 — 同一批準(zhǔn)文號(hào)下應(yīng)可存在多個(gè)不同品牌的標(biāo)準(zhǔn)SKU，目前數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)上不符合藥品的特殊屬性；
2. 規(guī)格信息無法管理 — 由于發(fā)布商品機(jī)制和流程的設(shè)計(jì)問題，數(shù)據(jù)庫存在大量重復(fù)的規(guī)格數(shù)據(jù)，例如商家發(fā)布的：3克/片*6片、3g/片x6片、3g/s*6s等本屬同一標(biāo)準(zhǔn)規(guī)格的被劃分為3個(gè)不同規(guī)格，這不利于平臺(tái)對(duì)商品的整體把控，也不利于用戶在網(wǎng)站端進(jìn)行搜索和分類查詢；
3. 基礎(chǔ)庫與商品庫混合 — 基礎(chǔ)產(chǎn)品與商品從結(jié)構(gòu)上是混合管理的，不利于未來平臺(tái)拓展其他橫向業(yè)務(wù)的發(fā)展需求；
4. 基礎(chǔ)庫數(shù)據(jù)維護(hù)十分耗費(fèi)人手 — 目前基礎(chǔ)庫信息由內(nèi)部員工手動(dòng)維護(hù)，沒有引入商家角色共同進(jìn)行維護(hù)，導(dǎo)致人力耗費(fèi)非常大；
5. 商品結(jié)構(gòu)靈活性與可拓展性不足 — 無法為商品增加多維度SKU的信息，如隱形眼鏡類目的商品，無法根據(jù)顏色和度數(shù)進(jìn)行多維度維護(hù)，而“100度 珊瑚色”“150度 珊瑚色”“200度 珊瑚色”這樣的SKU商家需要一個(gè)個(gè)添加；
6. 不支持多渠道的價(jià)格 — 不利于未來拓展多品類商品的業(yè)務(wù)需求；
7. 外部產(chǎn)品接口不規(guī)范 — 商品模塊作為對(duì)接多個(gè)產(chǎn)品的公共模塊，對(duì)外接口仍需優(yōu)化；
8. 界面很老舊，用戶體驗(yàn)不佳。

以上的這些從#4~#8的需求其實(shí)在目前外購或者開源的電子商務(wù)系統(tǒng)上已經(jīng)有非常成熟而穩(wěn)定的解決方案，但由于這套系#1~#3的需求是基于自身業(yè)務(wù)的，醫(yī)藥屬性強(qiáng)，其他一般的電商系統(tǒng)不支持，再加上希望做到跟原有系統(tǒng)更和平的過渡，所以我們最后計(jì)劃是自己來開發(fā)。

新系統(tǒng)做了哪些事情解決這些問題

重新搭建商品數(shù)據(jù)表結(jié)構(gòu)

1. 取消“自定義SKU”機(jī)制，針對(duì)標(biāo)準(zhǔn)化類目建立標(biāo)準(zhǔn)產(chǎn)品與商品的強(qiáng)制關(guān)聯(lián)關(guān)系；
2. 將基礎(chǔ)產(chǎn)品庫與商品庫從結(jié)構(gòu)上進(jìn)行分離，并建立基礎(chǔ)庫和商品庫中的各層商品基礎(chǔ)信息映射關(guān)系，日后基礎(chǔ)產(chǎn)品庫會(huì)作為打通其他橫向產(chǎn)品業(yè)務(wù)的公共庫，而商品庫則主要給到電商平臺(tái)使用。

重建新的商品發(fā)布機(jī)制

1. 在商品發(fā)布時(shí)，允許商家申請(qǐng)新增基礎(chǔ)產(chǎn)品、允許商家修改基礎(chǔ)產(chǎn)品信息提交審核，審核通過后基礎(chǔ)產(chǎn)品信息自動(dòng)入庫；
2. 將商品發(fā)布與基礎(chǔ)產(chǎn)品數(shù)據(jù)維護(hù)整合在一起，引入商家角色維護(hù)基礎(chǔ)信息，節(jié)省內(nèi)部維護(hù)人手。

新增多維度規(guī)格機(jī)制

如下圖，增加“類型”與“通用規(guī)格”的邏輯，與類目關(guān)聯(lián)，為同類型的商品增加多維度規(guī)格的維護(hù)。

優(yōu)化用戶體驗(yàn)

1. 優(yōu)化各頁面各功能的SQL查詢，提升加載速度
2. 優(yōu)化頁面結(jié)構(gòu)與界面UI設(shè)計(jì)

商品系統(tǒng)結(jié)構(gòu)

系統(tǒng)級(jí)的設(shè)計(jì)從大到細(xì)一般分為四個(gè)層次，一般從我們平時(shí)做產(chǎn)品設(shè)計(jì)的時(shí)候，可能會(huì)比較多在#3和#4上，而如果培養(yǎng)自己習(xí)慣從#1和#2層開始去思考這個(gè)功能和界面的設(shè)計(jì)，往往設(shè)計(jì)出來的功能可執(zhí)行性會(huì)更高，與程序猿撕逼的機(jī)會(huì)會(huì)更低：

1. 該系統(tǒng)與外部其他系統(tǒng)的關(guān)系（如何協(xié)作、功能邊界）
2. 系統(tǒng)內(nèi)底層數(shù)據(jù)庫結(jié)構(gòu)設(shè)計(jì)
3. 系統(tǒng)內(nèi)應(yīng)用功能邏輯
4. 系統(tǒng)內(nèi)各界面層建設(shè)

系統(tǒng)結(jié)構(gòu)設(shè)計(jì)

一般的電商系統(tǒng)可以拆成好幾塊主要業(yè)務(wù)。訂單、用戶、商品、促銷等等，對(duì)于第三方平臺(tái)系統(tǒng)來說還有商家。我們目前的系統(tǒng)是按端來拆分的，像文章開始說的，PC端、移動(dòng)端、平臺(tái)后臺(tái)、商家后臺(tái)。各個(gè)端的邏輯是自己管自己的，所以從代碼的層面每一個(gè)端都會(huì)有一套相對(duì)獨(dú)立的訂單、用戶、商品、促銷邏輯。這樣子就會(huì)造成說，由于各種原因?qū)е翽C和移動(dòng)端的處理邏輯可能不統(tǒng)一，不同模塊之間的耦合度高，例如可能改一下商品的顯示邏輯，可能會(huì)影響訂單的和用戶的，加大問題定位的難度。所以我們最后決定逐步建立模塊化系統(tǒng)的方案。其實(shí)這也是目前很普遍的技術(shù)方案，優(yōu)勢(shì)是更加靈活、拓展性強(qiáng)，邏輯相對(duì)各模塊獨(dú)立對(duì)于問題的定位也更精準(zhǔn)。（模塊化的架構(gòu)設(shè)計(jì)大家可以參考一下《淘寶技術(shù)發(fā)展》）

而考慮到我們的資源問題，以及考慮到重構(gòu)后的系統(tǒng)跟現(xiàn)有業(yè)務(wù)進(jìn)行和平對(duì)接，所以我們第一期先以搭建新商品數(shù)據(jù)庫、替換平臺(tái)后臺(tái)與商家后臺(tái)管理功能（涉及到所有產(chǎn)品與商品數(shù)據(jù)增刪查改的功能）為主，其他讀取商品數(shù)據(jù)的功能（如網(wǎng)站前端、其他功能）則維持原來的邏輯，并在新舊數(shù)據(jù)庫之間建立同步機(jī)制，完成第一期的開發(fā)內(nèi)容。（如下圖）新舊數(shù)據(jù)庫的同步機(jī)制在這一點(diǎn)上我們這次踩了很多坑，這一點(diǎn)下面會(huì)有專門的模塊講到，所以也希望大家跟架構(gòu)師和開發(fā)經(jīng)理討論的時(shí)候，對(duì)于新舊數(shù)據(jù)和功能系統(tǒng)的切換方案，還是要謹(jǐn)慎謹(jǐn)慎再謹(jǐn)慎。

數(shù)據(jù)庫底層設(shè)計(jì)

很多人說系統(tǒng)的設(shè)計(jì)歸根到底就是管數(shù)據(jù)的，建立功能和邏輯來去管控這些數(shù)據(jù)的流轉(zhuǎn)以及儲(chǔ)存。這樣的說法雖然片面，但也不無道理。建立一套系統(tǒng)，其實(shí)搞清楚其數(shù)據(jù)庫表結(jié)構(gòu)，就相當(dāng)于搞清楚了它所管理的“對(duì)象”還有“對(duì)象和對(duì)象之間的關(guān)系”，這對(duì)于后續(xù)的功能設(shè)計(jì)是非常重要的。

關(guān)于數(shù)據(jù)庫底層結(jié)構(gòu)很多產(chǎn)品經(jīng)理會(huì)覺得這是開發(fā)經(jīng)理和架構(gòu)師所需要溝通和建立的事情，產(chǎn)品經(jīng)理主要還是在業(yè)務(wù)邏輯和界面上來策劃，這也沒有錯(cuò)，但是為了更好地掌控開發(fā)出來的系統(tǒng)質(zhì)量，我選擇參與到數(shù)據(jù)庫表結(jié)構(gòu)建設(shè)的工作來，下面幾張圖是我基于產(chǎn)品邏輯上的理解對(duì)各種商品管理系統(tǒng)中涉及到的“對(duì)象”和“對(duì)象與對(duì)象之間的關(guān)系”而制作的圖表。其實(shí)這些圖表均不復(fù)雜也不“技術(shù)”，是產(chǎn)品經(jīng)理力所能及的事情，但很有助于開發(fā)以及測(cè)試還有各方干系人更好地理解系統(tǒng)，這樣后面設(shè)計(jì)出來的功能邏輯和界面也會(huì)更加清晰。

功能邏輯結(jié)構(gòu)

一般的第三方平臺(tái)型的商品管理系統(tǒng)都會(huì)有幾個(gè)固定模塊，商品發(fā)布、商品管理、商品上下架、商品審核，這幾塊的流程以及管理功能都是商品管理系統(tǒng)所必須的。而由于醫(yī)藥類目的商品都是屬于高度標(biāo)準(zhǔn)化的商品，而且對(duì)于信息準(zhǔn)確性的要求非常高，市場(chǎng)上的所有藥品、醫(yī)療器械、保健食品、化妝品等都必須在中國國家食品藥品監(jiān)督管理局登記在冊(cè)，而且對(duì)于該類商品而言，有規(guī)范化的參數(shù)與標(biāo)準(zhǔn)，包括批準(zhǔn)文號(hào)、通用名稱、功能主治等所有信息都以在國家藥監(jiān)局注冊(cè)的為準(zhǔn)，所以我們?cè)谠O(shè)計(jì)商品管理系統(tǒng)的時(shí)候需要建立產(chǎn)品庫，并與商品庫分開，另外在工作流上需要將產(chǎn)品庫的信息標(biāo)準(zhǔn)掌握在平臺(tái)管理員手中，而限制商家修改這部分信息的權(quán)限。

在設(shè)計(jì)這套系統(tǒng)的時(shí)候，我參考了天貓的達(dá)爾文商品管理系統(tǒng)（http://open.taobao.com/doc2/detail.htm?articleId=102155&docType=1）。當(dāng)年2012年左右的時(shí)候，淘寶針對(duì)SPU、SKU亂象的問題建立起這套商品管理系統(tǒng)，從流程上通過天貓、商家、品牌商多方參與共建一個(gè)準(zhǔn)確有效的天貓產(chǎn)品庫， 通過品牌歸一、型號(hào)歸一等解決現(xiàn)存的重復(fù)SPU的問題。我們基礎(chǔ)庫的做法其實(shí)是參考了達(dá)爾文的，但是在達(dá)爾文的大框下，在數(shù)據(jù)表設(shè)計(jì)和工作流上再做了適合我們平臺(tái)業(yè)務(wù)的修改。

在功能邏輯這一層，除了考慮到功能點(diǎn)之外，也需要考慮到工作流，每一項(xiàng)功能的工作流，什么角色在什么權(quán)限下能夠做什么樣的操作，需要做怎么樣的判斷，判斷正確和判斷錯(cuò)誤分別會(huì)進(jìn)行什么樣的操作和提示什么樣的信息，這樣的流程會(huì)讓項(xiàng)目里的所有人（包括開發(fā)、測(cè)試、業(yè)務(wù)方）都能清晰每一件事情的走向，也對(duì)產(chǎn)品經(jīng)理在后續(xù)檢驗(yàn)自己的策劃是否有錯(cuò)誤，也對(duì)后續(xù)項(xiàng)目上線后的驗(yàn)收或者使用有很大的幫助。

一般商品管理系統(tǒng)的流程主要是發(fā)布商品、審核商品、上下架的規(guī)則判斷等，而在我們的這次系統(tǒng)設(shè)計(jì)上，還會(huì)加入基礎(chǔ)產(chǎn)品信息發(fā)布和維護(hù)，以及因?yàn)榛A(chǔ)產(chǎn)品信息維護(hù)而影響商品狀態(tài)的流程和同能。這一點(diǎn)大家可以根據(jù)自身的平臺(tái)需求來進(jìn)行設(shè)計(jì)。在流程上標(biāo)識(shí)好每一個(gè)節(jié)點(diǎn)即可。

這一點(diǎn)《后臺(tái)設(shè)計(jì)小結(jié)》 這一篇文章的小哥寫得很不錯(cuò)，后臺(tái)管理系統(tǒng)的設(shè)計(jì)上除了功能和界面之外，權(quán)限流、工作流和日志流也是非常重要的，但這往往我們?cè)谠O(shè)計(jì)后臺(tái)功能的時(shí)候會(huì)忽略，尤其是經(jīng)驗(yàn)不足的時(shí)候。在項(xiàng)目策劃時(shí)期，盡量把每一個(gè)場(chǎng)景、每一個(gè)數(shù)據(jù)、每一句的提示都覆蓋到，把需求做細(xì)做精，其實(shí)是能夠節(jié)省大量在項(xiàng)目中期撕逼的情況（雖然還是免不了要撕逼，:）。下圖是當(dāng)時(shí)做的原型文件中的頁面：

看不見的需求 ???

除了以上看得見的需求之外，還有一部分需求是看不見的。

1. 上文講到的權(quán)限管理。作為后臺(tái)管理系統(tǒng)，用戶角色權(quán)限系統(tǒng)管理都是必要的功能模塊。由于要兼顧舊有平臺(tái)的使用，以及避免要管理兩套用戶權(quán)限，所以這一期商品管理系統(tǒng)的權(quán)限管理是直接使用接口的方式跟舊有平臺(tái)進(jìn)行同步。
2. 上文講到的日志管理。這一期的開發(fā)我們并沒有考慮到日志操作管理，導(dǎo)致我們?cè)诤竺嬗龅揭驗(yàn)閿?shù)據(jù)同步還有程序出現(xiàn)問題的時(shí)候，我們沒有辦法非常有效和及時(shí)地定位出問題。日志操作管理是為了方便管理和跟蹤業(yè)務(wù)處理過程，并依據(jù)業(yè)務(wù)系統(tǒng)使用活動(dòng)過程記錄的信息，分析系統(tǒng)的使用情況、存在問題和對(duì)任意業(yè)務(wù)處理的過程追蹤管理。而如果一開始忘了，后面要補(bǔ)可能是一個(gè)相對(duì)復(fù)雜的過程，就像我們現(xiàn)在這樣。所以我們下一版本也計(jì)劃把操作日志記錄這塊補(bǔ)上。
3. 商家ERP接口對(duì)接。我們有部分商家自己沒有技術(shù)力量，所以如果我們的ERP接口的需要重新開發(fā)的話，會(huì)對(duì)商家的業(yè)務(wù)有很大影響。在跟團(tuán)隊(duì)商量過后，我們決定保留原來接口的協(xié)議以及邏輯，但是對(duì)接到新商品數(shù)據(jù)庫上面來，在商家不需要做任何修改的情況下，依然正常使用。（因?yàn)槟壳拔覀兊腅RP接口只有查詢和更新少量商品信息的功能，沒有發(fā)布和提交審核功能，所以可以這樣改。）
4. 新舊平臺(tái)數(shù)據(jù)同步機(jī)制。第一期我們將幾乎所有涉及商品數(shù)據(jù)增刪查改的功能全部進(jìn)行了替換，換到新的管理平臺(tái)進(jìn)行，舊平臺(tái)只保留查詢功能以及3個(gè)影響商品數(shù)據(jù)的功能。因?yàn)橘Y源和時(shí)間問題，而且考慮到風(fēng)險(xiǎn)的問題，所以我們第一期仍保留網(wǎng)站前端的功能不變，前端依然讀取舊商品庫，通過新舊商品庫單向同步（新的同步到舊的）的方式更新舊庫商品數(shù)據(jù)。而3個(gè)影響商品數(shù)據(jù)的功能采用數(shù)據(jù)庫觸發(fā)器的方式單向從舊庫同步到新庫。就是上文架構(gòu)圖所寫的。后續(xù)計(jì)劃在系統(tǒng)運(yùn)作相對(duì)穩(wěn)定，資源相對(duì)充足的情況下，會(huì)針對(duì)各個(gè)端逐步替換，最終拋棄舊的數(shù)據(jù)庫。

界面應(yīng)用層設(shè)計(jì)

界面應(yīng)用層的設(shè)計(jì)是大部分產(chǎn)品經(jīng)理每天都做的工作了，主要需要考慮到的就是用戶體驗(yàn)方面的功能。這次的商品管理系統(tǒng)，界面只有后臺(tái)界面，用戶分別是平臺(tái)各部門的同事以及商家。我認(rèn)為后臺(tái)系統(tǒng)的界面或者說用戶體驗(yàn)是否好，主要考察的是兩點(diǎn)，提高效率，降低出錯(cuò)。

除了頁面布局和UI界面以外，其實(shí)對(duì)于控件使用統(tǒng)一性、適量清晰的提示、數(shù)據(jù)加載的時(shí)間、動(dòng)畫的流暢度、出錯(cuò)時(shí)的提示等等這些都屬于用戶體驗(yàn)的一部分，這些都非常有助于提升用戶操作的效率以及降低其錯(cuò)誤率。界面這一塊我就不多說了，還是要多看看其他人的設(shè)計(jì)，多用心站在用戶立場(chǎng)試用，后期多搜集用戶意見就能夠清楚了。

數(shù)據(jù)同步是個(gè)大坑

總結(jié)整個(gè)項(xiàng)目下來，遇到比較多問題的引起都是由于新舊數(shù)據(jù)同步以及不兼容而產(chǎn)生的。如上文所述，由于資源和時(shí)間問題，而且考慮到風(fēng)險(xiǎn)的問題，所以我們第一期仍保留網(wǎng)站前端的功能不變，前端依然讀取舊商品庫，通過新舊商品庫單向同步（新的同步到舊的）的方式更新舊庫商品數(shù)據(jù)。這個(gè)方案在立項(xiàng)之前其實(shí)我們就已經(jīng)多次討論過，當(dāng)時(shí)有三個(gè)方案，一個(gè)是在舊的數(shù)據(jù)庫上進(jìn)行改造，另一個(gè)是做節(jié)點(diǎn)（在上線之后，直接拋棄舊庫）。

但最后決定用新舊同步的方案原因是這樣對(duì)系統(tǒng)的穩(wěn)定性影響最低。由于我們是從根本結(jié)構(gòu)上進(jìn)行改造，原有的表結(jié)構(gòu)不能使用了，要變更數(shù)據(jù)庫表結(jié)構(gòu)，那么連同其應(yīng)用層的邏輯基本上都需要重寫。這意味著如果不進(jìn)行同步，我們需要全網(wǎng)整體代碼進(jìn)行替換，這樣的工作量太大，且如果萬一新系統(tǒng)有嚴(yán)重問題，會(huì)對(duì)業(yè)務(wù)影響很大。而采用同步的方法，工作量相對(duì)小，且如果新系統(tǒng)有嚴(yán)重問題，只要將同步機(jī)制斷掉（如下圖），將平臺(tái)和商家后臺(tái)切換回原來的舊后臺(tái)，也能保持正常使用。

設(shè)計(jì)數(shù)據(jù)同步方案時(shí)的幾個(gè)注意點(diǎn)：

1. 表結(jié)構(gòu)設(shè)計(jì)。在進(jìn)行表設(shè)計(jì)的時(shí)候，要將舊庫的每一張表每一個(gè)字段可能影響到的每一個(gè)功能都詳細(xì)列出，并做好一一對(duì)應(yīng)，這樣在設(shè)計(jì)新表的時(shí)候就能夠更好地兼容所有商品相關(guān)功能。除了舊對(duì)應(yīng)到新表上面去，也要思考新表的數(shù)據(jù)如何對(duì)應(yīng)回舊表并兼容舊平臺(tái)的功能，因?yàn)槲覀冇胁糠止δ苓€是要在舊平臺(tái)上實(shí)現(xiàn)，所以兩邊的數(shù)據(jù)表和數(shù)據(jù)結(jié)構(gòu)如何做到兼容是很關(guān)鍵的。這一點(diǎn)上我覺得我們做得還是挺不錯(cuò)的，在新舊數(shù)據(jù)庫表和功能之間的覆蓋基本上做到了95%以上，沒有出現(xiàn)比較大的問題。
2. 數(shù)據(jù)初始化。平臺(tái)經(jīng)過了多年的發(fā)展，再加上之前的維護(hù)不夠，存在著大量的臟數(shù)據(jù)。有一些臟數(shù)據(jù)是無法從功能和邏輯上說得清的怎么產(chǎn)生的，有一些臟數(shù)據(jù)是之前由于bug產(chǎn)生的數(shù)據(jù)，但是因?yàn)樵谡Ｊ褂弥校砸脖仨毧紤]是同步過去還是丟棄掉。除了臟數(shù)據(jù)之外，還需要考慮數(shù)據(jù)的不同狀態(tài)。在初始化之前再三多方共同檢查初始化腳本、做好數(shù)據(jù)的備份、溝通好初始化數(shù)據(jù)檢查的機(jī)制，包括初始化數(shù)據(jù)的數(shù)量、狀態(tài)，初始化后進(jìn)行比對(duì)。這個(gè)工作量是很大很枯燥的，而且很重要，一旦初始化之后沒有檢查清楚投產(chǎn)使用，后面會(huì)產(chǎn)生更多問題數(shù)據(jù)，就沒有辦法恢復(fù)了。我們?cè)谶@件事情上，吃了很多虧，直到現(xiàn)在都還有一些問題持續(xù)在處理當(dāng)中。
3. 數(shù)據(jù)同步機(jī)制。我們針對(duì)不同的功能采用了不同的數(shù)據(jù)同步機(jī)制，針對(duì)一般時(shí)效性要求不高的功能采用程序觸發(fā)隊(duì)列更新的同步機(jī)制，針對(duì)需要及時(shí)修改的如商品價(jià)格和上下架和庫存等數(shù)據(jù)采用程序直接觸發(fā)新舊庫更新的機(jī)制，針對(duì)舊庫同步到新庫的功能（如前端用戶下單后扣減庫存）采用數(shù)據(jù)庫觸發(fā)器的機(jī)制。同步機(jī)制的制定可以根據(jù)不同功能的要求，充分與開發(fā)技術(shù)進(jìn)行討論確定下來。
4. 數(shù)據(jù)檢查機(jī)制。除了初始化的數(shù)據(jù)檢查機(jī)制之外，在維護(hù)期可能會(huì)有頻繁地批量操作數(shù)據(jù)的事情，尤其是當(dāng)批量功能沒有在需求策劃階段被考慮進(jìn)去的情況，所以當(dāng)需要批量操作數(shù)據(jù)的時(shí)候，往往由于各種原因出現(xiàn)問題，所以數(shù)據(jù)比對(duì)的檢查機(jī)制就很重要了。這個(gè)可能需要拉上開發(fā)和測(cè)試的同學(xué)，使用數(shù)據(jù)比對(duì)的工具進(jìn)行。

項(xiàng)目回顧

最后回顧一下項(xiàng)目的時(shí)間節(jié)點(diǎn)和成員，大家在進(jìn)行類似項(xiàng)目的時(shí)候可以大致參考一下。2016年6月開始需求調(diào)研，2016年8月開始需求策劃，2016年9月底項(xiàng)目啟動(dòng)，原計(jì)劃2016年12月底項(xiàng)目上線，這樣能夠趕在2017年1月底過年之前有一個(gè)相對(duì)長的運(yùn)作期，恰好是元旦后春節(jié)前，商家和用戶操作會(huì)減少，如果真的出問題影響會(huì)比正常時(shí)間要小。但后來因?yàn)橛许?xiàng)目插隊(duì)還有開發(fā)時(shí)間延長的問題，最終在2017年2月初春節(jié)后回來上線。截止2017年4月迭代了5個(gè)小版本，仍然持續(xù)迭代中。

項(xiàng)目成員包括產(chǎn)品經(jīng)理一個(gè)、前端一個(gè)半、后臺(tái)開發(fā)三個(gè)、測(cè)試兩個(gè)半、運(yùn)維一個(gè)，還有其他包括舊平臺(tái)的開發(fā)童鞋協(xié)助。由于后臺(tái)系統(tǒng)采用的是一個(gè)開源框架來做前端，所以并沒有用到設(shè)計(jì)資源。

小彩蛋：為什么先從商品模塊開始重構(gòu)？

1. 作為醫(yī)藥電商平臺(tái)，我們的商品數(shù)據(jù)結(jié)構(gòu)需求是一般的電商系統(tǒng)無法兼容的；而訂單、會(huì)員等其他功能，基本與其他電商系統(tǒng)無異，目前的系統(tǒng)仍然能支撐業(yè)務(wù)，所以其他模塊的優(yōu)先級(jí)不高；
2. 商品管理從功能界限上相對(duì)獨(dú)立，但是大部分的邏輯都在商品管理系統(tǒng)內(nèi)部，與外部系統(tǒng)以及第三方對(duì)接少，影響可能相對(duì)低；
3. 考慮到公司的整體戰(zhàn)略規(guī)劃，未來希望建立自己的藥品庫，可以提供給不同的產(chǎn)品進(jìn)行對(duì)接，包括資訊社區(qū)、問答社區(qū)、疾病庫等等，可以作為我們自身的專業(yè)數(shù)據(jù)庫。

后記

這是我第一次主導(dǎo)系統(tǒng)級(jí)的產(chǎn)品項(xiàng)目，雖然只是我們公司內(nèi)部電商系統(tǒng)的一個(gè)商品子系統(tǒng)，但是在經(jīng)歷了這半年一個(gè)人從需求調(diào)研到產(chǎn)品策劃設(shè)計(jì)一腳踢，從開發(fā)開始到延誤三次最終上線，從上線后被狂批再到目前經(jīng)過幾次版本維護(hù)后逐步順暢起來，中間的思考和多次踩坑的經(jīng)驗(yàn)，都讓我對(duì)產(chǎn)品設(shè)計(jì)有了不同的認(rèn)識(shí)，我希望把這些記錄下來，算是給自己這半年工作一個(gè)小結(jié)，也希望能夠跟其他童鞋一起交流~

本文由 @KitWu 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。