08:15 到公司 09:16-08:19 整理桌面衛(wèi)生 08:20-08:22 整理簡書內(nèi)容 08:23-08:44 處理金額計算邏輯和測試,修改文檔 08:45-08:49 休息 08:50-09:14 處理單筆和批量金額支付前校驗代碼重構(gòu) 09:15-09:21 休息 09:22-09:35 處理單筆和批量金額支付前校驗 09:36-09:47 深度優(yōu)化項目早會 09:48-10:22 處理深度優(yōu)化測試環(huán)境合并和構(gòu)建 10:23-10:27 休息 10:28-11:52 將代碼合并到pre測試支付回調(diào) 11:53-13:46 午休 13:47-15:29 處理完成支付回調(diào)的問題 15:30-**:**
1.處理金額計算邏輯和測試,修改文檔 2.處理單筆和批量金額支付前校驗代碼重構(gòu),文檔修改 3.將代碼合并到pre測試支付回調(diào) 4.處理完成支付回調(diào)的問題
技術(shù): 1.訂單編號首字母作用到期要不要用到業(yè)務(wù)中,首字母到底應(yīng)該有什么用呢?要不要和業(yè)務(wù)掛鉤呢?如果掛鉤到什么程度呢?沒有答案啊.? ? 2.真是上面隨便一說,累死下面一群人啊,今天感觸非常深刻啊.如果隨意改動基礎(chǔ)業(yè)務(wù)邏輯,很多東西真沒法做了啊.
思考: 1.昨天突然想到的問題,那就是金額計算的展示問題,因為存在發(fā)票費包含在服務(wù)費中的問題,那么需要有選擇的展示,問了沈哥,說自己又查詢了一遍數(shù)據(jù)庫,其實這個問題溝通好了,我處理下,一次性返回就好了啊.體現(xiàn)的問題有2,第一我考慮問題不周啊,同時有個問題,那就是任何人都無法面面俱到的,需要大家溝通協(xié)助的;第二就是溝通協(xié)作的事情,也許沈哥看我太忙了,或者我忙忘記了,所以自己處理的;第三,這個是和江東說的比較多的,就是如果php實現(xiàn)困難,那么我們Java來處理簡單的話,那么Java來處理,如果Java處理困難,那么php處理簡單,那么就php處理,從這一點和江東的溝通很到位的,反正都是為了工作,不一定非要強加給誰去處理的. 2.我有預感,直接數(shù)據(jù)庫修改訂單金額價格,一定會存在非常多的隱患和后續(xù)操作的問題,這個問題并且一定非常難搞的啊,因為這些數(shù)據(jù)是金額的源頭,沒有金額的數(shù)據(jù)流發(fā)生,從源頭的數(shù)據(jù)就不復合規(guī)則,后續(xù)金額計算除非擺脫源頭,使用基本數(shù)據(jù)進行計算,否則一定會出現(xiàn)非常多的問題. 3.郵件問題,發(fā)送郵件的時候自己考慮是否需要別人回復,如果應(yīng)該發(fā)送,不回復,無所謂;如果需要是否應(yīng)該發(fā)送,如果應(yīng)該發(fā)送,那就發(fā)送,不用考慮別人是否回復;如果值得值得發(fā)送,那么就需要進一步思考,是否值得.如果不值得浪費時間,那么就不處理.
業(yè)務(wù)總結(jié): 1.昨日和穆哥,增勛說,金額計算,支付前金額校驗,支付回調(diào)已經(jīng)說明,都以支付訂單以數(shù)據(jù)庫字段使用,目前不使用原始數(shù)據(jù)進行計算,這樣存在的問題已經(jīng)思考過,目前不做處理,因為存在管理后臺修改數(shù)據(jù)的情況存在.同時任何支付方式都不需要計算平臺支付費.都以數(shù)據(jù)庫字段中支付訂單表中字段為主.
