在过去的差不多一个半月时间里，有幸参与了订单列表的翻译工作，这个工作就做一个事情，将订单列表的实现由php语言改为java语言（类似于搬运工的工作）。在这个过程中有一些个人的感悟，沉淀下来作为个人的总结。
个人感悟亦或是总结我觉得主要是分为两大块，一块我称之为项目把控的反思，另一块我称之为技术上的反思。
关于技术改造中项目把控的反思
现状的分析
这里想强调下前人工作的重要性，我参与的技术改造属于二期，所以很多问题和隐藏的坑已经被前人很好的解决了，我们能够站在前人的肩膀上继续前进。
因为有了前人的铺路，至少在两点上我们比较有信心，第一是实际方案的选择上几乎沿用了技术改造一期定的方案；第二是心理上对技术改造过程中能够遇到的困难比较乐观，至少我们能够遇到的问题不会比一期的更多，类似于有点战略上要藐视，战术要重视的意味。
实际执行当中至少技术上我们遇到的困难跟我们预估的比较相近，没有出现预期之外的问题。
跨团队协作问题。
在这个改造过程中，由于依赖的上下游业务接口同样需要由php改造为java的实现，所以这里就需要涉及到跨团队的协作问题。
针对这种跨团队的协作，我们也借鉴了一期技术改造的经验，通过前期梳理依赖接口，友邻团队专人跟进的方针去实施，这个方案的优点在于友邻团队能够在集中的时间窗口内提供服务。
实际过程中还可能遇到前期梳理存在遗漏的依赖接口或者提供的服务接口存在问题，这些都需要与友邻团队保持沟通及时反馈解决，这个过程中可能会零散地贯穿整个过程。
做好应对突发问题的预期
在整个技术改造过程中需要做好应对突发问题的预期，突发问题在实际改造过程指的就是原本已经在线上使用的接口有可能在java中就不好使了。
实际遇到的最大的突发问题就是原本java的服务通过rest协议发布服务在线上使用没有问题，但是一旦转为dubbo调用之后，各种不规范的写法导致的问题就会爆发，主要集中为基本的对象序列化定义缺失，导致部分接口需要重新发布上线。
另外，在开发和测试过程中会遇到一些服务不存在预发环境或者预发环境经常性重启服务不稳定，针对这种问题我们基本上把这类服务直接直连线上，当然这是有前期条件的，那就是我们的服务都是read类型，所以不存在污染线上环境的可能。
及时做好向上管理
这里主要想强调的是对于这类技术改造的项目，前期我们很难有全面的时间评估，而且大部分技术改造都是按照deadline来倒推时间线，时间点大概率是比较赶的，能做到的就是尽量往前赶，保证deadline之前完成。
在保证大deadline的前期下，对于未按照实际排期完成任务的情况，需要及时反馈问题做好向上管理，保证双方得到的信息是一致的。
技术改造时间点的选择
- 对于电商公司，Q3进行技术改造不是一个好选择，特别在双11-12期间，事实证明时间会被各种打乱。
关于技术改造中技术上的反思
翻译和重构的平衡
在改造过程中会自然而然遇到是直接搬运代码还是按照功能重构代码的灵魂拷问，平心而论直接搬运代码有辱程序员的底线，而按照功能重构代码又有时间上的问题，所以建议在两者取个平衡。
在保证时间点的前提下尽量把原来一团麻的代码进行有限的梳理，至少按照功能块拆分下保证条理顺便保证下代码的可读性。
强烈建议在模型和视图(MV)这个原则上，需要在代码上强行进行隔离，不然你会发现后人会在原本视图的基础上耦合进各种模型的内容，导致代码腐化的非常严重。
新技术和新平台的使用
在改造过程中针对具体实现，如果使用新的技术特性能够节省工作量那么强烈建议使用，至少在我们改造过程中java8的stream的语法节省了大量的工作量。
咨询下公司内部是否有新的平台能够帮忙提高自测的能效，如果有那么同样强烈建议使用。
往前多想一步
在保证改造工作完成的前期下，如果有时间能够往前多想一步，考虑到这个业务的迁移有可能导致流量分配的迁移以及带来的影响，可以提前做好方案。
备用的方案方案包括流量分配需要带来的机器扩容或者应用的拆分，其实改造只是第一步，后续带来的问题会引发一系列的问题同样值得深思。
