首页广州恒大足球俱乐部 六合特码预测

“遗留代码是传奇!”

2019-07-07

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

或者,如果有些代码失去了所有者,你该怎么办?

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

与永久性的运营成本相比,软件最初的开发成本几乎可以无视。

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

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

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

在一个不起眼的小角落里,有一段默默无闻的小代码。

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

“是吗?”小代码有点伤心地问。

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

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

出品 | CSDN(ID:CSDNnews)

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

“你好,微服务先生,为什么大家那么喜欢你呀?”

狼狈的代码淡淡地说:“当然没人喜欢你了,因为你是遗留代码。”

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

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

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

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

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

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

☞泪目!Linux之父:我就是觉得苹果太没意思!

展开全文

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

原标题:“遗留代码是传奇!”

原文:https://circleci.com/blog/the-little-legacy-code-that-could-a-fable-of-software-ownership/

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

“生产?”微服务回答道,“那是什么?”

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

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

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

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

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

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

作者 | Michael Stahnke

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

以下为译文:

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

下面这些迹象表明代码出现了所有权问题:

何时需要代码所有权?

译者 | 弯月,责编 | 郭芮

“那么,为什么没有专门的团队管理我们?”

“哦,”小代码说,“都有哪些人负责你的工作呀?”

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

由于缺乏软件所有权而引发的问题

小代码突然停下来转身微笑着说:

“你好。你知道为什么人们不喜欢我吗?”

“没有必要当面给我难堪吧。”小代码说。

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