電商積分支付系統構建經驗與總結

這個套系統算是很是完整的，由我本身全程設計構建的系統。其餘幾套系統多多少少是與同事合做之類的，並無那麼完整的經驗。

不算大的一套東西，可是卻的確學到不少，主要是關於數據庫設計、設計api、代碼結構設計、項目推動、項目時間和難度的預估、測試預估。

項目從拿到需求到積分系統的完成(包括對接現有支付模塊，編寫測試之類)其實耗時很少，大概在16個天，對帳系統包括測試作了4天總工做日大概在20天。可是這個看似正常的時間，跟最開始估計的時間相差甚遠。我在前期有不少加班包括週末加班的狀況下才勉強能照着如今這個進度完成，實際上最初估沒有對帳系統的完成時間只有12天，中間差了4個工做日，算上加班的時間可能差了7個工做日。可能這就是不常常預估項目時間的人容易犯下的錯誤吧，對本身的編碼效率莫名自信，卻不知裏面其實有大量不可控因素影響進度。其中很大影響比重在於修改前面人寫的支付模塊的代碼上，不只須要大量時間閱讀前面的人寫的代碼和思路，還須要把本身的邏輯加進去，這極花時間。因此估時間的時候必定要預留充足的時間，這個後面再提一下。

 

(一) 仍是按順序來吧，先說數據庫設計，設計API，設計代碼結構

花了大概兩天時間設計了數據庫，一共涉及到11張表。弄好了以後拉着leader和主管開了一個短會，我闡述了個人設計思路，而後拉着他們幫我看看設計是否存在問題，或者有沒有地方有漏洞是我沒有辦法考慮到的。這裏我其實設計了兩張流水錶，每當有一筆收入或者支出的積分，都會在支出和收入的流水錶裏面增長一條記錄，可是最開始的時候，由於某些緣由我可能須要update流水錶裏面的字段，可是leader告訴我流水錶最好不要有update的操做，這樣可能比較容易出錯，流水錶只往內記錄，不更新，這樣不會出問題。這點使得我開始從表穩定性去思考這個問題，以爲仍是有必定道理。由於流水錶最終在結算的時候可能用於對帳，一旦這個表由於更新字段出現問題，那麼對帳就會出錯，電商系統的對帳出錯的話。。。。。

找前輩幫忙看由於他們比我更熟悉系統，因此必定要拉他們幫本身看看，不然有些坑，或者之前弄的hack可能會影響到新的系統進行某些操做。作了一些改動，而後咱們一致贊成了一個決定，就是若是所有作好一塊兒上線代碼量超大最少2k行，可能徹底沒有辦法review。畢竟要花時間去看一個2k行代碼的項目，仍是須要花費很多的時間。因此決定將項目拆成兩塊分批上線。因爲構件積分的查詢存儲使用之類的東西是徹底不會影響到現有系統的，因此能夠單獨上線，而後將接入如今的支付退款系統做爲另一部分進行上線。這樣就拆開了如今邏輯和新構件系統的耦合，看代碼上面也會變得稍微方便一些。

 

當時討論完以後,leader讓我最好當天的下午，或者次日的早上將這套東西要提供給app的api定出來，大概須要哪些api。api定下來以後，寫東西就能夠按照api來依次實現功能了。

這個步驟真的是讓我大受啓發，在數據庫設計完成以後，就設計到底要提供哪些功能出來，就能完成初步的api設計。這樣想就能夠安好想提供的功能依次編寫代碼了，也不容易漏掉什麼東西。其實這裏面最難的部分，就是將思路理清楚，能讓本身知道究竟有哪些工做完成，什麼先完成，什麼能夠後完成比較好。在設計完api和數據庫以後我可能須要畫一些圖，和作一些筆記來輔助我思考這些問題纔可讓我本身的思路變得更清晰。我本身的畫拿了幾張a4紙在上面大概畫了寫了一下有哪些api，名字大概叫什麼，提供什麼樣的功能，可能會設計到的表之類。

 

最後這個chapter裏面關於代碼結構：

 

dao裏面存放了各新建表的模型，因爲使用orm因此使用到這些模型。

model裏面存放了各類中間邏輯，包括調用dao裏面的方法建立更新刪除數據，拼接各種數據。

外面api提供了各功能的api函數，api層我只處理了入參，保證各入參的類型合法而後傳給model對應的函數進行進一步的邏輯處理。

const裏面存放了各類可能會使用到的常量。在設計常量存放的時候此次踩了一個坑，最好把有哪幾個可能出現的常量類型分別創建一個類，在類下面寫，並且最好提早分配好他們所屬的數字區域。打個比方，咱們可能有支出和收入不一樣的常量需求，千萬不要寫成這種：

