代码所有权是代码的味道吗？
自从我在有争议的编程观点线程中阅读此答案以来，我一直在思考以下问题： 你的工作是使自己失业。 在为雇主编写软件时，所创建的任何软件都应以任何开发人员都可以选择并以最小的努力理解的方式编写。它经过精心设计，清晰一致地编写，清晰地格式化，记录在何处，按预期每日生成，检入存储库并进行适当版本控制。 如果您遇上公共汽车，下岗，解雇或下班，您的雇主应该能够在短时间内通知您，然后下一个人可能会担任您的职务，接管您的代码，并做好准备。一周之内就可以跑步了。如果他或她做不到，那您就惨败了。 有趣的是，我发现有了这个目标使我对雇主更有价值。我越努力成为可抛弃型产品，我对他们就越有价值。 而且在其他问题（例如这个问题）中也进行了讨论，但是我想再次提出来从更空白的角度讨论“ 这是代码的味道！ ”的观点-尚未真正涵盖深入。 我从事专业开发已经十年了。我曾经做过一项工作，代码编写得足够好，可以被任何体面的新开发人员相对迅速地拿到，但是在行业中的大多数情况下，似乎拥有很高的所有权（个人和团队所有权）规范。大多数代码库似乎都缺乏文档，流程和“开放性”，而这将使新开发人员可以选择它们并快速使用它们。似乎总是有很多不成文的小技巧和黑客，只有非常了解代码库的人（“拥有”它）才知道。 当然，明显的问题是：如果该人退出或“被公交车撞上”怎么办？还是在团队层面上：如果整个团队在团队午餐时外出时食物中毒，而他们全都死了怎么办？您是否可以相对轻松地用一组新的随机开发人员代替团队？-在过去的几份工作中，我完全无法想象这种情况的发生。这些系统充满了诡计和技巧，以至于您“ 只需要知道 ”，以至于您雇用的任何新团队所花费的时间远远超过可盈利的业务周期（例如，新的稳定版本）才能使事情恢复正常。简而言之，如果不得不放弃该产品，我不会感到惊讶。 显然，一次输掉整个团队是很少见的。但是我认为所有这一切中还有一个更微妙和危险的事情-这就是让我开始思考这个话题的要点，因为我以前从未看到过这些术语的讨论。基本上：我认为对代码所有权的高度需求通常是技术债务的指标。如果您“必须知道”系统中缺乏流程，沟通，良好的设计，许多小技巧和小技巧，等等-这通常意味着系统正在逐渐陷入越来越深的技术负担。 但是问题是-代码所有权通常被表示为对项目和公司的“忠诚”，是对工作“承担责任”的积极形式-因此，完全谴责它是不受欢迎的。但是，与此同时，等式的技术债务方面通常意味着代码库变得越来越不开放，并且使用起来更加困难。特别是随着人们的前进和新开发人员的到位，技术债务（即维护）成本开始飙升。 所以从某种意义上说，我实际上认为，如果对代码所有权的高度需求被公开认为是一种工作气味（在流行的程序员想象中），这对我们的职业而言将是一件好事。与其将其视为工作中的“承担责任和自豪感”，不如将其视为“通过技术债务巩固自己并创造人为的工作保障”。 我认为测试（思想实验）基本上应该是：如果这个人（或者实际上是整个团队）明天要从地球上消失，该怎么办？这是否会对项目造成巨大的伤害甚至是致命的伤害，还是我们可以招募新人员，让他们阅读doccos和帮助文件并使用代码几天，然后再返回在几周内完成业务（一个月左右即可恢复全部生产力）？