giveOut 迁移总结

一.初识需求阶段
2020.0528周四接到需求
确定好需求，同时明白该在哪里改，这是第一步，但在此时，实际上我是没有理解到底所谓的实时指的是什么，这也是这项功能里最大的难点。

问vic：
1.新加一种类型的clientAccount
2.对于这种类型的account，所有的trade在verify的时候会去生成一笔相反的trade和tradeEntry（如果新系统也是这样的）
分析： 因为已经实现过一遍了，所以在实现的思路上基本是没有什么问题，所拆解的两步也非常合理，所得到的答案也让我在熟悉新系统时非常迅速。
这个时候的问题在于，虽然已经熟悉了fourEyeCheck的两步，但对具体的实现思路还是不清楚，特别是代码在重构后，将很多信息都放在了一个大字段里，这种实现可拓展性非常好，但在初次理解的时候不是很确定。

二.实现的第一步，生成反向trade
这里分析大于工作，我真正写的代码反而非常少，主要是确定功能点放置的位置。
1.放在trade的创建时，理论上来说要走跟trade完全一样的实现过程。
2.放在trade真正进入业务的时候，也就是我们常说的fourEyeCheck。

这个时候我只想到了trade的创建，没有考虑过删改的情况，所有的实现都是在add下完成的，在原始代码中，我也注意到了有cxl和rebook的存在，真正的理解却是另外一回事。
思考过后，我觉得实现在verify里更加简单，而且改的代码会更少，只要写的代码足够通用，完全可以处理多种情况。

首先我做的实现是基于原来的接口的verify的工作的拓展，因为要做到实时，而且对于新生成的trade，本质上只是在往数据库里写入一笔trade，哪里有那么多东西可以问，两步里面缺了一步，就缺了，在其他地方补上不就可以了，在将代码的处理看清楚之后，自己写一遍有什么难度？
有一个问题，我在问过之后，稍作思考，在代码中只是加入了两行就将我的功能实现了，就这？

反思：
很多不必要的考虑实际上是没有道理的，我在名义上是一名有很多年开发经验的developer，就不应该因为这种小事情而烦恼。
特别是在实现过程中，对一些细节的处理，比如空指针，比如常见的业务情况，都应该包含到，但我只考虑了自己所更改的，将很多错误的处理情况都交给我的同事来发现，这很不好，一来暴露了我逻辑思维能力确实很薄弱，二来，缺乏足够的思考也会丧失很多业务上进一步深入理解的机会。

三、枚举类的迁移
枚举到底应该放在哪里？
放common包里，这个问题的回答如果是这个，那就会牵扯到另外一个很严肃的问题，到底什么东西应该放在common包里，所有的枚举都往这里塞到最后会形成一个无法控制的怪物？
项目开始初期这么干没有人管你，但在一个日趋成熟的项目里，这样的代码十有八九是要进入重构阶段，我司目前就处于这样一个状态。

枚举放在common包里实际上是有一定的合理因素，因为我们所需要的枚举在微服务阶段通常不是只在一个模块要用到，为了避免C+V的悲剧发生，一个合格的开发通常会想到common包。
但在最后的执行阶段，往往只有20%是被其他多模块频繁使用的，大部分只是在一个模块里使用过之后，再被编译进其他模块吃灰。
这个时候，这部分牺牲的空间来换取的代码整洁性到底是否值得，就非常有必要深入思考了。

四、将trade的所有接口debug一遍，消除恐惧心理。