時間過得很快，今天是我到德國工作的第四周，剛好一個月。Prototype的框架已經(jīng)搭起來了，現(xiàn)在Order能夠在新的框架下正常讀寫，能跑一些簡單的scenario，這些scenario對于end user來說感覺不到任何區(qū)別，因為畢竟只是DB layer變了。

從下周起就是第二個月，要解決一些open question，比如STATUS, DOCUMENT FLOW這些后臺存在SAP_ABA的表，怎么合到新表里去？這些都是接下來要解決的東西。

what I have done in first month

one order這個workstream只有Carsten, Oliver ( IMS guy, one order expert ) 和我，而Oliver只有50%的resource放這個workstream上。POC 4300行左右代碼，平均下來按1周5天算每天也就寫200行。 屬于我名下的一共有46個bug，不過都已經(jīng)fix了，平均下來我每寫93行就要生產(chǎn)出一個bug, 囧。不過我之前和一些同事提過，框架開發(fā)的復(fù)雜度比應(yīng)用程序開發(fā)要高。

舉個例子: 創(chuàng)建新的service order，維護(hù)header的shipping data，此時order和shipping data的mode 都是creation，然后創(chuàng)建line item，添加product，header的shipping data帶到line item，然后在line shipping data做修改，item的mode變成了change，此時不存盤，直接刪除該item，然后馬上另外創(chuàng)建一個item，繼續(xù)編輯，此時第二個item的mode是creation，前一個item的change mode變?yōu)閐eletion，然后再刪除第二次加的line item，不存盤，再創(chuàng)建第三個product，維護(hù)一些數(shù)據(jù)，存盤。此時我代碼里的buffer處理會出問題，存到DB確實有一條item數(shù)據(jù)，但是已經(jīng)corrupt掉了。 由于我buffer處理logic有bug, 我花了很大功夫最后發(fā)現(xiàn)是第二次被刪除的那條數(shù)據(jù)的內(nèi)容被錯誤存到了DB里：

我甚至花了大量的時間來找重現(xiàn)這個錯誤的辦法，因為最初我是偶然的機會發(fā)現(xiàn)這個錯誤，但是沒留意我的操作，我花了很長時間在屏幕上進(jìn)行各種操作，最后才找到能穩(wěn)定復(fù)現(xiàn)問題的步驟，趕緊記錄下來：

這個buffer處理的bug直接導(dǎo)致了某天有4個新bug開到我頭上：

第二階段 Design improvement - 被Carsten虐

第一階段，也就是前半個月，我加了很多班讓one order能夠在新框架下跑起來，然后進(jìn)入后半個月，也就是第二階段，對Design的不斷改進(jìn)。

大家都知道老的One order，header和item的administration信息都是存CRMD_ORDERADM_H和CRMD_ORDERADM_I, 然后其他的order節(jié)點，每個節(jié)點都有1張表，這些表總共有1368張，每次你保存的時候，不同的數(shù)據(jù)進(jìn)不同的表。

現(xiàn)在新的design下，所有這1368張表都不要了，所有的數(shù)據(jù)都往新的Header和item塞。怎么弄？Carsten在我來之前remote和我溝通，說他有一些draft idea，但不sure是否真的能work，需要我把這些idea變成可以運行的代碼，run起來之后走一步看一步。Carsten的draft idea很粗，沒有實現(xiàn)細(xì)節(jié)，因此我有充分發(fā)揮的空間。

第一階段我的框架搭起來之后，我自以為實現(xiàn)的很精妙，代碼量又不算太多(2000多行)，又能夠工作，我自我陶醉了。

第二階段我們每天上午有半個小時的sync meeting，下午有ad hoc的meeting。 上午sync meeting的agenda: 把當(dāng)前我寫的POC代碼分成若干塊，每天review一塊

review昨天那一塊的rework結(jié)果

review今天應(yīng)該看的那一塊

