如何应对遗留代码库——生存指南
如何应对遗留代码库——生存指南
原文:https://medium.com/hackernoon/how-to-cope-with-a-legacy-codebase-survival-guide-6838cde54050
在长期接触充满遗留解决方案的难以维护的单一应用程序的过程中,很难保持良好的态度和动力。本指南是一套 10 个好的想法和主意,如何应对这种情况,并在两个领域提高:个人技能和代码质量。

进退两难
改写或不改写。
这是大多数团队维护和开发一个遗留的不断发展的应用程序时一直在问的问题,或者一直在问的问题。或者至少一直在他们的脑海里。
这有时是一个很难的问题,有时也没那么难。然而,无论如何,这超出了本指南的范围。本指南面向需要使用这些代码的人,即使正在进行重大的重建工作或者已经计划好了——有时我们只是需要有人来处理那些“正在工作”并且是业务的种马的遗留问题。
开始加粗
所以你在一个维护团队,或者你负责一个。或者你只是一只孤独的狼,被一个所有人都害怕的遗留巨石的所有者雇佣。首先——别急,大胆一点。让我们从几个重要的步骤开始,这会给你的探索一个好的方向。
1。使用 VCS
有些人无法想象没有适当的Version Control System的软件开发——他们已经习惯了。你知道吗,现在仍有一些人无法想象像 VCS 这样的东西存在?如果这是你的情况,从一个好的.gitignore文件开始,做你的Initial commit,永远不要回头。
2。尽可能强制格式化
为你的语言和平台选择一些好的格式约定。强迫它,我是认真的。设置一个自动过磅器,尽可能修复现有的代码库。不要忘记修剪空白和添加结束行,如果需要的话,将所有内容转换为UTF。然后在每次代码更改时运行 linter。
为什么要这么戏剧化呢?一个很好的处理遗留问题的工具,通常是膨胀的代码,当没有人真正知道它是如何工作的时候,版本和变化之间的差异,不要浪费资源和你的能力去解决被空白污染的差异。
3。拥抱当前架构
既然你正在读这篇文章,你可能需要继续写一些非常大的代码。大到你不能在一周内重构它。让我们拥抱你所拥有的。
当代码出现时,试着找出当前解决方案的好的方面。这对以后的工作很重要,对你的动力也很重要,不要被当前解决方案带来的困难所压倒。
回答这个简单的问题——这个项目有什么好处?可能是遵循了一些行业标准或者一些常见的模式。我敢肯定,当你看到这些代码时,你已经想到了 10 个更好的解决方案。但是真的有那么糟糕吗?更糟不代表坏。找到好的部分,记下来,你马上就会用到。
4。笑骂
现在是严格的法官。列出所有薄弱部分。维护、安全和进一步发展可能面临的威胁。记住你现在要对那件事负责。要明确目前的状态是什么。
5。找到自己的路
所以现在你应该有好的一面和坏的一面。从零开始一个新项目的 R&D 部门,有一个轻松的说法,它应该在一个确定的未来结束。你不能,你应该精确地知道你现在在哪里,但未来大多是未知的。
你的日常工作可能被短期目标所驱动,而短期目标可能会扼杀任何伟大的长期技术路线图。让我们面对它,不要做一个复杂的“我们不想去的地方”的计划,而是专注于一个日常工作的普通指南。这个指导方针将塑造你的应用和你未来的工作。
在好的部分和坏的部分之间画一条线。选择那些你不能接受的——主要是任何安全威胁或严重的不稳定性。
- 定义构建新要素和更改现有要素的方式
- 然后定义你想随着时间慢慢修改的部分— “每次我遇到这样的实现,我都会用下面的方式替换那个部分”
- 计划对不可接受的部分进行更密集的重建,如果可能的话,为压缩工作安排一个小型项目,以移除最薄弱的部分
大胆地站在每天的基础上
当你做了准备阶段,你需要开始工作。创建你自己的日常工作环境,包括工具和程序,以帮助你和你的团队更加自律,并执行你在高层计划的低层想法。
1。决定工作流程
决定你想要如何处理日常维护和开发。它将与您的组织已经拥有的项目管理系统相关,所以让我们为它添加技术支持。获取一些 VCS 流——例如 GIT 流。决定您想要如何测试、审查和部署发布。对你来说释放是什么。坚持使用一些版本控制模式。如果可能,尝试创建并维护CHANGELOG文件。
2。设置应用环境
很有可能,应用程序已经有了一些生产环境,但是可能没有任何准备、测试或开发环境和工具。
如果有,就像代码库本身一样对待它——利用好的部分,去掉不好的部分。如果什么都没有,那就去创造。从本地开发实例开始,然后是试运行和测试。考虑 CI/CD 并记住 12 个因素应用程序规则。这种训练需要时间。不要着急,如果项目没有完整的框架,它将继续工作得很好。
3。确保监控和报警
如果还没有,添加基本间隔监控来测量正常运行时间。添加错误处理,可能还有一些初始日志记录。你关心你病人,所以确保你知道什么时候会恶化。
设置错误监控时,不要忘记定期检查。一个月一次可能太少了。
4。做代码审查
当团队中至少有两个开发人员时,效果最好。保持代码审查是确保您的维护和开发路线图被执行的最重要的工具,一行接一行,一次一个拉请求。
如果你是一个人,那么使用 diff 的 pull 请求会有所帮助——至少你会清楚地看到你正在应用什么变化,以及哪个变化会导致你用监控工具检测到的令人讨厌的退化错误(总是比赛谁会首先发现错误,你或者用户,或者是你老板的朋友的用户)。
作为每次代码审查的一部分,运行您的 lint 检查和测试套装。
5。提高您的高水平指南
确保你的日常事务可以改善你的高层次计划和路线图。花时间重复你的主要维护和开发指南。做一个回顾,看看哪些成功了,哪些失败了。解决这个问题,并进行自我反思。
每当你遇到有趣的案例时,试着记录下来。这将有助于你的回顾,也有助于那些在你之后接手项目并重新开始整个故事的人。



