我在德国作SAP CRM One Order redesign工做的心得

时间过得很快，今天是我到德国工做的第四周，恰好一个月。Prototype的框架已经搭起来了，如今Order可以在新的框架下正常读写，能跑一些简单的scenario，这些scenario对于end user来讲感受不到任何区别，由于毕竟只是DB layer变了。

从下周起就是第二个月，要解决一些open question，好比STATUS, DOCUMENT FLOW这些后台存在SAP_ABA的表，怎么合到新表里去？这些都是接下来要解决的东西。

what I have done in first month

one order这个workstream只有Carsten, Oliver ( IMS guy, one order expert ) 和我，而Oliver只有50%的resource放这个workstream上。POC 4300行左右代码，平均下来按1周5天算天天也就写200行。 属于我名下的一共有46个bug，不过都已经fix了，平均下来我每写93行就要生产出一个bug, 囧。不过我以前和一些同事提过，框架开发的复杂度比应用程序开发要高。

举个例子: 建立新的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，不存盘，再建立第三个product，维护一些数据，存盘。此时我代码里的buffer处理会出问题，存到DB确实有一条item数据，可是已经corrupt掉了。 因为我buffer处理logic有bug, 我花了很大功夫最后发现是第二次被删除的那条数据的内容被错误存到了DB里：

我甚至花了大量的时间来找重现这个错误的办法，由于最初我是偶然的机会发现这个错误，可是没留意个人操做，我花了很长时间在屏幕上进行各类操做，最后才找到能稳定复现问题的步骤，赶忙记录下来：

这个buffer处理的bug直接致使了某天有4个新bug开到我头上：

第二阶段 Design improvement - 被Carsten虐

第一阶段，也就是前半个月，我加了不少班让one order可以在新框架下跑起来，而后进入后半个月，也就是第二阶段，对Design的不断改进。

你们都知道老的One order，header和item的administration信息都是存CRMD_ORDERADM_H和CRMD_ORDERADM_I, 而后其余的order节点，每一个节点都有1张表，这些表总共有1368张，每次你保存的时候，不一样的数据进不一样的表。

如今新的design下，全部这1368张表都不要了，全部的数据都往新的Header和item塞。怎么弄？Carsten在我来以前remote和我沟通，说他有一些draft idea，但不sure是否真的能work，须要我把这些idea变成能够运行的代码，run起来以后走一步看一步。Carsten的draft idea很粗，没有实现细节，所以我有充分发挥的空间。

第一阶段个人框架搭起来以后，我自觉得实现的很精妙，代码量又不算太多(2000多行)，又可以工做，我自我陶醉了。

第二阶段咱们天天上午有半个小时的sync meeting，下午有ad hoc的meeting。 上午sync meeting的agenda: 把当前我写的POC代码分红若干块，天天review一块

1. review昨天那一块的rework结果
2. review今天应该看的那一块

也就是说，这半个小时是咱们三我的坐在一块儿，经过看个人POC代码来改进design。原本是我把代码打到大屏幕上一行行解释这些代码作什么事情，可是实际根本不须要，Carsten看代码速度很是快，反应速度也很快(也多是我代码可读性实在不错)。我代码质量没任何问题，我自认为算一流，Carsten却天天都能找出须要rework的地方，这些须要rework的都和design相关，好比这件check不该在method A处作而应放到method B处，某逻辑不该放在class A而应放在class B作。因此我第二阶段天天的流程通常都是: 上午review, 下午rework, 改bug. 改bug的时候，我会增长一些代码，这些新增代码又会成为次日review的input, 周而复始。

我以为这一个月我收获最多的地方，就是能够和Carsten work on the same topic, learn why he disagrees with my design / code. 由于打比方，若是让Carsten给我作one order的training，我想对我不会有任何帮助。Oliver在我到的第一天问我需不须要他给我讲些one order的session，我说no no no，直接开工吧。我天天和Carsten review他都会找出毛病，并且他挑毛病的尺度和评价标准很值得我学习- 有些毛病他会说，你如今这样作，POC没任何问题，之后productive实现再改。有的毛病他则说，你这样不行，必须改。我过后也会暗自揣摩，他作这些判断的依据。

之前Wuji告诉我，他最开始想学编程，可是没任何基础，不知道怎么入门，因此花1400/月找了一位川大计算机老师，每周三天去这位老师家让他给Wuji讲些计算机基础。因此我如今把本身天天作的事情当成一个相似北大青鸟的培训，这个培训天天有T5的Chief Architecture做为个人老师, 可以和我坐在一块儿，就一个具体的项目一块儿动手作，既有纸上的项目设计，又有上机做业，并且这个老师还会认真批改个人做业，这种机会太可贵了。我作的越多，就会有越多的机会让老师帮我批改，我就能学的更多。正由于这样想，我每一个周末哪也不去。

第一副图是我改了无数版的Order save的实现，我以为已经至关不错了，可是今天Carsten review的时候，仍是给出了修改意见，reason就是看起来很简单的single responsibility. 这个原则提及来容易实现作起来难。

两幅图比较起来，看起来个人design代码量更少，更简单。Carsten的更复杂。但这只是表象，实际上个人视线把buffer merge这个框架须要作的事情注入到了One order 模型每一个节点的convert class里去了，就是那个叫convert_1o_to_s4的方法。而One order 模型比方说有200个节点，这些merge的事情就要重复作200次。而Carsten的理由很简单，就是single responsibility，convert class不该该作的事情，不该该感知到的东西，坚定不去碰。 今天我刚才按照Carsten的proposal把整个framework作了refact，结果确实是，改进后的framework代码量更少，由于全部convert class里duplicate的 buffer merge动做都提取到class外面来了，也就是第二章图里那个棕色的method。

Carsten的这个proposal我最初脑子里也曾想过，但我以为若是放到外面，这个method要能handle任意格式的Order node数据，并且须要能检测出Creation, Deletion和Update的任意一种模式，我以为编程复杂度太高，无法给出effort estimation。若是放到convert class内部，那么内部convert class知道本身具体是什么structure，因此structure在convert里可以写死，这样作buffer merge简单得多。所以我作POC就按照简单的实现来作，没想到最后仍是被Carsten callenge了。这个refact让我总结出一条结论，若是是作框架开发，具体实现复杂度不能成为影响design的决定性因素(做为参考能够).

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