为什么开发框架已经更新了，但是代码依旧写得很差？背景：公司有一个多年的JSP项目，最近有一些模块用Vue重构了。最近在看

背景：公司有一个多年的JSP项目，最近有一些模块用Vue重构了。最近在看重构后的代码的时候，发现代码质量依旧很差。我在这里举了三个典型的案例，详细地分析了代码质量差的一些原因。

典型案例介绍

我们都知道，Vue、React等开发框架的出现，对开发思路有了颠覆性的改变，但公司的JSP项目存在了多年，开发者或者页面设计者的思路已经根深蒂固了，结果就看到了这样的现象：代码是Vue写的，但是用的是JQuery的思路。

典型案例一：Tab切换，展示不同的查询页

上图是ant-design-vue的案例，从这个例子上看，交互应该是这样的：

每个Tab页对应一个组件，并且互相独立，页面初始化的时候，Tab1选中，并且对应的组件内进行了初始化操作。切换Tab的时候，切到哪个Tab，哪个Tab就执行初始化操作。初始化过的组件，下次切到这个组件的时候，可以不重新调用接口（这一点根据实际业务决定，例如每个Tab下都是一个分页的表格，此时切换的时候，不需要重新调用接口，否则第一个Tab内看到第十页的时候，切出去再切回来，应该还是保留在第十页）。

这种交互在JQuery页面是这样的逻辑：

给Tab上绑定了点击事件，Tab下的内容都是通过调用接口，根据接口内容替换HTML。

受JQuery思路的影响，我在Vue的项目里看到了类似的逻辑：没使用ant-design-vue组件，而是自己写了几个按钮，绑定了点击事件，控制一个状态，然后用v-if进行切换DOM内容。

典型案例二：代码复用，但没完全复用

业务是这样的：首页上需要展示多个卡片，每个卡片不完全一样，有的卡片有按钮，有的卡片字号、颜色有一些细微的差别。

JQuery的代码基本上都是这个思路：一个HTML文件包含了所有的卡片的内容，每个卡片的class名称基本上一样，有些特殊的样式再追加一些新的class名字，大致结构如下：

.card-wrapper { /* 样式 */ }
.card-wrapper .card-title { /* 样式 */ }
.card-wrapper .card-body { /* 样式 */ }
.card-wrapper .card-title .card-title-btn { /* A卡片title后的按钮 */ }
.card-wrapper .card-body .card-body.card-body-B { /* B卡片的内容特殊的样式 */ }

总结起来就是，只是复用了一些CSS的class名。

受上面的思路影响，Vue项目的结构惊人地相似，也是一个总的Vue文件，所有的卡片HTML都写进去了，并且CSS也是混在一起的，用的是less/scss，甚至还会有复杂的嵌套。这种代码糅合在一起的，后面遇到改样式的需求，发现代码很难改，因为代码混在一起，改动很容易影响到其他模块。

推荐的思路，其实就是Vue组件化开发的思路。每一个卡片都是一个单独的组件，组件内的内容互不干扰。至于是否要封装成一个通用的卡片组件，这个要看实际情况。这里就需要开发者评估一下，投入产出比，看看封装成通用组件是否值得去做。如果业务明确、UI交互明确，就可以封装；如果时不时要改一下样式或者经常有个性化的改动，维护公共组件的成本就大了，此时复制比复用更高效。

典型案例三：拖动排序操作

针对拖动排序的操作，JQuery的设计思路一般都是这样的：每次拖动排序得到一个新顺序，就把新顺序发送给服务端，这种方式有三个缺点：

1. 每次改变顺序，就调用一次接口，保存了很多中间状态，而中间状态是没有多少意义的；
2. 每次改变顺序，就调用一次接口，让页面操作起来会一卡一卡的；
3. 如果出现网络不好的时候，排完序的内容可能没存下来，用户不知道有没有真的存下来；如果做了回滚操作，用户看到的效果，就是交换两个元素的顺序，一会儿由于回滚操作又自动还原了，体验很差。

这个案例，其实就Vue和JQuery理念上的区别：JQuery注重过程，每一步都记录下来了；Vue注重状态，所有的调顺序的操作都是前端行为，只需要最后提交一下调整后的顺序即可。按照Vue的理念，可以完美解决上面的三个问题，付出额外的代价仅仅是一个保存按钮需要点击，这个是非常划算的。我们上面提到过的投入产出比，在这里也能适用。

如下图，是某软件的拖动排序功能：

这里的拖动操作都是前端行为，用户使用起来非常流畅，操作好了之后再点击左上角的按钮即可完成保存。

作为开发人员，该如何做？

代码质量差，并不全是开发的责任，和需求设计人员也有很大的关系。现在最大的问题是，开发和需求人员常年受已有的JQuery的代码结构和交互方式限制，就算在Vue项目做开发，也仅仅是用Vue的写法把JQuery的代码又翻译了一遍，换汤不换药。

相信自己作为一个有经验的开发者的判断能力。

这个是在上一家公司，我的领导和我说的：你一个有好几年工作经验的前端，不能被后端实习生、产品经理实习生牵着走。你比他们更懂你做的这个产品。因此你觉得设计不合理、接口不合理的地方，就可以把问题拿出来讨论，而不是别人说什么就是什么。

当然，这个还是要看公司实际的情况，不能一概而论。有些公司是真正想做好产品的，也有的公司，只是想把项目完成并交付出去就完事的。不同的目标，当然就会有不同的做事方式，对于你提的问题，领导也会有不同的看法。

技术只是实现业务的工具，但技术也可以反过来指导业务

这一点也是结合我现在的工作环境总结的。现在的工作环境里，需求人员业务化，有时候他们给出的并不是一个产品的详细设计，而是对业务的转述。我们也没法指望需求分析师能详尽地写出每一个交互细节，但我们可以提出前端规范，让业务需求跟着我们的规范走。例如拖动排序，就必须要在操作完成之后点击保存按钮；设计页面之前，先去组件库里看看有没有合适的组件，交互设计尽量向上面靠拢。