我在德國作SAP CRM One Order redesign工做的心得

時間過得很快，今天是我到德國工做的第四周，恰好一個月。Prototype的框架已經搭起來了，如今Order可以在新的框架下正常讀寫，能跑一些簡單的scenario，這些scenario對於end user來講感受不到任何區別，由於畢竟只是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，不過都已經fix了，平均下來我每寫93行就要生產出一個bug, 囧。不過我以前和一些同事提過，框架開發的複雜度比應用程序開發要高。

舉個例子: 建立新的service order，維護header的shipping data，此時order和shipping data的mode 都是creation，而後建立line item，添加product，header的shipping data帶到line item，而後在line shipping data作修改，item的mode變成了change，此時不存盤，直接刪除該item，而後立刻另外建立一個item，繼續編輯，此時第二個item的mode是creation，前一個item的change mode變爲deletion，而後再刪除第二次加的line item，不存盤，再建立第三個product，維護一些數據，存盤。此時我代碼裏的buffer處理會出問題，存到DB確實有一條item數據，可是已經corrupt掉了。 因爲我buffer處理logic有bug, 我花了很大功夫最後發現是第二次被刪除的那條數據的內容被錯誤存到了DB裏：

我甚至花了大量的時間來找重現這個錯誤的辦法，由於最初我是偶然的機會發現這個錯誤，可是沒留意個人操做，我花了很長時間在屏幕上進行各類操做，最後才找到能穩定復現問題的步驟，趕忙記錄下來：

這個buffer處理的bug直接致使了某天有4個新bug開到我頭上：

第二階段 Design improvement - 被Carsten虐

第一階段，也就是前半個月，我加了不少班讓one order可以在新框架下跑起來，而後進入後半個月，也就是第二階段，對Design的不斷改進。

你們都知道老的One order，header和item的administration信息都是存CRMD_ORDERADM_H和CRMD_ORDERADM_I, 而後其餘的order節點，每一個節點都有1張表，這些表總共有1368張，每次你保存的時候，不一樣的數據進不一樣的表。

如今新的design下，全部這1368張表都不要了，全部的數據都往新的Header和item塞。怎麼弄？Carsten在我來以前remote和我溝通，說他有一些draft idea，但不sure是否真的能work，須要我把這些idea變成能夠運行的代碼，run起來以後走一步看一步。Carsten的draft idea很粗，沒有實現細節，所以我有充分發揮的空間。

第一階段個人框架搭起來以後，我自覺得實現的很精妙，代碼量又不算太多(2000多行)，又可以工做，我自我陶醉了。

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

1. review昨天那一塊的rework結果
2. review今天應該看的那一塊

也就是說，這半個小時是咱們三我的坐在一塊兒，經過看個人POC代碼來改進design。原本是我把代碼打到大屏幕上一行行解釋這些代碼作什麼事情，可是實際根本不須要，Carsten看代碼速度很是快，反應速度也很快(也多是我代碼可讀性實在不錯)。我代碼質量沒任何問題，我自認爲算一流，Carsten卻天天都能找出須要rework的地方，這些須要rework的都和design相關，好比這件check不該在method A處作而應放到method B處，某邏輯不該放在class A而應放在class B作。因此我第二階段天天的流程通常都是: 上午review, 下午rework, 改bug. 改bug的時候，我會增長一些代碼，這些新增代碼又會成爲次日review的input, 周而復始。

我以爲這一個月我收穫最多的地方，就是能夠和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他都會找出毛病，並且他挑毛病的尺度和評價標準很值得我學習- 有些毛病他會說，你如今這樣作，POC沒任何問題，之後productive實現再改。有的毛病他則說，你這樣不行，必須改。我過後也會暗自揣摩，他作這些判斷的依據。

之前Wuji告訴我，他最開始想學編程，可是沒任何基礎，不知道怎麼入門，因此花1400/月找了一位川大計算機老師，每週三天去這位老師家讓他給Wuji講些計算機基礎。因此我如今把本身天天作的事情當成一個相似北大青鳥的培訓，這個培訓天天有T5的Chief Architecture做爲個人老師, 可以和我坐在一塊兒，就一個具體的項目一塊兒動手作，既有紙上的項目設計，又有上機做業，並且這個老師還會認真批改個人做業，這種機會太可貴了。我作的越多，就會有越多的機會讓老師幫我批改，我就能學的更多。正由於這樣想，我每一個週末哪也不去。

第一副圖是我改了無數版的Order save的實現，我以爲已經至關不錯了，可是今天Carsten review的時候，仍是給出了修改意見，reason就是看起來很簡單的single responsibility. 這個原則提及來容易實現作起來難。

兩幅圖比較起來，看起來個人design代碼量更少，更簡單。Carsten的更復雜。但這只是表象，實際上個人視線把buffer merge這個框架須要作的事情注入到了One order 模型每一個節點的convert class裏去了，就是那個叫convert_1o_to_s4的方法。而One order 模型比方說有200個節點，這些merge的事情就要重複作200次。而Carsten的理由很簡單，就是single responsibility，convert class不該該作的事情，不該該感知到的東西，堅定不去碰。 今天我剛纔按照Carsten的proposal把整個framework作了refact，結果確實是，改進後的framework代碼量更少，由於全部convert class裏duplicate的 buffer merge動做都提取到class外面來了，也就是第二章圖裏那個棕色的method。

Carsten的這個proposal我最初腦子裏也曾想過，但我以爲若是放到外面，這個method要能handle任意格式的Order node數據，並且須要能檢測出Creation, Deletion和Update的任意一種模式，我以爲編程複雜度太高，無法給出effort estimation。若是放到convert class內部，那麼內部convert class知道本身具體是什麼structure，因此structure在convert裏可以寫死，這樣作buffer merge簡單得多。所以我作POC就按照簡單的實現來作，沒想到最後仍是被Carsten callenge了。這個refact讓我總結出一條結論，若是是作框架開發，具體實現複雜度不能成爲影響design的決定性因素(做爲參考能夠).

要獲取更多Jerry的原創文章，請關注公衆號"汪子熙":