为什么团队总在写烂代码？因为 “背锅侠” 根本不存在

CV: Copy & Paste, 复制的意思

草台班子的代码现状：烂却能跑的魔幻现实

做开发越久，你就越能感受到“这个世界，就是个巨大的草台班子”这句话的含金量。很多看似不错的项目，其代码质量和整理设计往往都经不起推敲。

项目中的冗余代码堆砌，不做修改的暴力复制，混乱的逻辑判断，以及令人作呕的文件命名，有时候自己都会不禁发出灵魂拷问：

“这东西能跑起来吗？ 这东西为什么能跑起来？”

可是，没有人一开始就是奔着要把整个项目写烂为目的的吧？ 没有吧！ 但事实就是这样啊，它虽然很烂，但它能用。虽然它能用，但也是真的烂。

Why? Tell me why?

熵增的起点：一次复制、一个else if的蝴蝶效应

它肯定不是一开始就是这么烂的，但随着时间的推移，版本的迭代，似乎有种 力量在不断地将他慢慢往变烂的的方向推。而且随着时间的变长，作为项目的开发者，能够明显的感觉到这种力量越来越强，整个项目的维护成本也越来越高。

而这一些，最初可能只是一次简单的代码复制，文件拷贝，也可能只是在原来的判断逻辑上加了一条 else if 判断语句…

而做这些的原因，可能是一次的需求变更，也可能是新特性的加入，又或是一次错误的代码优化，但最终的结果是一样的–整个项目的复杂度提高了，代码混乱程度也变高了，换句话来说就是，整个项目的熵增加了。

协作困境：通用性在功能优先主义下的妥协

对于一个生命周期还没有走到成熟那步的项目来说，需求点的增加和改动是必然的。而需求点的增加和改动，对原有代码的通用性造成的影响有时候是破坏性的。

而在保证项目功能优先的情况下，开发者往往会选择通过牺牲一定通用性来实现对应的功能。虽然可以通过提升组件抽象层次来保证组件的通用性，但这种设计上下多个层次的改动，工作量会比前者多出很多。

而且对于一个多人协作开发的项目而言，每个人并非对指定组件或者模块负责，而是对某些功能点负责，因此在维护组件通用的积极性并没有那么强。

于是今天少一点通用性，明天少一点通用性，直到有一天，协同开发的同事小明需要使用该组件，但是又涉及到内部改动，不好评估改动对整个项目带来的影响。索性生死看淡，不符就干，直接来个CV操作。

至此，回归到了CV的路上。

伪组件化陷阱：看似复用，实则埋雷

通常，我们对弈是否要将一部分代码抽取成一个模块或者组件的判断还是比较朴素的。

比如，有一段判断逻辑，如果有在3个或3个以上地方出现，这个时候我们就可以考虑将其抽取成一个函数。对于组件也是一样，频繁出现内容相近的表单，也可以封装成一个公共组件。

为什么说这种判断依据比较朴素呢？ 通过一定参数或者内部逻辑适配，使得一个组件能够在多个地方应用，在开发是确实方便了很多。但是，这一操作本身可能就破坏了组件的单一性职责，而且其内部代码将比原来三者中任意一个都负责。

而且，通过简单适配出来的组件，其本身的通用性在复杂多变的需求面前是十分脆弱的。

烂代码的本质：团队责任感的集体缺位

不可否认，一个项目在功能变复杂的过程中，其代码的复杂程度是会对应增加的，代码烂的程度也会增加。但比较可悲的是，我们往往总是把这种结果归咎于事情本身，而不是管理机制和人。

每一位开发者都在关注着自己手头上的功能，“人和代码，有一个能跑就行”，把手头上的功能做完即可。 整个团队中，没有人需要为项目的烂代码兜底，因为它不是烂在自己手上的。

责任感的缺位，导致烂代码就像癌细胞一样逐渐扩散到整个项目。“能用就行，能跑就行，现就这样吧，之前又不是我写的”，这样的思想侵蚀着开发者的责任感。

按理说，每个项目的代码都是有代码审查环节，但在实际操作中，代码审查者往往都是起一个橡皮图章的作用，要么根本没有参与到开发中，要么就是随便瞅两眼后便何如代码。代码审查，本该是把好代码质量的一道重要的门，但却形同虚设，这样又怎能保证代码的质量呢？

组件的通用性差，代码乱复制，冗余代码堆砌…这些烂代码的现象，其实也都是表象。说到底，项目代码的烂，本质是研发团队管理机制和责任感的烂。

先说到这吧，散了散了…