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.
   简单的说，就是这两件事。为什么Carsten估出来940个人天？当然和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. 这样做在POC阶段没问题，但到了productive实现阶段如果还频繁出现这种rework的情况，会影响项目进度和大家的士气。

要获取更多Jerry的原创文章，请关注公众号"汪子熙":