传奇私服

“遗留代码是传奇!”3d顶赞传奇

时间:2019/12/2 19:03:26  作者:传奇  来源:www.99cang8.com  查看:102  评论:0
内容摘要:  【CSDN 编者按】只要在软件行业待得足够长,就不可避免会面临一个棘手的问题:修复遗留的代码库。遗留代码是很多程序员眼中的“烦”,那究竟为什么如此“讨嫌”呢?本文以一则寓言为引,写出了遗留代码的产生原因和解决办法—&...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  有些公司让团队承担起的责任。假设你所在的团队负责计划和付款,这时有一个孤立的项目已经上线,尽管与计划和付款无关,但也会成为你们团队的责任。这种方式比公会更有效,因为团队承担的工作就会计入绩效考核中。但有人不喜欢这种方法,因为这种方法有点混乱,任务的职责与团队的核心领域无关。人们喜欢完美的领。

标签:蓝色庄园版本传奇 服传奇 
相关评论
评论者:      
  传奇私服-www.99cang8.com京ICP备11022069号-1
Powered by OTCMS V2.91