网站地图 | RSS订阅 老铁博客 - 上海SEO优化|上海网站建设|蜘蛛池出租|站群代搭建
你的位置:首页 » 站群搭建 » 正文

“遗留代码是传奇!”

2019-7-13 9:52:40 | 作者:老铁SEO | 0个评论 | 人浏览

  【CSDN 编者按】只要在软件行业待得足够长,就不可避免会面临一个棘手的问题:修复遗留的代码库。遗留代码是很多程序员眼中的“烦”,那究竟为什么如此“讨嫌”呢?本文以一则寓言为引,写出了遗留代码的产生原因和解决办法——“我们不是遗留代码……我们是传奇。”

  它厌倦了别人叫它遗留代码,它厌倦了被人们遗忘在角落。毕竟,它还在负责一段业务逻辑。然而,尽管它处理了所有的交易,提供了许多价值,还帮助了许多用户,但还是免不了被人取笑。

  小代码很难过。“我是这项业务的支柱!”它大喊道,然而没有人听到它的呐喊声。人们不愿理睬它,甚至不想与它互动。小代码经常听到有人用很刺耳的绰号称呼它。就在上周,有人接到了修改小代码的命令,但是那个人的话深深地刺痛了小代码。

  “我不想碰小代码。它太丑了,不符合我们目前的做法。每次我碰小代码,就会走霉运。”一位团队负责人说。

  小代码伤心地坐在角落里哭泣,然而它没有眼泪。后来,小代码决心振作,它觉得自己需要品牌推广。于是,它开始与其他代码交谈。虽然,小代码和其他代码并不是好朋友,但它们似乎总是在调用它。

  “哦,你好,”微服务回答,一边快速地瞟了一眼小代码,显然它想尽快结束这场对话,“可能是因为我们的目标很容易定义,我有测试覆盖率,而且我很容易部署。”

  “整个团队。他们负责编写、重构,并将我部署到Kubernetes上,然后更新并自动扩展规模。”

  “哇,听起来很有趣。什么是kubernetes?”小代码说,“你合适生产吗?”

  它意识到它正在与“最好的”代码交谈——这些代码在技术上是完美的,但对用户没有帮助性。我们的小代码获得了很多诸如此类的反馈。很多新系统都有新想法,但是小代码的职责是运行业务,过去是,现在是,而且将来也是。

  这个代码库体型庞大,而且好多天都没有刮胡子了。它看起来有点狼狈,但总得来说,它看上去很有智慧。

  “不,不。遗留代码的意思是说,你负责运行业务。你有巨大的影响力。你承担着各种职责……但也意味着,与你愉快地合作的时光也已经随着那些伟大的人一起远去了。人们采用了新的模式、实践和工具。现在我的处境也是同样。”

  “当然,遗留代码从不是贬义词。遗留代码意味着这些代码长期有效,它们辛勤地工作了很长时间,而且在经历了大风大浪以后依然幸存了下来。像你和我这样的代码的职责是运行业务,我们不断坚持完成任务。领导都想要成为历史传奇,代码库也一样。”

  “它们这么说只是因为嫉妒你。这些服务中有多少能见光的?没有你或我,有多少人能够真正完成自己的工作?当然,这本来是他们的本职工作,但通常人们都无法正确地抽象代码。这些服务最终都会成为调用我们的接口。虽然我们是遗留代码,但是没关系,因为我们提供了价值。其他代码库希望发生交易、延迟,但我们拥有健康。”

  “人们喜欢重新组织他们的工程团队。他们会分领域、微服务或子系统。很多时候,在人们的组织结构分裂之前,我们就已经存在了。我们永远在默默无闻的小角落,被人遗忘。但也有一些细心的人会看到我们,无论他们在哪个队伍。”这个很聪明的代码说。

  “嗯。因为我们工作得很好,所以人们忙于处理其他事情,才把我们忘了,是吗?”

  “也不能这么说。人们知道我们的存在。他们知道我们做出的贡献。他们只是想以更新的方式工作。有时他们会投资新技术和工具。我常常在想,究竟哪些产品会投入生产。记住,生产才是我们展示自我价值的地方。”

  “我们不是遗留代码……我们是传奇。”“这就是我们的精神。我们提供价值,也不枉我们来这世上走一遭。我们为此感到自豪。”

  以上是一个童话小故事,但这个故事说明的问题非常真实。请注意,下面来让我们看看为何软件失去了管理员,以及如何才能防止产生没人喜欢、悲伤而又孤独的小代码。

  如果在提交代码后,这些代码就交由别人负责,那么这不叫所有权,这更像是到期的租约。一旦功能、子系统或应用程序发布后,由谁来负责维护?把这些工作推给运营团队或其他不太走运的团队?这可不是维护代码库的最佳方式,因为他们几乎没有领域知识,无法维护基础设施的稳定,或承担起升级和改进的工作。

  通常在我们的行业中,SRE(Site Reliability Engineering ,网站可靠性管理)团队的任务是负责所有损坏的东西。当软件没有一个明确的所有者时,就不得不进入SRE的收容所,久而久之SRE团队就积攒了一堆数字杂物,他们还需要确保系统的政策运行。但这对SRE来说很不公平,有点浪费他们的才华。但是,事情是如何演变到这一步的呢?

  通常,衡量开发团队绩效的指标是新功能的交付或开发速度。然而,他们实际的绩效衡量并非出自这些角度,而且他们也会因为可操作性、可追溯性、保持库更新而得到奖励……基本上,这些都不是功能。由于开发团队不理会维护的责任,那么通常最终这种责任都会落到运营团队身上。运营团队的绩效指标是稳定性和可靠性。他们可能会用牛顿第三定律系统管理法来维护系统,即“只要你不碰系统,它就会保持正常运转。”我们知道这种状态只能维持一段时间,但在此之前,世界各地的运营团队都会如此操作。

  有一句话虽然听起来浅显,但我还是想重点强调一番:你不能在写完代码后就转身离开——但人们总是这么干。

  在功能测试完毕后,团队不可避免地会发生变化,他们需要投身新的项目。而构建好的软件已投入生产,很多人正在使用和依赖这些功能。这些人希望软件持续发挥作用,并常常希望有人改善该软件。但是,很多时候,一旦产品或功能投入使用后,就会被人抛诸脑后。

  这可能是最小化可行产品开发的必然结果:快速交付产品,并快速获得反馈。但问题是我们发现这种模型往往不完整,在收集到有价值的数据并完成反馈循环后,该模型的计划就结束了。但是人们常常忽略的一点在于,那些用来获取反馈的软件现在怎么样了?我们应该从一开始就建立完整的步骤,来防止这种情况的发生。

  规划软件的持续维护性是构建软件的责任的一部分。编写和交付代码很有成就感,但是写完代码后你的工作并未就此结束,真正的工作是持续维护和更新这些代码。

  许多组织使用叠加矩阵模型(Overlayed Matrix Model),例如Spotify的公会或Valves cabals,来为孤立代码项目分配所有权。我们也尝试过,但说实话,我并不觉得这种方式有效。就其本质而言,公会工作不是你的主要工作。因此,你在公会中的表现并不能反映到绩效考核中。因此,这种方法并不能真正解决所有权的问题。而且这种方法还会削弱职责。

  说到底,改善代码所有权的问题关系到设计软件和构建软件的方式。具体来说,软件在设计时需要考虑到分配任务、衡量考核以及监控,比编写正确的软件更高层的目标是,能够验证软件是否能够正常工作。如果想在设计时考虑诊断问题,就必须提前了解开发人员的意向。通常,他们都没有这种意向,除非接到运营的任务,因此,你可以在绩效考核项中加入适当的考察目标和调试目标。

  • 本文来自: 老铁博客,转载请保留出处!欢迎发表您的评论
  • 相关标签:网站源码  
  • 已有0位网友发表了一针见血的评论,你还等什么?

    必填

    选填

    记住我,下次回复时不用重新输入个人信息

    必填,不填不让过哦,嘻嘻。

    ◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。