共计 2384 个字符，预计需要花费 6 分钟才能阅读完成。
框架开发和应用程序的开发完全不一样。
举个具体的最近折腾我的例子: 创建新的 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 越难经验值越高。
我做这个 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 的内容
新的数据库表。每个 object type 一张表，比如 BUS2000116 是 Service process，有且仅有一张 header 表，BUS2000131 是 sales item，有且仅有一张 item 表
围绕这些数据库表的 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 的原创文章，请关注公众号 ” 汪子熙 ”:
