如何防止“破窗效应”的发生？

很多人应该已经知道破窗效应[注1]，这是一个来自社会学（犯罪学）的术语。 破窗效应最早是由社会学家James Q.和L.在一篇名为《注2》的文章中提出的：

“如果房子里的一扇窗户坏了，没人修，其他窗户很快就会莫名其妙地被打破；如果墙上有一些涂鸦没有清理干净，墙上很快就会布满乱七八糟、难看的东西；在很干净的地方，人们不好意思扔垃圾，但一旦地上有垃圾，人们就会毫不犹豫、毫无羞耻地扔掉。”

我们一直叫敏捷开发。 事实上，敏捷开发的一个很重要的目的就是杜绝浪费，防止破窗效应的发生。 如果某件事太困难，就让它变得简单、再简单。 如果这个过程太繁重，那就让它变得更轻、再轻。 努力消除发展障碍，消除破窗环境。 下面我将从软件建设的多个方面来讲述如何防止“软件开发破窗”。

脏代码

如果代码不整洁，后面的人就很难理解。 人们常常对难以理解的代码失去耐心，不愿意了解更多。 如果你不能进一步理解一部分代码，就很难改进它。 这样做的后果之一可能是两点： 1. 这段代码被废弃，然后被重写。 2.直接复制此代码并在其他地方使用。 关于第一点，会带来软件开发的浪费，而且不可能每次都写正确，而且可能会引入新的bug。 关于第二点，大家都知道重复代码是设计腐败的根本原因之一。

如果我们在编写代码时能够不断应用一些原则，我们就能确保我们的代码是可理解的和自描述的。 在开发新功能时，我们不断使用重构方法来保持我们的设计处于良好的状态。 我们可以防止窗户进一步被打破。

测试

没有测试或混乱的测试代码是破坏窗口滋生的环境。

没有测试

如果没有测试，当我们想要重构一段代码时，我们就像走在没有安全绳的钢丝上。 我们害怕失去平衡并从悬崖上掉下来。 这就在我们心里产生了对重建的恐惧阴影，久而久之，我们就不再重建了。 最终的结果和上段提到的一样：设计不断恶化，然后失去控制。

如果有单元测试和验收测试，每次我们进行重构时，我们都可以很快得到测试的反馈。 每当红条亮起时，我们就知道我们已经破坏了一些现有的功能，然后我们就停止了。 去维修吧。 当绿色条亮起时，我们知道现在处于安全状态，可以安心地继续重构。 一切都在我们的控制之下，我们将享受重构。

测试代码乱七八糟

很多人认为测试代码不是交付给用户的产品代码，可以区别对待。 我们不需要花那么多时间思考变量命名和方法命名，也不需要关注重复的代码。 但……

混乱的测试代码与没有测试一样糟糕，甚至更糟。 我们认为我们有测试，但测试给了我们错误的报告，当我们发现我们的重构有多严重时，已经太晚了。 即使测试可以给出真实的报告，如果测试代码很乱，那么添加新的测试就会非常困难，我们会越来越害怕添加新的测试。 随着产品代码的发展，测试代码也需要随之发展。 测试代码越混乱，我们就越难修改测试，使其反映产品代码中出现的状态。 终于，大家决定放弃测试的那一天到来了，我们又回到了没有测试作为保证的日子。

事实上，在某种程度上，测试代码的整洁比产品代码的整洁更重要，因为有了好的测试，我们就可以放心地重构我们的代码，即使我们的产品代码现在很糟糕。 不要害怕，因为有了测试的保证，我们知道我们可以重构过去。 如果我们只有混乱的测试代码，那么重构的机会就渺茫了。

难以测试

可测试性是对代码的衡量。 由于这是一个一般很难实现的准则，如果代码很难添加测试，我们一般会在尝试几次后放弃编写测试的想法。 当我们尝试为一段代码编写测试时，我们发现该代码是单一的，并且与太多其他类耦合。 它需要传入许多重型对象的参数，例如与设备交互的代码和与数据库交互的代码。 这些重型物体相互耦合。 对象很难模拟或检测。 没办法，在进度的压力下，我们不得不放弃了添加测试的想法，那么就如上面那样，代码就像草原上奔跑的野兽，一发不可收拾。

编写可测试的代码很困难，将糟糕的代码改进为可测试的代码尤其困难。 但有一个技巧。 我们可以先编写测试，然后用测试来驱动我们的产品代码。 这样，我们从一开始就得到一个又一个的测试套件，把我们的产品代码牢牢地固定在那里，就像走钢丝时的保险一样。 绳索; 不仅如此，我们还获得了可测试的代码。

