因为工程师也是人，他们经常对于自己编写的代码形成一种情感依附，这些冲突在大规模清理源代码树的时候并不少见。一些人可能会提出抗议，"如果我们以后需要这个代码怎么办?""我们为什么只是把这些代码注释掉，这样稍后再使用它的时候会更容易吗?""为什么不增加一个功能开关?"这些都是糟糕的建议。源代码控制系统中的更改反转很容易，数百行的注释代码则会造成干扰和混乱（尤其是当源文件继续演进时）;那些由于功能开关没有启用而没有被执行的代码，就像一个定时炸弹一样等待爆炸，正如Knight Capital的痛苦经历（参考"OrderInthe Mattr ofKnight CapitalAmericasLLC"，文献【sec13 】）。

极端地说，当你指望一个Web服务7×24可用时，在某种程度上，每一行新代码都是负担。SRE推崇保证所有的代码都有必须存在的目的的实践。例如，审查代码以确保它确实符合商业目标，定期删除无用代码，并且在各级测试中增加代码膨胀检测。

"负代码行"作为一个指标

术语"软件膨胀"用来描述软件随着时间的推移不停地增加新功能而变得更慢和更大的趋势。臃肿的软件直观上来看就是不可取的，从SRE的视角中可以更清晰地描述这种情况的消极方面∶添加到项目中的每行代码都可能引入新的缺陷和错误。较小的项目容易理解，也更容易测试，而且通常缺陷也少。从这一观点出发，当我们感觉到增加新功能需求时，应该保持保守的态度。我曾经做过的一些最令人满意的编码工作就是删除了数千行已经没用的代码。

因为工程师也是人，他们经常对于自己编写的代码形成一种情感依附，这些冲突在大规模清理源代码树的时候并不少见。一些人可能会提出抗议，"如果我们以后需要这个代码怎么办?""我们为什么只是把这些代码注释掉，这样稍后再使用它的时候会更容易吗?""为什么不增加一个功能开关?"这些都是糟糕的建议。源代码控制系统中的更改反转很容易，数百行的注释代码则会造成干扰和混乱（尤其是当源文件继续演进时）;那些由于功能开关没有启用而没有被执行的代码，就像一个定时炸弹一样等待爆炸，正如Knight Capital的痛苦经历（参考"OrderInthe Mattr ofKnight CapitalAmericasLLC"，文献【sec13 】）。

极端地说，当你指望一个Web服务7×24可用时，在某种程度上，每一行新代码都是负担。SRE推崇保证所有的代码都有必须存在的目的的实践。例如，审查代码以确保它确实符合商业目标，定期删除无用代码，并且在各级测试中增加代码膨胀检测。

"负代码行"作为一个指标

术语"软件膨胀"用来描述软件随着时间的推移不停地增加新功能而变得更慢和更大的趋势。臃肿的软件直观上来看就是不可取的，从SRE的视角中可以更清晰地描述这种情况的消极方面∶添加到项目中的每行代码都可能引入新的缺陷和错误。较小的项目容易理解，也更容易测试，而且通常缺陷也少。从这一观点出发，当我们感觉到增加新功能需求时，应该保持保守的态度。我曾经做过的一些最令人满意的编码工作就是删除了数千行已经没用的代码。