這個套系統(tǒng)算是非常完整的，由我自己全程設(shè)計構(gòu)建的系統(tǒng)。其他幾套系統(tǒng)多多少少是與同事合作之類的，并沒有那么完整的經(jīng)驗。

不算大的一套東西，但是卻的確學(xué)到很多，主要是關(guān)于數(shù)據(jù)庫設(shè)計、設(shè)計api、代碼結(jié)構(gòu)設(shè)計、項目推進、項目時間和難度的預(yù)估、測試預(yù)估。

獨立商城網(wǎng)站項目從拿到需求到積分系統(tǒng)的完成(包括對接現(xiàn)有支付模塊，編寫測試之類)其實耗時不多，大概在16個天，對賬系統(tǒng)包括測試做了4天總工作日大概在20天。但是這個看似正常的時間，跟最開始估計的時間相差甚遠。我在前期有很多加班包括周末加班的情況下才勉強能照著現(xiàn)在這個進度完成，實際上最初估沒有對賬系統(tǒng)的完成時間只有12天，中間差了4個工作日，算上加班的時間可能差了7個工作日?？赡苓@就是不經(jīng)常預(yù)估項目時間的人容易犯下的錯誤吧，對自己的編碼效率莫名自信，殊不知里面其實有大量不可控因素影響進度。其中很大影響比重在于修改前面人寫的支付模塊的代碼上，不僅需要大量時間閱讀前面的人寫的代碼和思路，還需要把自己的邏輯加進去，這極花時間。所以估時間的時候一定要預(yù)留充足的時間，這個后面再提一下。

(一) 還是按順序來吧，先說數(shù)據(jù)庫設(shè)計，設(shè)計API，設(shè)計代碼結(jié)構(gòu)

花了大概兩天時間設(shè)計了數(shù)據(jù)庫，一共涉及到11張表。弄好了之后拉著leader和主管開了一個短會，我闡述了我的設(shè)計思路，然后拉著他們幫我看看設(shè)計是否存在問題，或者有沒有地方有漏洞是我沒有辦法考慮到的。這里我其實設(shè)計了兩張流水表，每當(dāng)有一筆收入或者支出的積分，都會在支出和收入的流水表里面增加一條記錄，但是最開始的時候，因為某些原因我可能需要update流水表里面的字段，但是leader告訴我流水表最好不要有update的操作，這樣可能比較容易出錯，流水表只往內(nèi)記錄，不更新，這樣不會出問題。這點使得我開始從表穩(wěn)定性去思考這個問題，覺得還是有一定道理。因為流水表最終在結(jié)算的時候可能用于對賬，一旦這個表因為更新字段出現(xiàn)問題，那么對賬就會出錯，電商系統(tǒng)的對賬出錯的話。。。。。

找前輩幫忙看因為他們比我更熟悉系統(tǒng)，所以一定要拉他們幫自己看看，否則有些坑，或者以前弄的hack可能會影響到新的系統(tǒng)進行某些操作。做了一些改動，然后我們一致同意了一個決定，就是如果全部做好一起上線代碼量超大最少2k行，可能完全沒有辦法review。畢竟要花時間去看一個2k行代碼的項目，還是需要花費不少的時間。所以決定將項目拆成兩塊分批上線。由于構(gòu)件積分的查詢存儲使用之類的東西是完全不會影響到現(xiàn)有系統(tǒng)的，所以可以單獨上線，然后將接入現(xiàn)在的支付退款系統(tǒng)作為另外一部分進行上線。這樣就拆開了現(xiàn)在邏輯和新構(gòu)件系統(tǒng)的耦合，看代碼上面也會變得稍微方便一些。

當(dāng)時討論完之后，leader讓我最好當(dāng)天的下午，或者第二天的早上將這套東西要提供給app的api定出來，大概需要哪些api。api定下來之后，寫東西就可以按照api來依次實現(xiàn)功能了。

這個步驟真的是讓我大受啟發(fā)，在數(shù)據(jù)庫設(shè)計完成之后，就網(wǎng)上電子商城系統(tǒng)設(shè)計到底要提供哪些功能出來，就能完成初步的api設(shè)計。這樣想就可以安好想提供的功能依次編寫代碼了，也不容易漏掉什么東西。其實這里面最難的部分，就是將思路理清楚，能讓自己知道究竟有哪些工作完成，什么先完成，什么可以后完成比較好。在設(shè)計完api和數(shù)據(jù)庫之后我可能需要畫一些圖，和做一些筆記來輔助我思考這些問題才可以讓我自己的思路變得更清晰。我自己的畫拿了幾張a4紙在上面大概畫了寫了一下有哪些api，名字大概叫什么，提供什么樣的功能，可能會設(shè)計到的表之類。

最后這個chapter里面關(guān)于代碼結(jié)構(gòu)：

dao里面存放了各新建表的模型，由于使用orm所以使用到這些模型。

model里面存放了各種中間邏輯，包括調(diào)用dao里面的方法創(chuàng)建更新刪除數(shù)據(jù)，拼接各類數(shù)據(jù)。

