破窗理论 VS 童子军军规

首先我们来看“破窗理论”，它是犯罪学的一个理论，该理论由詹姆士·威尔逊（James Q. Wilson）及乔治·凯林（George L. Kelling）提出，认为环境中的不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉。

一幢有少许破窗的建筑为例，如果那些窗不被修理好，可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里定居或者纵火。一面墙，如果出现一些涂鸦没有被清洗掉，很快的，墙上就布满了乱七八糟、不堪入目的东西；一条人行道有些许纸屑，不久后就会有更多垃圾，最终人们会视若理所当然地将垃圾顺手丢弃在地上。

人们总是会有这样的心理，会认为“法不责众”，如果已经有人犯了小错误，那么我再犯些同样的错误也应该没有问题。而且，大家还会不断地试探坏事的底线在哪里，程度会不断加深。

而童子军军规说的是什么呢？大家应该都听说过美国的童子军，小朋友们会一起行军，类似于我们的军训，但要求会很高，而且还需要在野外扎营。其中有一条规定是：当你离开一个宿营地的时候，要让它比你来的时候更整洁干净一点。

当然，提出这条规定的时候，一方面是要让童子军从小养成自律的好习惯，另一方面也应该是处于对环境保护的考虑吧。每次在旅游的地方，看到满地的垃圾，破坏了美丽的风景，心中就充满感慨，哎……

如果把这两个理论结合在一起，就是我们的一句古话：不以恶小而为之，不以善小而不为。如果提升到哲学层面就是，量变引起质变的道理了。

其实，我们整天在说敏捷，说持续改进，不也正是说的这个事儿吗？

敏捷团队最大的特点，就是主动、持续地学习和改进。敏捷开发提倡的也是，小步快跑，快速迭代。

我们并不是要一下子做一个特别大的改进，那更多的都是一种集中式管理，或者说是命令控制性组织里面习惯的方式。很多时候，我们并不需要说自己做的是否是敏捷，只需要团队的每个成员都能够每天为自己提升那么一点点，也能够为组织提升那么一点点，长此以往，就会有很大的进步。

程序员经常要面对已经编写好的系统代码，但这些代码的质量可能会有比较严重的问题，比方说会有很多“坏味道”，再比方说都是没有单元测试作为夹具的遗留代码（请参加《修改代码的艺术》一书）。面对这样的代码应该怎么做呢？

如果我们就“破罐子破摔”，继续把这些质量很差的代码到处使用VC大法（Ctrl-C & Ctrl-V，你懂的……），那么这就是技术债务带来的利息，终究有一天，破窗变成了破小区，我们偿还不了这些技术债务，系统也就破产了。

相反，如果我们能够对待代码采用“童子军军规”，每次签入一段旧代码的时候，能够保证比签出的时候，质量好上那么一点点，那么长时间吸取，代码的质量就会有改观。对于为既有代码编写单元测试也是一样的，如果每次修改一段代码的时候，能够保证修改的代码有相应的单元测试保证质量，更好的话，顺手消除一些坏味道，为相关联的代码也编写一些单元测试，那么积累下来，最经常修改的代码就会慢慢有了单元测试，这对于代码的可读性和可维护性都会有很大好处，而且这真的是“功在当代，利在千秋”的事儿，我们何乐而不为呢？

在敏捷的过程里面也是一样，我们找到好的节奏（从不知道多长时间一个迭代变成两周甚至于一周一个迭代），每个迭代里面我们都会做回顾会议，总结我们的改进项。

大家千万不要小看这个回顾会议，试想一下，如果我们两周一个迭代，那么一年之中有五十二周，扣除掉节假日等特殊情况，至少还有四十周，两周一个迭代，我们可以有二十次回顾会议。如果保证每次回顾会议都能够有两项小改进措施落到实处，那么团队在一年之内就会完成四十项改进。这样的话，一年后的组织和一年之前一定会有非常大的变化啊。

再回到我们的生活之中，就拿码字这件事儿来说，很多人都是先写公众号或者在知乎上回答问题，写一些短文，积累多了就可以出书。就算是写书的人，很多时候也需要做这种刻意的训练，写得多了才能够找到那种感觉，而不是“茶壶煮饺子”的感觉。这同样在于每天都积累一些，能够不断持续改进自己的能力，这样才能够不断写出好的文字来。（这段文字是给我自己的鸡汤，也希望自己能够把这件事儿坚持下去，哈哈哈）

总之，我们要坚持做好的事儿、对的事儿，坚决杜绝一些不好的事儿，那样才能够不断进步，而不是到老的时候被时代所淘汰。