技术负债是敏捷开发里的一个词汇，讲的是为了快速解决一个问题，不惜代价，写一个解决方案。燃眉之急虽然接了，却使得代码更加混乱，导致下一次回答新需求的时候，难度更大，耗时更长。就是今天欠下的债，总归要还的。

其实这是把软件开发中遇到的问题，用更加简单易懂的方式，说给非技术人员说的。

然而，往往在很多非技术人员的眼里，负债是一件好事情。贷了款是负债了吧，不过这是一种发展投资的方式，反而会有利于企业的发展。

所以与其用这个可能引起歧义的概念来打比方，倒不如，说得更干脆，跟直接一点，有人便提出了的技术安全的概念。

俗话说，一颗老鼠屎坏了一锅汤。在持续集成中那些随机通过的测试，便是那可恶的老鼠屎。把它们称作随机通过的测试，是乐观的说法，其实它们是一些随机失败的测试。之所以说它们坏了一锅汤，是由于它们飘忽不定的特性，使得程序员对持续集成的结果难以做出准确的判断。

为什么这么说呢？假如，你提交了一段代码，结果测试报错了。如果说你的测试是说一不二的测试，那么你提交的代码肯定是破坏了程序的某些功能。唯一的做法，就是亡羊补牢，提交一个纠正的代码，再运行一次持续集成把所有的测试通过了。可如果这些测试不三不四，它们报错了，有时候，什么都不改，重新运行一遍，就又通过了。可有的时候，是真的错了，必需进行改正。这样一来，这持续集成就成了一个鸡肋，食之无味，弃之可惜。

我是一个比较激进的人，遇到这样的情况，对这些老鼠屎绝不姑息，斩钢截铁的把它们从持续集成的任务中剔除出去。只把那些讲信用的测试留下来，这样一来，虽然测试少了，但至少它们可靠。

可那些随即通过的测试，也不能丢掷一旁，不闻不理，要抓紧时间，把它们纠正过来，把它们从新争取成可以依赖的战斗伙伴。

末了，看看Martin用什么手段来解决这些不确定的测试的。

 

代码审查的时候，我们总会有些争论。痛苦的不是别人的代码写的不好，而是明明知道写的不恰当，却不能有力的说服他，采纳更好的解决方案。

想要说服别人，一定要先说服自己。这是最最重要的一部分。不能过早的下结论。说得太多，却说得不对，久而久之，说出的话，倒出的词，就没什么分量了。所以一定要充足的把握，才可以开始说服别人。

说服别人，也讲究一定的方法方式，不能靠权势，或武力把见解强加与人。

程序，对于一个程序员来说，是他的劳动成果，是他智慧的结晶。如果受到他人的指责，一个程序员的本能反应便是去反驳他人的观点，保护自己的代码。因此，审查别人代码的时候，一定要提建设性的意见，肯定他已写代码的优点，真诚的指出可以改进的地方。相信稍微有点理想的程序员，都希望看到更美的代码。

谈说服力的同时，我觉得谈谈被说服的能力也很重要，一个可以被说服的人，是一个能理性的看待自己劳动成果的人，是一个拿得起放得下的人，是一个开放上进的人。所以受到别人说服的时候，要耐心的听取别人的意见，要有自我否定的魄力。毕竟，代码审查是一个相互的过程，今天审了别人的，明天会被别人审。