我作SAP CRM One Order redesign的一些心得體會

1. 框架開發和應用程序的開發徹底不同。

舉個具體的最近折騰個人例子: 建立新的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，不存盤，再建立第三個project，維護一些數據，存盤。此時我代碼裏的buffer處理會出問題，存到DB確實有一條item數據，可是已經corrupt掉了。 因爲我buffer 處理logic有bug, 我花了很大功夫最後發現是第二次被刪除的那條數據的內容被錯誤存到了DB裏：

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

這個buffer處理的bug直接致使了今天三個新bug：

這就是框架開發的難度。若是是作應用，能夠和PO商量，哪一個客戶吃飽了作這種操做？不支持。可是這些操做從Oneorder框架的角度來看，無非就是create, update和delete三個local buffer的處理罷了，沒有任何理由不支持這種sequence的操做。 反過來講，當developer通過一段時間努力以後可以自如地應對這些挑戰，從這些bug中抽絲剝繭定位問題，給出correction，他的開發能力必定能獲得很大提高。

Developer對於本身編程能力的提高是沒有止境的，我來以前本早已對本身的編程能力很是自信，可是通過這21天的開發，我仍是造了一共40個bug出來。但我最終都fix了他們，每解決一個bug就像之前Wuji老師用遊戲打比方同樣，得到必定經驗值。bug越難經驗值越高。

2. 我作這個POC確實是全神貫注拿出所有精力去作，就這樣都還生產了這麼多bug，確實很燒腦。我每踩一個坑，都會用Jerry : timestamp這種格式寫下注釋. 若是用Jerry作關鍵字搜索，能發現34處坑:

每一處坑趟過以後都增長了我對one order的理解，我把這些bug看成個人一筆財富。好比看這個"this code is ugly"的註釋，點進去看：

確實很ugly，這偏偏就是fix注1裏提到那個buffer更新bug的correction的一部分，加了註釋估計沒接觸過one order的人也看不懂。

咱們拿成都如今已經完成一部分的product harmonization爲例來看：7531行代碼。

而這個POC，作到今天是第21天，代碼量已經超過product harmonization一半了。 請看其中我highlight的這個class，是個人搭檔IMS寫的，他從2010年開始作One order。這個class 到如今寫了921行，就爲了實現一個功能：把partner的數據重新表裏讀出來，放到對應的buffer裏去。爲何有921行？由於buffer的插入頗有講究。

我天天吃飯，騎車的時候都在想這些buffer的東西。這個redesign的關鍵用三個詞來歸納的話，就是buffer, buffer, buffer.

2017-05-15 9:45PM

Model redesign target

One order model redesign主要發生在下圖我畫的黑色方框內的模塊，

下列是須要徹底從新開發, 而非harmonization的內容

1. 新的數據庫表。每一個object type一張表，好比BUS2000116是Service process，有且僅有一張header 表，BUS2000131是sales item，有且僅有一張item表

2. 圍繞這些數據庫表的CRUD API. 簡單的說，就是這兩件事。固然和One order 框架的複雜程度相關。

Scope

其中有9個component是硬骨頭，當前POC已經done了兩個，我用黃色標記。

現有的POC，總體框架已經搭起來了，one order在新的model下已能正常工做，productive實現除了上述提到的7個硬骨頭以外，不存在作不出來的東西和Feature. 固然，根據你們這麼多年的開發經驗，POC不可能100%暴露productive開發的全部問題。

歸納起來講，就是咱們不須要從頭空想一套東西來實現，一切以現有的POC爲基礎，這也是Carsten如今對這個POC很是重視的緣由，每一個方法，每行代碼，在他力所能及能夠抽出時間review的時候，他都不放過。

開發這個事情並非說工做認真負責就能deliver高質量的代碼。打個不恰當的例子，我和Oliver工做都很認真，但咱們仍是生產了38個bug.

和Carsten一塊兒工做一個月，我對他工做風格的體會：一方面，他review你東西的時候很是仔細，很是注重細節，包括我以前舉的例子，好比某方法是在LOOP裏call仍是外面call好，method的參數設置等等。另外一方面，對於什麼纔是正確的design，他每每只給出大方向，overall的思路，但不會具體到能夠直接拿來實現那麼細的粒度，好比他不會告訴你爲了實現他的思路，須要幾個class，每一個class幾個方法，每一個方法參數如何定義。他這種工做方式make sense，由於Chief Architect不須要把事情拆分這麼細。這樣就形成我最近按照我本身的理解去實現他那些思路，因此常常返工，refact.

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