从头到尾重构饿了么商家App

作为一名优秀的工程师，我们从头到尾完整做一套系统出来，这对我们来说是很有成就感的。这其中有多少磨磨难操，有多少可以分享的经验。现在市面上有很多饿了么商家移动端App，但我们需要一个能满足我们需要、又能让我们成就感得到满足，更重要的是能让我们学到东西。在这个项目开始前，我们对已有的一些App做了调研，发现大家基本上都走的React技术路线。需要控制系统依赖，不能乱加东西，那就基于React来做一个精简版Demo出来。这样做有以下好处：

• 学习。学习饿了么移动端App的功能架构。新的技术栈的优缺点。
• 验证。如果这个Demo做的成功，那我们有把握可以做一套稳定易拓展的饿了么移动端App。
• 工程师成长度。实现饿了么商家移动端App从0到1，这一套体系如果推广，可以接入市面上大部分App。

在做项目时，往往会有一个困境。那就是在一开始的调研中，我们不能明确系统的边界，而是一边做一边学一边调整。原来React来做的，发现一些场景React做不到，那就学新的技术栈。这个过程其实是很痛苦的，因为没有一个明确的边界来明确我们研究的进度，来让我们对这个系统有一个明确的规划。不知道做什么，怎么样做是合理的，怎么样做是正常的。但市面上没有好的可以借鉴的例子，只能从头到尾自己摸索出来一套，只有做到足够优秀，才有新的App可以模仿。

另一个难点，同样是一开始系统规划的问题。刚开始，我们没有考虑到这个App可能需要其他人维护，所以没有写单元测试。但是做了一段时间后，我们发现现存的系统必须要补上单元测试这块，如果不能补，那么任何的改动都非常恐怖，因为测试成本会过大。为了让我们移动端App无论谁来改都不会改错，我们必须补单元测试。

第三个难点，前端重构最需要面对的问题，就是老的路由和需要做的路由的兼容。一做不兼容，我们又要改很多老的界面。如果做兼容，改动的成本又会过大。对这个问题，我们探索了很多兼容的思路，但还是需要大量的额外的工作。

可能有人会质疑这套技术的复杂，App只是为了用户点餐，这个技术栈是否过度？对于初学者来说，的确是复杂的。我们试了市面上其他的技术栈，但那些技术栈不是维护性很差就是不能容错网络环境，不能断网。我们认为，我们现在已经具备了切换到一个新的技术栈的成本，这是因为我们对项目、对这套技术栈都非常熟悉。我们知道，这是一种新的技术栈，要控制系统依赖，不能乱加东西。我们需要一套整体的技术路线。这些已经成为我们的一种习惯，如果新的项目继续用这套技术栈，那么只需要花很少的精力，我们就能复现过去的功能，而且能学的更快。

总体来说，这是一个很有成就感的过程，做成饿了么商家移动端App功能重构之后，我们学到了很多东西，在新的项目中能解决更大的问题，前端架构师这个角色扮演的是越来越顺。