测试运行太慢

测试运行太慢这一事实表明耦合太紧。 运行测试需要编译和加载许多模块。 如果运行测试需要 20 分钟，您想要更频繁地运行测试吗？ 如果运行一组测试需要 10 个小时，您希望测试运行的频率是多少？ 运行太慢的测试是第一个被破坏的窗口，如果不快速修复，稍后会破坏更多的窗口。

如果测试运行得太慢，我们就不会频繁运行测试，测试也不会提供即时反馈，那么测试的有效性就会大大降低。 以上主要从代码实践方面讲解了编码中的破窗以及如何防止破窗。 事实上，类似的情况在软件开发的很多方面都存在。

源代码管理

有很多团队由于各种原因而采用很难使用的源代码管理工具，或者仅仅因为供应商的广告来管理，他们采用了看起来很好但没什么用的极其重型的工具。 被工具折磨一两次后，团队成员就会变得恐惧，尽可能推迟提交代码。 提交代码需要足够频繁，甚至有意义的重命名也可以被视为一次提交，这样在代码审查时，只需阅读所提交代码的注释就可以展示代码的演变。 而且，如果把每一次成功都保存下来，我们就有机会在犯错时后悔，也有机会回滚到成功的状态。 虽然人脑非常聪明，但它也很容易出错，尤其是当我们很累的时候。 如果我们小步前进并小步承诺，我们就可以在任何地方停下来。 您还记得那些必须在某个时刻保存当前状态的电脑游戏吗？

有时候并不是工具难用，而是环境难用。 在分布式团队中，网络可能不稳定，远程源代码库经常无法访问，或者提交代码时需要连接VPN然后提交。 久而久之，团队成员就会懒得提交代码。 这样我们就应该使用分布式源代码管理工具，比如Git。

难以整合

代码编写完成并不是开发任务的结束。 您还记得有多少次加班加点去整合产品、解决几个模块之间的冲突吗？ 敏捷强调及时反馈和持续交付。 如果集成一个产品需要几天的时间，我们如何获得及时的反馈？ 如果整合太难，大家都会害怕整合，尽量避免整合。 但是产品最终还是要集成的，所以当到来的时候，大家都在加班，但不是为了写代码，而是为了集成。

如果整合太难，我们为什么不不断整合呢？ 所有团队成员都在同一个分支机构工作。 持续集成服务器不断检查最新代码，运行各种测试，最终构建可用的软件。 我们可以在需要时提供工作软件。

可视化

可视化是管理中的铁三角之一。 许多管理者喜欢使用各种花哨的工具来绘制花哨的图表。 比如用它制定精确到今天的人员计划，用它制定产品的宏伟蓝图。 似乎通过制作这些并发送给大家，我感觉这个项目在我的掌控之中。 事实上，无论多么优秀的软件工具，仍然不如纸和笔。 打开软件需要时间。 随着软件的更新，软件的体积也越来越大。 打开一个巨大的文件甚至需要一两分钟，而且该文档深深地埋藏在计算机文件系统中。 找到文档，打开，几分钟过去了。 别看这几分钟。 久而久之，我们就不再愿意看这些东西了。 我们以为这些事情都在我们的脑海里，但事实上却并非如此。 我费了很大功夫写的需求文档最终变成了一张纸。 当我发现不符合要求时，已经晚了。 为了防止这样的发现，我们不要打破第一个窗口。

虽然进入21世纪，丰田在很多方面仍然沿用原来的看板。 软件开发也是如此。 抛弃那些精美的软件，用最简单的纸笔画出计划、时间表、用户故事，然后贴在墙上，让开发者抬头就能看到。 你不需要把它画得很漂亮，因为它越漂亮，你就越不想去修改它，但软件开发中不变的就是变化，我们必须根据需要改变。

笨重的过程

有些公司有严格的开发、测试和部署流程。 开发人员想要将产品功能部署到测试环境中，需要与很多相关人员进行交互并提交申请表，然后由专人将刚刚修改的这行代码部署到测试环境中进行测试。 首先先不说这个过程中有多少等待和浪费。 光是这个繁琐的过程就让大家望而却步，从而导致对修改的恐惧，甚至好的改进也会遭到抵制。

后记

软件开发的各个方面都像。 不要打破第一扇窗户。 如果损坏，请尽快修复。 否则，软件就会像一样被一一破坏，慢慢变质。

在远远落后于福特和通用汽车之后，日本丰田公司采用了5S精益思维[注3]，成为后起之秀。 这个5S（整理、整顿、清扫、清洁、扫盲）的最终目的是为了防止破窗效应。 。