Act with Prudence

 

Whatever you undertake, act with prudence and consider the consequences.

                                                                                                                --Anon

     不管你的日程安排在某个迭代刚开始的时候看起来有多么适合， 你总不能避免在某个时候会感受到压力。如果你发现必须在“正确地去做”还是“更快地去做”中做选择， 后者总是更具有吸引力，因为你认为你应该会在将来的某个时间回来将它修正。当你对自己，你的团队，你的客户做这种承诺的时候，你是认真的。但总是那么快就会在另一个迭代中出现新的问题，而你开始将注意力转移到它上。这种工作推迟即所谓的技术性债务(technical debt)，而且它对你并不会那么友好。具体点说，Martin Fowler将其称之为故意性的技术债务(deliberate technical debt)在他的技术性债务分类中，并提出这不应该与inadvertent technical debt(无意中的技术债务)混为一谈。(以下简称之为TD)

     TD就像借贷：你会在短期中获益，但是你必须不断偿还利息直到它被彻底还清。代码中的捷径导致你在添加特性或者是重构你的代码的时候会非常困难。他们就像是缺陷和脆弱的测试用例滋生的土壤。你听之任之的时间越长，它就越发的会变本加厉。到了你必须面临并想办法解决最初始的修正的时候，会有成堆的不那么正确(not-quite-right)的设计选择堆积在最原始的问题智商，使代码更加难以重构和修正。实际上，经常是问题已经变得不可收拾，你必须去修正最原始问题的时候，你才真正回去修正它。但是这个时候，通常的情况是它已经很难更正，因为你没有那么多时间，或者是承担不起那种风险，

     经常有情况是你必须引入TD，以在最后期限之前完成任务，或者是实现某个特性(feature)很小的部分(thin slice)。尝试着不要是自己陷入这样一种境地，但是如果环境和境况确实要求你这样，那你可以这样做。但是(这是一个如此重要的但是)，你必须对这个TD保持跟踪，然后尽快将其还清，不然问题会迅速急转直下。当你真正决定做出妥协的时候，制作一个任务卡，或者是将其记录到你的问题跟踪系统中，以保证它不会被忘却。

    如果你将账务的归还计划到下一个迭代中，TD的影响会是最小的。放任债务不管会是利息不断积累，同时，利息应该被跟踪以保证TD的影响是可视的。这会强调出TD对这个项目的商业价值的影响和伤害，这样合适的提高债务偿还的优先级将成为可能。如何计算和跟踪这些利息是不同的项目而不同，但是你必须去做。

    尽可能快地还清TD。不这样做事非常不聪明的举动。

 

燮羽. 2010.5.21