谨慎行动

Act with Prudence

不论你想干嘛,三思而后行——Anon

不管开局多么美好,你都无法避免某些时刻的压力。当“保质保量”和“赶工期”摆在你的眼前,选择“赶工期”意味着你很快会返工。尤其是你给自己、团队、客户作出某些承诺后,就意味着你选择了后者,通常在下次迭代那些赶工导致的问题就会浮现出来,反而导致工期延长。Martin Fowler 在他的技术债分类中把这种现象称为deliberate technical debt(故意的技术债),注意不要和无意的技术债混淆(前者是你和你的团队明知这样做会出问题,还选择这么做)。

“技术债”就像一次借贷:短期内你能从中获益,但必须为此支付利息直到还清为止。代码中的投机(Shortcuts in the code)会导致你的代码很难再增加新功能或重构,也是缺陷和脆弱的测试用例的温床,时间越长越糟糕。当你着手准备修复时最初的问题时,在此之上可能还会面对一堆堆被不太正确的选择(越来越歪)。而事实上,你总是等到bug一发不可收拾的地步才会回来修复它。燃鹅,这早已发展到你承担不起的时间和风险。

有时你必须引入技术债去应付截止日期或一些功能雏形,尽量别尝试这么做,除非情况已经是非做不可了。但是(一个大大的但是)你必须跟踪这个技术债而且要尽快偿还或者把事情迅速平息下来。当你决定妥协时,为了确保这笔债不会被遗忘,一定要在你的系统问题跟踪里加入此项任务清单或日志。

如果你打算在下次迭代的时候就偿还此债务,它的成本是最低的。未偿还的部分应该作为累计利息被跟踪,以使成本可见。同时这也将作为影响项目的业务价值权重,确保偿还的优先级。至于如何计算和跟踪这些利息并加以权衡,取决于项目的细节,但跟踪是必须的。

尽可能还清技术债,否则就太轻率了不是吗。

0%