外面api提供了各功能的api函數(shù)，api層我只處理了入?yún)?，保證各入?yún)⒌念愋秃戏ㄈ缓髠鹘omodel對應(yīng)的函數(shù)進行進一步的邏輯處理。

const里面存放了各種可能會使用到的常量。在設(shè)計常量存放的時候這次踩了一個坑，最好把有哪幾個可能出現(xiàn)的常量類型分別建立一個類，在類下面寫，而且最好提前分配好他們所屬的數(shù)字區(qū)域。打個比方，我們可能有支出和收入不同的常量需求，千萬不要寫成這種：

應(yīng)該首先確定income里面占用的是1000-1999的數(shù)字 那么expenditure就可以占用2000-2999的數(shù)字 這樣能保證同樣類型的const是連貫的就像這樣：

不要把自己搞得像個精神分裂一樣，遇到了就往里加一項數(shù)字上漲一個。。。。簡直不忍直視＝ ＝。

exception里面存放了各種可能會拋出的錯誤，統(tǒng)一繼承自Excepition類

(二) 項目推進

項目推進的過程中，無非是按照前面設(shè)計好的東西按部就班的一個模塊一個模塊的寫。其實中間也沒有碰到什么特別坑爹的事情，只是把原先的兩個上線步驟拆成了三個，因為發(fā)現(xiàn)前面其實雖然沒有構(gòu)建整套積分支付的東西，但是卻有記錄用戶積分的東西，在用戶評論商品之后會給用戶記錄積分的，這就造成了前面多多少少寫了一些積分的東西，我需要把這些原有的東西分好類重新放回到積分新設(shè)計的積分模塊里面去。這一步其實我在估時間的時候沒有想到的，由于前面寫的代碼比較隨便，導(dǎo)致我遷移起來很費勁，有非常多的依賴滿天飛，多花了很多時間，而且是影響線上的東西不得不小心翼翼，測了又測。總結(jié)了一個經(jīng)驗，先從依賴最少的地方開始拆，拆完一塊就測一塊。這樣一步一步的弄幾乎不會出錯。千萬不要一連遷好幾塊的東西，最后再來一起測，那個時候要是再測出了問題，我相信改起來的難度非常大。你要依次去排查是前面哪個改動導(dǎo)致了這個問題，這幾乎的是不可行的。

遷移的理想狀態(tài)是，所有東西都有單元測試，如果沒對的情況下，跑單元測試都會報錯，你就能及時發(fā)現(xiàn)并切改動?，F(xiàn)實是(好殘酷的樣子)，如果沒有單元測試，你可能需要穩(wěn)健的一步一步來。當(dāng)你把簡單的東西都遷走之后，你會發(fā)現(xiàn)之前那些難以遷移的東西也變成容易遷的東西了。

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

就像第一部分談到的，其實如果時間非常充足和從容，你可能有大把時間來按照我上面說的流程對關(guān)鍵部分進行仔細測試，甚至給每個地方都帶上單元測試?，F(xiàn)實是如果你自己估的項目時間過短，你可能沒有時間來完善測試方面的事情。前提是你的公司里面沒有專職QA,測試幾乎需要你自己完成，這個時候，將測試時間估算進你項目進度顯得非常重要。我這次的測試時間大概占完成項目時間的30％，這個結(jié)果很大部分取決于我還用了不少業(yè)余時間完成項目或進行測試，以及依賴一些以前同事編寫的支付部分的測試，如果全部自己來的話我估計時間至少需要估完成項目時間的50％時間用于測試或者編寫單元測試。也就是說如果你估計這個項目你15天可以寫完，你可能大概需要額外的7天時間用于測試和修復(fù)測試出來的bug，以及自己對代碼二次review。這樣的進度才能保證你代碼的質(zhì)量，以及在上線之后不用提心吊膽是否會被客戶端或者web端的同事找麻煩。

對時間方面的估算，沒有幾個項目的經(jīng)歷是肯定估不準的，在你發(fā)現(xiàn)在deadline之前完成不了項目的時候，一定要向自己的leader說明項目延期，以及因為什么原因?qū)е铝隧椖垦悠?，并且盡快完成項目。所以對項目推進節(jié)奏的把控，可能嚴重影響項目質(zhì)量，既不可以完全沒有壓力和時間上的deadline隨意完成項目，也不可把項目時間卡得過于緊，因為中間除了我上面分析得問題，還又可能出現(xiàn)諸如你需要請假有事，中途任務(wù)的插入。

文章來源：博客園

編輯：云朵匠 | 數(shù)商云(微信ID：shushangyun_com)

<數(shù)商云（m.zhimaihui.cn）是國內(nèi)知名企業(yè)級電商平臺提供商，為企業(yè)級商家提供系統(tǒng)開發(fā)（多種模式電商平臺搭建：B2B/B2B2C/B2C/O2O/新零售等）、供應(yīng)商系統(tǒng)及電商解決方案服務(wù)>