一.初识需求阶段
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一遍,消除恐惧心理。