首先 - 你要保持你的注册非常简单,否则维护注册的开销将阻止人们使用它,并且浪费更多的时间而不是实际修复它旨在解决的技术债务......
如果您仍然决定继续,我建议保留一个简单的寄存器,它是一个平面文件/简单数据库/Google 电子表格,其中包含以下字段:
- 模块/组件名称
- 需要修复的内容的描述(您可能有一个类别列表,但我认为这也需要一个文本单行)
- 估计的修复时间(以天为单位)(我倾向于坚持整数天,否则人们会倾向于开始记录琐碎的小事)
- 哪个开发商承担了债务(并提供了修复时间估计)
- 债务是在哪个项目上产生的(任何暗示,哪个项目经理负责)
规则如下:
- 开发人员应该对技术债务保持透明。如果开发人员由于项目压力需要承担技术债务,开发人员应将其添加到日志中,并附上他们估计的修复时间。
- 项目经理对他们产生的技术债务负责(即他们是否迫使开发人员走捷径?)。他们应该能够为总债务增加提供可靠的商业理由,并提出应该采取哪些措施来解决它。
- 如果没有注意到技术债务,那么代码应该是最高质量的并通过任何相关的代码审查。如果记录了技术债务,那么开发人员会获得任何记录的“通行证”(审查可能会有助于考虑债务记录的准确性以及应该采取哪些措施来解决问题)。
- 预计开发人员会对修复时间给出合理的估计。如果他们说重构架构需要两天时间,那么如果他们有两天时间在以后修复它,他们应该不会感到惊讶......
我认为这种方法将创造一个良好的整体动态 - 开发人员有责任保持透明并考虑如何解决技术债务,项目经理/业务负责人必须做出权衡,但很明显债务成本是他们的责任,最好的开发人员和架构师将因完成艰巨的项目而获得赞誉,同时还能控制技术债务。