转载

语言栈转型经验谈

以下所谈的属于敏捷开发的一种实践，及早和持续不断的交付有价值的软件。关于 Scrum 开发的介绍可以看：什么是敏捷

语言栈转型经验谈

近一年都在做语言栈的转型，也注意到周围很多公司都在做相似的事情，大概的路径是 Python -> Go -> Java，转型的起因也是有诸多的因素，像 Python 这种开发速度快，执行相对慢的语言更适合中小型项目，加上国内语言生态不够成熟，项目做大了会发现大家一刀切的转到其它语言上，当然这些说的是在做 web 后端方向上，Python 在数据分析和人工智能方向上还是势头很猛的。Go 可能还是因为它能承载的并发更高，性能更好而逐渐流行起来。在并发模型上 Java 原生 API 使用上确实做得不好驾驭，Go 则要相对好用很多。还有在某些垂直领域上，Java 的生态已经很成熟，其它语言栈上则需要自己造轮子，相应对于开发人员的水平要求就会低很多了。

在当前互联网领域，后端研发做 web 主要谈的还是通过抽象和建模来提高项目的可迭代性与可维护性，另一方面谈的是工程实现上的优化和性能上的优化。在这些后面依赖的则是中台来保证的基础服务综合稳定性。

语言栈转型经验谈

在语言栈转型中也踩过一些坑，遇到过一些小问题，当然这些也得益于一个相对靠谱的方案来保证迁移的安全，基于这些经验总结一下，在以后的迁移中使问题可预见和避免采坑。

首先要明确转型的三个流程， 迁移 -> 重构 -> 优化 ，然后看我们人力和时间是否充足，我想大部分情况下是不充足的，按照最短时间交付的原则，我们应该只做迁移流程，也就是说先对原有代码进行语言上的迁移，就是把代码照着抄一遍过来，这样我们可以快速实现交付。重构的目的是来提高项目代码的可维护性和可迭代性，可以放到迁移完成来做。优化则可以是在模块依赖、调用关系、接口字段等方面调整来降低项目的复杂性和提高合理性。

在交付过程中的验证流程 单测验证 -> 测试环境功能测试 -> QA生产灰度回测 -> 灰度验证 -> 完全上线 ，只有功能和单测代码都迁移完才能算代码部分完成，需要优先保证单测行数覆盖率再去保证分支覆盖率，测试环境的功能验证需要覆盖所有 case 来保证大部分问题都被发现，然后进入小范围的灰度验证，之后逐步提高灰度比率直至完全上线。如果是纯读接口则可以直接进行异步校验，就是请求两遍，然后对比差异来不断的发现和修复 bug，直至问题收敛完全解决，期间如果有发现旧逻辑的 bug 也不要管，而是另外去修复。只有通过明确目的和流程并且遵循这个流程做，才能更快的去交付。

语言栈转型经验谈