class IncomeConst(object):
    INCOME_NORMAL_REVIEW = 1  # 正常評價得到積分
    INCOME_REVIEW_BONUS = 2  # 好評得到的額外積分
    INCOME_UNLOCK_ORDER = 5  # 訂單積分解除鎖定
    INCOME_REFUND_ORDER = 7  # 退款退積分


class ExpenditureConst(object):
    EXPENDITURE_FRESH_MEMBER = 3  # 愛嚐鮮購買
    EXPENDITURE_LOCK_ORDER = 4  # 訂單積分消費鎖定
    EXPENDITURE_OFFSET_CASH = 6  # 積分抵現

 

應該首先肯定income裏面佔用的是1000-1999的數字 那麼expenditure就能夠佔用2000-2999的數字 這樣能保證一樣類型的const是連貫的就像這樣：

class IncomeConst(object):
    INCOME_NORMAL_REVIEW = 1000  # 正常評價得到積分
    INCOME_REVIEW_BONUS = 1001  # 好評得到的額外積分
    INCOME_UNLOCK_ORDER = 1002  # 訂單積分解除鎖定
    INCOME_REFUND_ORDER = 1003  # 退款退積分


class ExpenditureConst(object):
    EXPENDITURE_FRESH_MEMBER = 2001  # 愛嚐鮮購買
    EXPENDITURE_LOCK_ORDER = 2002  # 訂單積分消費鎖定
    EXPENDITURE_OFFSET_CASH = 2003  # 積分抵現

不要把本身搞得像個精神分裂同樣，遇到了就往裏加一項數字上漲一個。。。。簡直不忍直視＝ ＝。

exception裏面存放了各類可能會拋出的錯誤，統一繼承自Excepition類

 

(二) 項目推動

項目推動的過程當中，無非是按照前面設計好的東西循序漸進的一個模塊一個模塊的寫。其實中間也沒有碰到什麼特別坑爹的事情，只是把原先的兩個上線步驟拆成了三個，由於發現前面其實雖然沒有構建整套積分支付的東西，可是卻有記錄用戶積分的東西，在用戶評論商品以後會給用戶記錄積分的，這就形成了前面多多少少寫了一些積分的東西，我須要把這些原有的東西分好類從新放回到積分新設計的積分模塊裏面去。這一步其實我在估時間的時候沒有想到的，因爲前面寫的代碼比較隨便，致使我遷移起來很費勁，有很是多的依賴滿天飛，多花了不少時間，並且是影響線上的東西不得不當心翼翼，測了又測。總結了一個經驗，先從依賴最少的地方開始拆，拆完一塊就測一塊。這樣一步一步的弄幾乎不會出錯。千萬不要一連遷好幾塊的東西，最後再來一塊兒測，那個時候要是再測出了問題，我相信改起來的難度很是大。你要依次去排查是前面哪一個改動致使了這個問題，這幾乎的是不可行的。

遷移的理想狀態是，全部東西都有單元測試，若是沒對的狀況下，跑單元測試都會報錯，你就能及時發現並切改動。現實是(好殘酷的樣子)，若是沒有單元測試，你可能須要穩健的一步一步來。當你把簡單的東西都遷走以後，你會發現以前那些難以遷移的東西也變成容易遷的東西了。

 

(三) 項目進度預估，對項目時間包括測試部分的預估

就像第一部分談到的，其實若是時間很是充足和從容，你可能有大把時間來按照我上面說的流程對關鍵部分進行仔細測試，甚至給每一個地方都帶上單元測試。現實是若是你本身估的項目時間太短，你可能沒有時間來完善測試方面的事情。前提是你的公司裏面沒有專職QA,測試幾乎須要你本身完成，這個時候，將測試時間估算進你項目進度顯得很是重要。我此次的測試時間大概佔完成項目時間的30％，這個結果很大部分取決於我還用了很多業餘時間完成項目或進行測試，以及依賴一些之前同事編寫的支付部分的測試，若是所有本身來的話我估計時間至少須要估完成項目時間的50％時間用於測試或者編寫單元測試。也就是說若是你估計這個項目你15天能夠寫完，你可能大概須要額外的7天時間用於測試和修復測試出來的bug，以及本身對代碼二次review。這樣的進度才能保證你代碼的質量，以及在上線以後不用提心吊膽是否會被客戶端或者web端的同事找麻煩。

對時間方面的估算，沒有幾個項目的經歷是確定估不許的，在你發如今deadline以前完成不了項目的時候，必定要向本身的leader說明項目延期，以及由於什麼緣由致使了項目延期，而且儘快完成項目。因此對項目推動節奏的把控，可能嚴重影響項目質量，既不能夠徹底沒有壓力和時間上的deadline隨意完成項目，也不可把項目時間卡得過於緊，由於中間除了我上面分析得問題，還又可能出現諸如你須要請假有事，中途任務的插入。

 

以上。