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的原創文章，請關注公眾號"汪子熙":