我即将开始计划我们的代码库的重大重构,我想得到一些问题的一些意见和答案(我已经看到很多关于类似主题的讨论,例如/sf/ 108141/how-do-do-do-working-very-messy-legacy-code, 用于大规模重构的策略,但我有一些具体的问题(在底部):
我们开发了一个复杂的应用 有大约25名开发人员在使用代码库.到目前为止,该产品的总人数约为150年.目前的代码库是一个用ant构建的单一项目.我正在着手的项目的高级目标是将代码库模块化为其各种基础架构和应用程序组件.目前各种逻辑组件之间没有良好的分离,因此很明显,任何模块化工作都需要包含一些API定义并进行严格的解决以实现分离.质量标准很低 - 几乎没有测试,并且绝对没有测试作为构建过程的一部分运行.
另一个非常重要的一点是,该项目需要与活跃的产品开发和发送给客户的版本并行进行.
项目目标:
- 允许跨不同项目重用组件
- 将应用程序与基础架构分开,并允许它们独立发展
- 提高可测试性(通过创建API)
- 简化开发人员的开发环境(减少检出和编译的代码)
我的想法和问题:
- 您对该项目的目标有何看法？你会改变什么？
- 你有这些项目的经验吗？会有什么建议吗？
- 我非常关心缺乏测试 - 因此我无法控制,因为我知道重构过程并没有像我一样破坏任何东西.这是一个问题22,因为这个项目的目标之一是使我们的代码更可测试...
- Michael Feathers的" 有效使用遗产代码 "非常受我的影响.根据它,自下而上的方法是解决我的问题的方法 - 不要首先跳到代码库并尝试修复它,而是通过在几个月内围绕新代码添加单元测试来开始,并看看如何代码(和团队)变得更好,在某种程度上抽象将出现,API将浮出水面,基本上 - 模块化将自己开始发生.有没有人有这方面的经验？正如关于这个主题的许多其他问题所见 - 这里的主要问题是管理上的怀疑."如何按类别进行测试(并花费大量时间这样做)会让我们进入一个稳定的系统？这是一个很好的理论,它在现实生活中不起作用".出售这个的任何提示？