也就是說，這半個小時是我們?nèi)齻€人坐在一起，通過看我的POC代碼來改進(jìn)design。本來是我把代碼打到大屏幕上一行行解釋這些代碼做什么事情，但是實際根本不需要，Carsten看代碼速度非常快，反應(yīng)速度也很快(也可能是我代碼可讀性實在不錯)。我代碼質(zhì)量沒任何問題，我自認(rèn)為算一流，Carsten卻每天都能找出需要rework的地方，這些需要rework的都和design相關(guān)，比如這件check不應(yīng)在method A處做而應(yīng)放到method B處，某邏輯不應(yīng)放在class A而應(yīng)放在class B做。所以我第二階段每天的流程一般都是: 上午review, 下午rework, 改bug. 改bug的時候，我會增加一些代碼，這些新增代碼又會成為第二天review的input, 周而復(fù)始。

我覺得這一個月我收獲最多的地方，就是可以和Carsten work on the same topic, learn why he disagrees with my design / code. 因為打比方，如果讓Carsten給我做one order的training，我想對我不會有任何幫助。Oliver在我到的第一天問我需不需要他給我講些one order的session，我說no no no，直接開工吧。我每天和Carsten review他都會找出毛病，而且他挑毛病的尺度和評價標(biāo)準(zhǔn)很值得我學(xué)習(xí)- 有些毛病他會說，你現(xiàn)在這樣做，POC沒任何問題，以后productive實現(xiàn)再改。有的毛病他則說，你這樣不行，必須改。我事后也會暗自揣摩，他做這些判斷的依據(jù)。

以前Wuji告訴我，他最開始想學(xué)編程，但是沒任何基礎(chǔ)，不知道怎么入門，所以花1400/月找了一位川大計算機老師，每周三天去這位老師家讓他給Wuji講些計算機基礎(chǔ)。所以我現(xiàn)在把自己每天做的事情當(dāng)成一個類似北大青鳥的培訓(xùn)，這個培訓(xùn)每天有T5的Chief Architecture作為我的老師, 能夠和我坐在一起，就一個具體的項目一起動手做，既有紙上的項目設(shè)計，又有上機作業(yè)，而且這個老師還會認(rèn)真批改我的作業(yè)，這種機會太難得了。我做的越多，就會有越多的機會讓老師幫我批改，我就能學(xué)的更多。正因為這樣想，我每個周末哪也不去。

第一副圖是我改了無數(shù)版的Order save的實現(xiàn)，我覺得已經(jīng)相當(dāng)不錯了，但是今天Carsten review的時候，還是給出了修改意見，reason就是看起來很簡單的single responsibility. 這個原則說起來容易實現(xiàn)做起來難。

兩幅圖比較起來，看起來我的design代碼量更少，更簡單。Carsten的更復(fù)雜。但這只是表象，實際上我的視線把buffer merge這個框架需要做的事情注入到了One order 模型每個節(jié)點的convert class里去了，就是那個叫convert_1o_to_s4的方法。而One order 模型比方說有200個節(jié)點，這些merge的事情就要重復(fù)做200次。而Carsten的理由很簡單，就是single responsibility，convert class不應(yīng)該做的事情，不應(yīng)該感知到的東西，堅決不去碰。 今天我剛才按照Carsten的proposal把整個framework做了refact，結(jié)果確實是，改進(jìn)后的framework代碼量更少，因為所有convert class里duplicate的 buffer merge動作都提取到class外面來了，也就是第二章圖里那個棕色的method。

Carsten的這個proposal我最初腦子里也曾想過，但我覺得如果放到外面，這個method要能handle任意格式的Order node數(shù)據(jù)，而且需要能檢測出Creation, Deletion和Update的任意一種模式，我覺得編程復(fù)雜度過高，沒法給出effort estimation。如果放到convert class內(nèi)部，那么內(nèi)部convert class知道自己具體是什么structure，所以structure在convert里能夠?qū)懰?#xff0c;這樣做buffer merge簡單得多。因此我做POC就按照簡單的實現(xiàn)來做，沒想到最后還是被Carsten callenge了。這個refact讓我總結(jié)出一條結(jié)論，如果是做框架開發(fā)，具體實現(xiàn)復(fù)雜度不能成為影響design的決定性因素(作為參考可以).

要獲取更多Jerry的原創(chuàng)文章，請關(guān)注公眾號"汪子熙":

總結(jié)

以上是生活随笔為你收集整理的我在德国做SAP CRM One Order redesign工作的心得的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。