遗产代码梦魇

我继承了一个项目,其中类图非常像一盘意大利面上的蜘蛛网.在过去的两个月里,我写了大约300个单元测试,给自己一个覆盖主要可执行文件的安全网.

在任何特定时刻,我都可以访问我的敏捷开发书籍库:

有效地使用遗留代码

重构

代码完成

C#中的敏捷原则模式和实践

等等

问题是我触摸的一切似乎打破了别的东西.UI类混合了业务逻辑和数据库代码.许多类之间存在相互依赖关系.每次我改变任何其他课程时,都会有几个神课程.还有一个带有大约一半实例方法和半静态方法的突变单例/实用程序类(虽然具有讽刺意味的是静态方法依赖于实例而实例方法却没有).

我的前任甚至认为向后使用所有数据集会很聪明.每个数据库更新都作为存储过程中的参数直接发送到数据库服务器,然后手动刷新数据集,以便UI显示最新的更改.

我有时候会想到他们在处理代码之前会使用某种形式的弱混淆来保证工作安全或作为最后的告别.

是否有任何好的资源来解决这个烂摊子？我所拥有的书籍很有用,但似乎只涵盖了我遇到的一半场景.

听起来你正在以正确的方式解决它.

测试

重构

再次测试

不幸的是,这可能是一个缓慢而乏味的过程.实际上没有什么可以替代挖掘并理解代码试图完成的内容.

我可以推荐的一本书(如果你还没有在"等"下提交它)是重构模式.它面向处于您确切情况的人.

我在类似的情况下工作.

如果它不是一个小实用程序,而是一个大型企业项目,那么它是:

a)来不及修复它
b)超出单个人的能力来尝试a)
c)只能通过完全重写那些不可能的东西来解决

在许多情况下,重构可能只在您的私人时间内尝试,您的个人风险.如果你没有明确要求在日常工作中做到这一点,那么你甚至可能没有得到任何信任.甚至可能被批评为"毫无意义地浪费时间在已经完美工作了很长时间的事情上".

只是继续以之前被黑客攻击的方式进行攻击,收到你的薪水等等.当你完全沮丧或系统达到不可攻击的程度时,找到另一份工作.

编辑:每当我试图解决真正的建筑问题并以正确的方式做事时,我通常会直接从负责任的经理那里得到LOL,他们说的是"我不会对好的建筑有所了解"(尝试过德语翻译).我亲自带来了一个非常糟糕的组件到了不可破解的程度,当然还提前几个月发出了预警.然后他们不得不取消一些承诺的功能给客户,因为它不再可行.没人接触它了......

我以前做过这份工作.我花了两年多时间研究一种非常相似的传统野兽.我们花了一年多的时间来稳定一切(它仍然破裂,但它更好).

首先 - 如果应用程序尚不存在,请将异常登录到应用程序中.我们使用了FogBugz,我们花了大约一个月的时间将报告集成到我们的应用程序中; 它不是很完美,但它自动报告错误.在所有事件中实现try-catch块通常是非常安全的,这将涵盖大部分错误.

从那里修复第一个出现的错误.然后打小战,特别是那些基于小虫的战斗.如果您修复了一个意外影响其他内容的错误,请重构该块以使其与其余代码分离.

无论多么糟糕,都需要采取一些极端措施来重写一个重要的,对公司成功的重要应用程序.即使你获得了这样的许可,你也会花太多时间来支持遗留应用程序,无论如何都要在重写上取得任何进展.如果你做了很多小的重构,最终要么大的重构,要么你的重写基础课真的很好.

从中获取的一件事是,这是一次很棒的体验.这将是令人沮丧的,但你会学到很多东西.