多少 ade oss 包括 cto ima api 兩張 測試

這個套系統算是非常完整的，由我自己全程設計構建的系統。其他幾套系統多多少少是與同事合作之類的，並沒有那麽完整的經驗。

不算大的一套東西，但是卻的確學到很多，主要是關於數據庫設計、設計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，名字大概叫什麽，提供什麽樣的功能，可能會設計到的表之類。

信用卡智能還款系統構建經驗與總結