大型系统管理中的技术债务和团队士气

在敏捷测试日2015大会上，Thomas Bradford讲述了他维护一个单体Java系统的经历，该系统测试覆盖率为零，而且有大量的技术债务。InfoQ对他进行了采访，内容涉及他们在系统维护过程中面临的问题，他们积累的技术债务，他们为什么决定采用一种不同的方法以及他们如何提高团队士气。

InfoQ：您能详细描述下你们在维护这个大型Java系统中面临的问题吗？最大的问题是什么？

Bradford：我是后来加入这家公司的。我在2015年年初受聘为工程部门的副总裁，任务是帮助开发人员解决困扰他们将近10年的质量问题。具体地说，就是他们根本无法做到修改系统或者修复Bug而又不引入更多的问题。

InfoQ：您能描述下你们面临的技术债务吗？

Bradford：当前的系统是在一个非常短的时间构建而成的，而且是单体系统。因此，测试覆盖率几乎为零。此外，代码一团糟，满是重复的、长得令人难以置信的方法。它就是维护人员的噩梦。

更严重的是，几乎没有做过任何工作让事情变得可控。Bug交给了卖力的新手处理，而不是导致那些Bug的团队，而团队被推动着“快速前进”，给新手们留下了够他们处理一生的Bug。

InfoQ：是什么让您决定开始采用一种不同的方法？

Bradford：在我同现在的技术负责人交谈的过程中，他们告诉我，他们实际上已经两次重写了他们的产品，每次的结果都类似。所以，我建议采用一种不同的方法，不只是战略上的，而且是哲学上的。

从战略上讲，我知道，维护这个单体Java系统，我们永远不可能还清债务，而且会深陷其中，没完没了，最终我们会发现自己陷入了一个无力发布任何东西的境地，不是因为我们导致系统崩溃，就是因为所有的开发人员在厌恶中离职。

从哲学上讲，我希望开发人员能够从过去多年的积累中脱离出来，尝试采用一种完全不同的方法解决问题，像新手一样。

InfoQ：您采取了什么措施来提高系统的测试覆盖率？

Bradford：简单来说，我们没有采取任何措施。

该系统最初是通过测试自动化来保持可控状态。在我来之前，公司已经采用外包的方式创建了一个Selenium测试套件，用来代替在那之前一直使用的人工测试矩阵。我们还尝试建立了单元测试覆盖率，但主要是使系统最难弄的部分可控。然而，这两个方法都不是最终的解决方案。

真正的解决方案是彻底地重构架构——将单体应用解耦成独立的服务——并采用一个完全不同的技术栈来实现。

InfoQ：您是如何处理团队士气的？

Bradford：我来的时候，团队士气已经非常低落。我不知道还会不会更差。开发人员已经完全败给这个系统了，害怕修改他们的软件，作为一名软件工程师，这是你能经历到的最差的感觉之一了。

不过，情况正在好转。在赋予了信任和自主性后，开发人员正在克服过去的恐惧，挖掘他们的创造性，同时开发出质量比过去高出许多的软件。

InfoQ：对于有大量的技术债务需要处理，而大多数开发人员对于他们的境况又非常不满的情况，您有什么建议吗？

Bradford：技术债务这种东西是可控的，而且必须及早控制。“我们将稍后清理”的主意可能会让产品人员高兴，但现实情况是“稍后意味着永不”。如果你发现自己处于同我们类似的境地，我们的单体系统的内部架构根本无法支撑我们有效地偿还技术债务，那么无论如何都要让公司偿还债务，他们必须决定是否要为了避免组织长远的失败而削减短期的功能输出。大部分公司都希望在商业竞争中生存下来。

作为专业的软件工程师，我们有责任保证我们的工作质量。外部参与者可能会对我们施压，让我们“再快点”或者在质量上妥协，但是，我们不是唯一必须承受那些决定的影响的人。最终，这些决定会回过头来咬组织一口。为质量辩护，高举警告标识，坚持用“正确的”方式做事，这是我们的工作，即使这个了不起的组织没有看到这样做的长期价值。

查看英文原文：Technical Debt and Team Morale when Maintaining a Large System