“你写它；你拥有它。”这是我曾经工作过的一个软件工程部门的哲学。确保对任何编写的代码负责是一个伟大的哲学。
但说起来容易做起来难。
代码所有权，虽然听起来很简单，但随着时间的推移也很容易无人看管。它的后果是巨大的。代码将变成意大利面条，无法维护，很快就会成为遗留的一部分$#!+，没有人能弄清楚它是如何工作的。
每一段代码都是由某人编写的，所以编写者就是所有者，不是吗？
这是一个非常简单的观点。它只适用于一个单独的项目或一个小项目的小团队。
实际上，最重要和最成功的项目，即使它们从小规模开始，也会经历不同的阶段，将引以为豪的闪亮代码变成令人恐惧和鄙视的可悲的神秘代码。
要知道这是怎么发生的，下面是一个项目变得丑陋的代码演变的七个阶段。
1. 出生
开发人员开始了一个具有深思熟虑的架构和干净的代码结构的全新项目。这是一个足够小的项目，单个开发人员可以理解整个流程和集成。
一个人基本上拥有代码。
代码为主要开发人员所熟知并拥有
2. 成长
我们开始有更多的开发人员为代码做出贡献。也许是一个由 3-5 名开发人员组成的团队。我们有同行代码审查。我们有代码配对。每个人都理解代码的所有部分。我们有一个主要的首席开发人员决定遵循的惯例，干净一致。
团队基本上拥有代码。
代码为团队所熟知和拥有
3. 可重用性
随着项目中添加更多功能，理想情况下，我们不想重写所有内容。我们尽量重用。我们使用诸如面向对象继承之类的方法，将公共代码重构为一些公共类。
每个开发人员都拥有自己的部分功能，但都拥有公共层。每个人都喜欢使用公共层，但人们尽量避免修改它，因为它也可能涉及更改其他人的代码。
没有人拥有公共代码。随着时间的推移，对通用代码的理解逐渐淡化
4. 联合
鉴于它只有一个由 3-5 名开发人员组成的团队，我们没有足够的开发人员来处理所需的所有功能。企业决定从其他项目雇用临时承包商或借用其他项目的团队成员来处理这个不断增长的项目，以满足眼前的项目需求。
后来的代码在技术上仍然属于团队所有，但团队并不编写所有代码。团队成员忙于其他功能，无法完全拥有联合代码。承包商或借用的团队成员后来离开，留下部分代码。
联合代码已完成但未拥有。不过，团队最终必须拥有联合代码，但不能完全理解它。这是因为他们还有其他正在开发的功能，因此部分理解了联合代码。
5. 自动化
一位聪明的开发人员有了一个想法，可以在没有更多开发人员的情况下进一步加快工作速度。他们看到了一些可以自动生成的样板和常见模式。为了简化自动化过程，他们开发了一种复杂的算法代码生成器，用于生成代码样板代码。
没有人需要拥有生成的代码，因为它是“精心生成的”。随着时间的推移，开发人员会使用它，但不知道它在内部如何运作，因为“不需要”。聪明的开发人员拥有代码生成器……但要等到很久……（见下文第 6 阶段）
自动化在刚开始的时候很棒。但是生成代码的用户会慢慢淡化他们对正在发生的事情的理解。
6. 过渡
聪明的开发者很聪明，找到了一份更好的工作，然后继续前进。其他一些团队成员也继续前进。也许该组织进行了重组。队伍缩小了。管理层决定雇用新人来填补一些空缺职位。在原来的团队发生变化并加入新的团队成员之前，发生了几次过渡迭代。
团队“拥有”的代码很多，但没有一个拥有归属感。他们中有一半知道一些代码，但绝大多数都留在那里，仅根据“需要”的基础知识进行学习。对它的任何代码更改都只是“补丁”，因为他们试图避免更改任何“原始”内容，因为没有人知道它是如何工作的。
如果没有适当的传递和足够的时间来理解代码，那么转换对代码的影响最严重。不编写原始代码的新开发人员感觉与代码有距离。最糟糕的是没有人可以轻松理解复杂的代码生成器。
7. 迁移
一段时间后，每个人都讨厌在原始代码库上工作。有人建议我们应该重写整个应用程序。此外，还引入了一个新的技术栈。因此，我们还需要转向新的技术栈。
然而，企业明白完全重写是一个很大的风险，因为该应用程序已经在生产中得到广泛使用。它无法承受需要时间的完全重写，并且不能保证与现有应用程序一样工作。
因此，决定是慢慢评估如何在保持“遗留代码”存活的同时慢慢迁移到更新的系统。旧的“拥有”代码现在变成了“烫手山芋”，每个人都尽量避免接触它。
每个人都喜欢跳槽并开始使用新的代码库。旧代码现在是一个每个人都试图避免的鬼屋
正如您最后看到的那样，开发人员现在不喜欢处理原本打算增长和扩展的原始代码。
从上面来看，问题似乎是由“可重用性”、“联合”、“自动化”和“转换”引起的，但它们并不是问题的根本原因。
基本问题都归结为一个普遍问题，“随着时间的推移，代码所有权的意识逐渐减弱”。
代码所有权意识如何恶化？
正如我们所见，一切都开始顺利。但是随着时间的流逝，事情会变得越来越糟，并呈螺旋式下降。以下是几个原因：
1. 不断增加的功能
只添加和添加功能而不删除任何功能的软件是一个定时炸弹。我们希望开发人员能够不断创建越来越多的新功能，同时仍然拥有他们曾经为余生编码的其他旧功能。
旧的功能很快就会变得陈旧，因为原始编码人员可能“很长一段时间”都没有接触过代码，因为他们正忙于开发新功能。虽然人们仍然热爱代码并拥有主人翁感，但真正拥有的东西是有限度的。
2. 每个人都拥有它 = 没有人拥有它
这发生在公共代码中。如果没有人或团队监督公共代码，很快，它要么变成：
一座鬼城——没有人愿意对其进行更改，因为任何更改都可能会不小心踩到其他功能的脚趾上。很快就没有人知道它在里面是如何工作的。
狂野的西部——也就是说，代码将变异为非通用的，每个团队都制作了他们特殊的特殊钩子和非通用的 API。很快，它变得混乱。
3. 编码但不拥有它
一些组织喜欢有一组开发人员从一个项目到另一个项目来临时支持每个项目并转移到另一个项目。这个想法是在多个项目之间共享资源。
虽然这听起来对组织来说“业务友好”，因为资源是共享的，但挑战在于，谁最终将拥有他们编写的代码？
与硬件产品不同，软件产品是永生的，需要不时更改以确保它得到很好的理解和维护。但是，如果只是“临时”拥有此类代码，它很快就会变得陈旧。
4. 化繁为简
为了帮助加速编码，有时开发人员构建复杂的
避免样板代码的代码生成器
旨在简化其使用的基类或函数
这些都是伟大的举措，可以帮助提高生产力。成本不在于构建它，而在于维护它。由于它很复杂，维护它的成本也可能很高，而且知识的转移并不容易，而且经常被忽视。
很快，没有人会了解它是如何工作的，也没有人愿意触摸它。
5. 我们不会一直都在
几乎可以肯定，代码的原始开发人员不会继续参与该项目。他们要么跳槽到另一个组织，更高的职位，要么由于公司重组。
通常，整个开发团队会在几年后发生变化。如果没有适当的过渡计划，新一批开发人员很可能会：
也看不懂代码
对代码没有任何依恋
对于应该如何编写代码有不同的偏好
由于上述所有原因，当前代码库的主人翁意识可能会恶化
如何保持良好的代码所有权意识？
为了确保由个人或团队进行适当的所有权管理，以下是一些建议的注意事项：
1. 对共享所有权说不
不应将任何代码保留为“共享所有权”。如果我们想要普遍共享一些通用代码，它还应该有一个开发人员或一个完全拥有它的团队。
所有者必须维护代码健康，这是贡献代码的指导原则（拥有的代码仍然允许其他人贡献，就像任何开源代码一样）。
2. 边界清晰、自治
代码归属应该用明确的边界清楚地分开：包、模块或存储库。这避免了歧义，也更容易构建管理所有权的系统。这也确保代码始终在开发人员或团队可管理的范围内。
虽然理想情况下，我们希望代码之间具有尽可能多的一致性（例如，使用相同的语言），但我们应该为每个代码所有者提供决定其结构的自主权。这种灵活性使代码所有者感到更有能力编写代码并热情地拥有它，并且将来可以根据需要更轻松地改进代码。
3. 代码正常运行，工作仍未完成
代码旨在改变……不断。它需要不断的维护和改变。一段时间（例如，1-2 年）无人看管的代码往往会过时和陈旧。总有一些东西需要不时地改变和改进（例如，库升级、重构等）
为确保代码始终更新，应始终为代码的改进分配时间，而开发人员则致力于其他功能。也许是代码重构、改进测试以及合并更新的开发实践。
4. 代码删除是健康的
鉴于每个代码都拥有并需要不时为其大修分配时间，因此每个开发人员只能拥有一定数量的代码。
为确保代码可维护，除了添加新功能和新代码外，企业还应考虑删除不再有影响的功能。此类删除将有助于减少需要维护的代码。（这也是为什么清晰的功能代码分区对于更轻松地删除功能至关重要的原因。）
如果我们必须在不淘汰任何功能的情况下增加功能，我们可能需要考虑招募更多的开发人员。代码维护不是免费的。
5. 自动化不是免费的
自动化是一开始比较有趣的软件开发之一。从事这项工作可能具有挑战性，但它会带来很多成就感。
实际更重的成本后来才出现——它的维护。我们需要确保有人不仅拥有它，而且完全理解它。这是为了确保可以解决将来需要的任何问题或增强功能。对于不知道自动化代码上下文的后续所有者来说，这样的工作通常是令人生畏的。
自动化，虽然看起来一旦完成，就可以神奇地提高生产力，但应该不时地发展以确保它得到良好的维护。后者的成本有时比初始成本更重。因此，在进入之前需要权衡一下。
有良好拥有的代码是维护良好的代码
在软件开发中，我们被教导构建可扩展和可维护代码的许多方面，例如编写干净的代码、良好的注释等。这些都是每个开发人员需要坚持的优秀软件开发实践。
然而，现实是代码在许多组织中仍然变成遗留物，因此成为开发人员难以维护的负担。
在大多数情况下，问题在于此代码不再为所有人所拥有。一旦发生这种情况，代码质量将呈螺旋式下降，最终变得难以管理。
就像任何关系一样，代码需要持续不断的“爱”。如果我们不断地“培育”它，它就会不断地茁壮成长。否则，它会很快变老并很快回来困扰我们。
如果你喜欢我的文章，点赞，关注，转发！
