乐天堂fun88 » 编程知识 » 拯救你的旧代码库,不得不看的11条军规!

拯救你的旧代码库,不得不看的11条军规!

admin 编程知识 203 次浏览 没有评论
程序员精选俱乐部
每个程序员、项目经理或团队负责人的生命周期中至少会发生一次这样的事件:你接手一坨超过百万行代码的系统,原来的程序员很久以前就离职,现在也许正在某个阳光明媚的地方度假,文档(如果有的话)最有可能的情况就是与现有的系统不同步。而你的工作则是带领团队脱离这个混乱。 在经历逃离的本能回应之后,你开始对项目进行了了解,通过你手头现有的东西,失败是大概率发生的事件。但是,公司高层领导是不能容忍项目失败的结果发生。你该如何应对? 拯救你的旧代码库,不得不看的11条军规! 这时,如果能够把这些垃圾代码变成健康的可维护的项目,实际上是非常值得一试的事情。以下是我们总结的改进旧版代码库的一些经验(或者叫军规)。 改进旧代码库的 11 条军规 数据备份 我们很难记得每天修改了哪些东西,特别是配置数据容易受到这种问题的影响。配置通常不会进行版本控制,如果能够进行定期备份,则可以规避很多麻烦。 在开始做任何事情之前,你需要备份所有可能相关的内容,放到一个非常安全的地方,确保不管发生什么情况都不会丢失数据。 构建一个真实的仿真环境 构建一个真实的仿真环境是重要的先决条件,第一步是你确保知道现在正在生产环境运行的是什么,这意味着你能够构建一个软件版本和你的真实环境保持一致,相同的软件环境与二进制版本。 如果你找不到一个方法来实现这一点,假如你提交代码到生产环境,就可能会遇到一些令人不快的意外。确保新的代码在合适环境尽可能地被测试,然后你才会有足够的信心将其运行到生产环境。 上线时做好准备可以随时切换回老的代码,并确保通过日志记录可以了解相关重要内容,以便在后续排查问题时能派上用场。 冻结 DB 修改 尽可能冻结数据库修改,当完成第一阶段的改进,直到团队对代码库有了彻底的了解,遗留代码已经弃之不用时,才考虑修改数据库结构。在此之前任何的数据库修改都可能会导致一些棘手的问题,让你失去并行运行旧系统和新的代码库的能力。 保持 DB 完全不变,你可以比较新的业务逻辑代码与旧的业务逻辑代码,如果所有这些效果都与预期一样,则应该完全没有区别。 编写测试 在进行任何修改之前,编写尽可能多的端到端以及集成测试,确保这些测试能够产生正确的输出,并覆盖所有潜在的情况。 这些测试将具有两个重要功能:一方面,帮助技术在早期阶段清除任何误解;另外一方面,一旦你开始编写新代码来替换旧代码,这些测试将可以更好保护您的系统。 自动化你的所有测试,如果你已经有 CI 的经验则尽快使用它,并确保您的测试运行足够快,以便在每次提交后运行全套测试。 Instrumentation 和日志 如果旧平台仍然可以增加 Instrumentation,在一个全新的数据库表中执行此操作,为你可以考虑的每个事件添加一个简单的计数器,并添加一个单个函数来实现此功能,以根据事件的名称来增加这些计数器。 这样,你可以使用一些额外的代码行实现带有时间戳的事件日志,你将了解到有多少事件导致另一种事件。 举例来说,用户打开应用程序,用户关闭应用程序。如果两个事件导致一些后端请求,那么这两个计数器应该在长期上保持不变,差异是当前打开的应用程序的数量。 如果你看到更多的应用程序打开,而不是应用程序关闭,你知道必须有另一种应用程序结束的方式(例如崩溃)。 这个简单的技巧可以将每个后端应用程序变成一个类似的簿记(bookkeeping)系统,就像一个真正的簿记系统那样,所有的数字必须匹配,确保它们在所有用到的地方没有问题。 随着时间的推移,这个系统的健康监控变得非常宝贵,并且将成为源代码控制系统变更日志的一个很好的伴侣,你可以在其中确定每个错误引入的时间点,以及对各种情况产生影响的计数。 我通常保留这些计数器的分辨率为 5 分钟(因此每小时记录 12次),但如果你的系统有更少或更多事件,则可能需要修改这个时间间隔。所有计数器使用同一个数据库表,因此每个计数器只是该表中的一列。 每次只修改一个点 在添加新功能或修复错误的同时,不要陷入同时改进代码以及修改代码运行平台的陷阱。这会导致很多头大的问题。 平台更改 如果你决定将应用程序迁移到另一个平台,那么请先执行此操作,但要保持一切功能完全一样。你可以添加更多的文档或测试,但不能超过这一点,所有业务逻辑和相互依赖关系应该保持原样。 架构变化 接下来要解决的是改变应用程序的架构(如果需要)。这个时候,你可以随意更改代码的较高级别结构,通常通过减少模块之间的水平链接数量,从而减少与最终用户进行任何交互时代码活动的范围。 如果旧代码本质上是一体的,现在将是一个很好的时机使其更加模块化,将大型功能分解成较小的功能,但是保留变量和数据结构的名称。 拯救你的旧代码库,不得不看的11条军规! 架构修改并不总是可行,如果特别不幸运,那么可能需要非常深入理解代码才能进行任何架构更改。 如果你同时进行高级别更改和低级别更改,至少需要将其限制在一个文件,或最坏情况下限制在一个子系统,以便尽可能限制更改的范围。否则你可能很难调试刚才所做的更改。 低级重构 到目前为止,你应该对每个模块的功能有很好的了解,并为实际工作做好准备:重构代码以提高可维护性,并使代码具备扩展新功能的能力。 这很可能是项目中耗时最多的一部分,文档需要随之进行,在完整编写文档介绍并彻底了解一个模块之前,不要随意更改模块。 这个阶段也可以修改变量和函数命名、修改数据结构,以提高代码清晰度和一致性。记得添加相关测试代码(根据需要,可进行单元测试)。 修复 bug 现在你准备好进行一些最终用户可见的变化,第一件事情将是修复多年来积累在队列中的 bug。 像往常一样,首先确认 bug 仍然存在,然后编写一个测试并修复 bug,你的持续集成和端到端的测试可以帮你避免由于缺乏理解或某些错误而导致的任何错误及外围问题。
义乌奥美编程,转载链接。本文永久链接: http://code.ywbb.com/172.html

发表评论

Go 乐天堂fun88