InfoQ|接手了严重过时的软件,到底是该逐步重构还是摧毁重写呢?( 三 )


为了帮助自己梳理具体的情况 , 你可以把它画出来 。 即对于可能现代化或改进应用程序的不同途径 , 究竟要更改些什么?这里有一个例子:
InfoQ|接手了严重过时的软件,到底是该逐步重构还是摧毁重写呢?
本文插图
实际上 , 变更的性质可能与重写或重构的定义不一致 , 但这没有关系 。 例如 , 上图可能表示了这样一种情况:我们提议使用一组更现代化的技术来重新实现某个服务 , 但同时保持公开的 API 和底层持久层结构不变 。 这是一个较小变更和重大变更的混合体 , 所以应该如何确切地标记它可能仍然不清楚 。 然而 , 重要的是 , 我们已经了解了更深层次的细节 , 这将有助于我们更好地思考和证明这个决定 。
现在我们的准备工作已经差不多完成了 , 但是在我们开始我们的旅程之前 , 让我们先把它们放在一起 , 看看这些不同类型的开发工作是如何适应给定应用程序生命周期的 。 换言之 , 让我们探究一下起源故事 , 以便重写 。
4重写的起源故事 这一切都是从新建开发阶段开始的 , 在这个阶段我们有了一个想法 , 并开始从中构建一个功能强大的应用程序 。 经过数周或数月的不懈努力 , 某些产品最终被投放到“市场”(可能是实际的付费客户 , 或只是一组内部业务用户 , 等等) 。 如果该应用程序很受欢迎 , 它将会在一段时间内处于增强的平衡阶段 , 在此阶段会添加新功能并修复缺陷 。 每个人都很开心 。 但最终 , 技术债会累积起来 , 我们开始看到努力的回报在递减 , 虽然在过去一周的开发足以添加一个全新的功能 , 但现在一周却不足以改变一个按钮的颜色 。
InfoQ|接手了严重过时的软件,到底是该逐步重构还是摧毁重写呢?
本文插图
在这一点上 , 我们可能会质疑是否值得投入更多的时间和金钱 。 此外 , 自从应用程序首次发布以来 , 可能已经出现了一些令人兴奋的新技术 , 我们可能会对如何利用这些技术来使我们的应用程序更具弹性、更易于使用、更具性能等抱有一些宏伟的设想 , 因此我们开始制定重写计划 。 其想法是在短时间内冻结现有系统的开发 , 然后将资源转移到替换系统上 。 我们将首先构建基础(使用更现代化的模式、工具、语言等等) , 然后将现有的功能迁移到该基础中 。 用户只需要安然度过“暂停”(即不需要任何新的更新) , 但当重写系统就位时 , 工作效率就会是之前的两倍(或更多!) 。
虽然这个计划看起来很直接 , 但它掩盖了一些关键的风险:技术、组织和心理因素 , 所有这些因素都会导致重写阶段是极不稳定的 。 随着这一阶段的拖延 , 我们成功替换的机会会越来越渺茫 。 在接下来的文章中 , 我们将探讨一些隐藏在重写工作中的危险 , 以及为什么我们总是不顾这些危险勇往直前的原因 。
原文链接:
InfoQ 读者交流群上线啦!各位小伙伴可以扫描下方二维码 , 添加 InfoQ 小助手 , 回复关键字“进群”申请入群 。 回复“资料” , 获取资料包传送门 , 注册 InfoQ 网站后 , 可以任意领取一门极客时间课程 , 免费滴!大家可以和 InfoQ 读者一起畅所欲言 , 和编辑们零距离接触 , 超值的技术礼包等你领取 , 还有超值活动等你参加 , 快来加入我们吧!


点个在看少个 bug ??


推荐阅读