我作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的原创文章，请关注公众号"汪子熙":