改善真正糟糕的系统

Question

你会如何开始改进一个非常糟糕的系统？

在您建议创建单元测试和重构之前,让我解释一下我的意思.我可以使用这些技术但在这种情况下这将毫无意义.

实际上系统是如此破碎,它没有做它需要做的事情.

例如,系统应计算它发送的消息数量.它主要起作用,但在某些情况下它会"忘记"增加消息计数器的值.问题是,许多其他具有自己的变通方法的模块建立在这个计数器上,如果我纠正计数器,整个系统将变得比现在更糟.解决方案可能是修改所有模块并删除自己的更正,但是有150多个模块需要如此多的协调才能负担得起.

更糟糕的是,有些问题的解决方法不是在系统本身,而是在人们的头脑中.例如,系统不能在一个消息组中表示超过四个相关消息.某些服务需要将五个消息组合在一起.会计部门知道这种限制,每次他们计算这些服务的消息时,他们会计算消息组并将其乘以5/4以获得正确的消息数.绝对没有关于这些偏差的文档,没有人知道现在系统中存在多少这样的东西.

那么你将如何开始改进这个系统呢？你会采取什么策略？

还有一些额外的事情:我是一个单人军队,因此雇用足够的人并重新设计/重构系统是不可接受的答案.在几个星期或几个月内,我真的应该展示一些明显的进展,所以不能选择在几年内进行自我重构.

一些技术细节:系统是用Java和PHP编写的,但我认为这并不重要.它背后有两个数据库,一个是Oracle和一个PostgreSQL数据库.除了代码本身之前提到的缺陷之外,它的编写和记录也非常糟糕.

附加信息:

计数器问题不是同步问题.counter ++语句被添加到某些模块中,而不会添加到其他模块中.快速而肮脏的修复是将它们添加到缺失的位置.长期解决方案是使其成为需要它的模块的一个方面,以后不可能忘记它.我没有修复这样的问题,但是如果我做这个改变,我会打破其他10个模块.

更新:

我接受了Greg D的回答.即使我更喜欢Adam Bellaire,也不会让我知道什么是理想的.谢谢大家的答案.

Answer 1

1. 扑灭火灾.如果存在任何关键优先级问题,无论它们是什么,您都必须先处理它们.如果必须,请将其删除,使用臭臭的代码库就可以了.你知道你会改进它.这是针对您报告的任何人的销售技巧.
2. 选择一些低悬的水果. 我假设你对这个特定的软件比较新,并且你被重新负责处理它.在代码的相关子系统中找到一些显然容易出现的问题,这些问题不应该花费一两天的时间来解决,并修复它们.这可能涉及重构,或者可能不涉及.目标是熟悉系统和原作者的风格.你可能不会很幸运(在我之前使用我的系统的两个不称职的人之一总是用四个标点符号而不是一个标点符号来修复他的评论,这使得很容易区分谁编写了特定的代码段.),但是你会深入了解作者的弱点,所以你知道要注意什么.例如,与全球状态的广泛紧密耦合与对语言工具的不良理解.
3. 设定一个大目标. 如果您的体验与我的相似,那么当您执行上一步时,您会发现自己处于特定的意大利面条代码中.这是你需要解开的第一个结.根据您的经验,您已经了解了原始作者可能做错的组件和知识(因此,您需要注意什么),您可以开始为系统的这个子集设想更好的模型.如果您仍然需要维护一些杂乱的界面来维护功能,请不要担心,只需一步一步.

泡沫,冲洗,重复!:)

在给定时间的情况下,考虑在接口下方的一个级别为系统的其余部分添加新模型的单元测试.不要通过使用它们的测试在代码中雕刻坏接口,您将在以后的迭代中更改它们.

解决您提到的特定问题:

当您遇到用户正在手动解决的情况时,请与用户讨论如何更改它.如果您在更改时间之前提供更改,请确认他们将接受更改.如果他们不想要改变,那么你的工作就是保持破碎的行为.

当您遇到多个其他组件已经解决的错误组件时,我支持并行组件技术.创建一个计数器,该计数器与现有的计数器应如何工 提供类似的(或者,如果实际的,相同的)接口,并将新组件滑入代码库.当您触摸解决损坏的外部组件时,请尝试使用新组件替换旧组件.类似的接口可以方便地移植代码,如果新的组件出现故障,旧的组件仍然存在.在可以之前,请勿删除旧组件.