時間過得很快，今天是我到德國工作的第四周，剛好一個月。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的原創文章，請關注公眾號"汪子熙":

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24475491/viewspace-2637984/，如需轉載，請註明出處，否則將追究法律責任。