前端开发技术与业务的思考

前言

架构随着业务进行。终点重构也是必然。本思考由@Jinghan Wang授权分享。

正文从这开始~~

首先，这不是一篇所谓的干货，是我自己对最近遇到的一些现象的思考。这几天没什么事情，记录下来，希望以后回看能够有进一步的理解。

我之前做的是一个大型持续迭代的云产品的前端，经过两年的时间，这个前端项目已经从错综复杂难以下手开发，变成了模块化业务功能基本解耦的状态。最近换了新工作，我接触到了几个从零开始的项目，尽管功能比之前做的云产品简单了很多，但修改一个功能往往比原来更加费时费力。

除了对项目的熟悉程度，造成这种差距的原因甚至不在代码层面，而是因为没有根据业务做好功能的拆分和组件化。最终的结果却比找一位有经验的后端工程师开发还要糟糕，相关的功能不在一起，无关的组件在一个文件里，还都导出了，复制粘贴导致大量相同的代码，不知道改哪里等等……尽管项目代码烂成这样，在浏览器里功能却都能用，用户没有不爽，客户感到满意，看似皆大欢喜，直到客户有修改一些小地方，时间飞逝，BUG层出不穷……

如果不换工作，我已经快忘记这种感觉。其实在我刚接手之前的工程时，那个项目也是那样：业务代码野蛮生长，没有任何模块化设计的影子，一个大功能只有一个组件，一个组件上千行，还没有文档注释……BUG修复和功能修改的速度极慢，一些功能模块甚至都已经无法进行调整了，因为里面不知道埋了多少业务逻辑，也不知道埋的业务逻辑做什么……

我从接手2个月都时候就开始一点一点重构这个项目，两年来，借着各种契机总算把大部分的代码都做了拆分，让业务组件分别负责独立的功能，再通过各个业务的数据管理模块串起整个业务逻辑。这一切让我做到高绩效的同时，在以福报闻名的地方远离福报。

让我惊讶的是，做这些事的时候我几乎没有找到任何资料。没有教程来指导如何去做类似的重构，没有人来说明做这些事情的意义，没有人关心过这个事情，甚至都没有人想来抢这个功劳。整个过程中，我参考的资料还是上世纪写成的几本讲重构的计算机书籍，和前端根本没有关系。一个能让团队工作效率提高30%，产出质量提高30%的事情，为什么没有人关心呢？

现在的前端技术文章充斥着各种干货，大厂面试题、各种手写、框架揭秘、前沿技术等等，似乎不说技术就是垃圾，用开源不自研就是技术不过关。我了解过很多号称比Mobx好用的Observable库，没有一个能做到Mobx的功能完整性，就不要说支持了。又有几个人会在实际工作中手写各种功能而不是引个lodash呢？而关系到生产效率和质量的方法和技术却几乎无人提起，在生产中应用的又少之又少，结果是大家面试越来越难，合适的人也越来越难招，进去以后一起996……

前端在大部分产品中都扮演了必要但不重要的角色，负担了大量业务功能，还处在产品技术鄙视链的下游。前端自己现在也一样轻视业务，很多大厂前端都把业务推给外包，外包也经常以做业务为耻，有很多学不到东西的声音。事实真的如此吗？

技术应该为业务服务，作为一名前端开发，既然日常工作很难脱离业务，那么做好业务、提高效率和质量、让项目变得井井有条，一样可以彰显开发人员的技术水平，甚至我认为这才是优秀开发的核心价值。创造出真正有价值的东西，而不是看起来牛逼的东西，才应该是一个技术工作人员的追求。

关于本文
作者：@Jinghan Wang
原文：https://zhuanlan.zhihu.com/p/269061571