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越難經驗值越高。

1. 我做這個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的原創文章，請關註公眾號"汪子熙":

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