关于前端:原来我们的代码就是这样被污染的

41次阅读

共计 2151 个字符，预计需要花费 6 分钟才能阅读完成。

最近 CR 了这样一段代码：

咱们团队的变量命名标准是小写驼峰，然而这里能够看到，一个 http api 接口申请的工具函数的入参却是下划线。这是一个外部我的项目，前后端都是咱们团队开发的。这个我的项目的代码随处都能看到这样的不符合规范的痕迹，而且 屡禁不止。我不禁在想，为什么会这样？

先探索一下这个问题的外表起因，让咱们从底层开始：

DB 表构造依照团队标准，字段名是下划线分隔的
node 服务定义 entity 的时候，间接复用 DB 表构造字段名
service 模块在查问 DB 之后，间接回吐后果，所以 service 类返回的数据结构的变量名也是下划线的
node api 的 controller 通过调用 service 模块的函数，获取数据处理之后，也间接回吐下划线的变量名的数据结构
因为 node api 的接口协议是下划线的，所以 web 页面申请 http api 的出入参也是下划线的，如上图所示
因为 http api 返回的后果是下划线的，而后页面逻辑间接应用，最初，页面逻辑也呈现了大量下划线

这是一段挺长的链路，只有咱们在前面的任意一个环节解决一下变量名的转换，都能防止这个问题，然而并没有。

为什么会这样？略微探索一下这里的深层起因，也是挺有意思的。

首先，我的项目启动时没有严格把控代码品质 。这里的起因有很多，比方我的项目工期紧、次要以实现性能为主、外部我的项目不须要要求这么严格、我的项目启动时是间接 copy 另外一个我的项目的，那个我的项目也是这样写的等等。然而， 这些通通都是借口！我是要负次要责任的。

其次，没有开发同学想过要去优化这里的代码。参加这个我的项目的同学并不是不晓得如何去解决这个问题，但就是没人想要去解决这个问题。大家更多的是抉择“入乡随俗”，他人这么写，我也这么写吧。

最初，Code Review 没有严抓。问题都是越早解决老本越小，如果在晚期咱们就开始严抓 Code Review 的话，说不定就能及时改善这个问题了。

这个案例是 一个十分实在的破窗效应案例，这外面有不少中央值得咱们沉思的。

首先，它会净化整个我的项目。如果咱们在我的项目的一开始就没有把控好代码品质，那咱们的我的项目代码很快就会被净化。最开始的开发同学可能晓得历史起因，天然不会感觉不天然。后续退出的维护者看到我的项目代码是这样子的，就会误以为这个我的项目的代码标准就是这样子的，于是也“入乡随俗”，最终整个我的项目的代码就被净化，破烂不堪。

其次，它会净化依赖的我的项目。比方这里就是 node 我的项目先被净化，对外提供的 api 也受到净化，而后调用这些 api 的 web 我的项目也被净化了。很多时候，api 的接口协议都是由后端开发来定，如果碰到一些缺乏经验的后端开发，前端同学会收到一些很奇怪的接口协议，比方字段命名标准不对立，冗余字段，设计不合理等等，因为前端的话语权较弱的缘故，很可能会被动承受，如果处理不当，前端我的项目的代码就会受到净化了。

最初，它会净化整个开发团队！初创的开发同学就不说了；后续的维护者看到代码是这样子的，不是谬误认知这个我的项目的代码标准，就是谬误认知团队的代码标准；更为蹩脚的是，浏览我的项目源码的其他同学也会受到净化：“哦，原来他人也是这样写代码的”。噩梦由此而生 …

破窗就像病毒一样，疾速并疯狂地净化整个我的项目代码，而后传染给开发团队，最初扩散到其余团队 。这个病毒传染的范畴很广，速度很快，一不留神，整个团队就会失陷。 那咱们应该怎么治疗呢？ 次要有 3 个方向：

首先，加强集体免疫力。造成集体的编码格调，而后保持它，这是治标的良方。良好的编码格调是不会损坏集体的编码效率的，反而会有助于晋升集体的研发效率，次要体现在以下几个方面：

缩小低级谬误
晋升代码的可浏览性，晋升代码的可维护性，从而晋升团队合作效率
造成“肌肉记忆”，晋升编码效率
防止返工，次要体现在蹩脚的设计问题和编码格调抵触问题

其次，做好防护，防止流传。比方咱们这个简略的案例，在整个链路的任何一个环节，都能轻松解决这个问题，这样就不会流传到前面的环节了。很多人碰到一些历史破窗代码时，可能会感觉修复这些破窗老本太大了，那就不要去修复，只须要保障本人写的新代码是良好的，也是一个不错的计划。曾经中毒的人咱们没有能力治疗的时候，起码，咱们能够认真做好防护，防止病毒进一步流传！

最初，隔靴搔痒治疗 。只有千日做贼，那有千日防贼，咱们总是须要想方法治疗这个病，而治病的药方就是重构。这里就不深刻讲了，重构也是个大学问，只须要晓得，越早重构，老本越低，比方在 Code Review 的时候就要严抓这些问题，并跟踪修复状况。

不晓得，你的“免疫力”修炼得怎么样了？