如何促进代码重用和文档编制？[关闭]

作为大约10个以上开发人员的团队负责人，我想促进代码重用。我们编写了很多代码-在过去几年中，很多代码都是重复的。现在的问题是，其中许多代码只是其他代码的重复或它们的微小变化。

我已经开始了关于如何将代码制成组件的运动（讨论），以便可以将它们重新用于将来的项目，但是问题是，我担心那些不了解组件的新开发人员或其他开发人员会继续前进，并且写自己的东西。

无论如何，有没有提醒开发人员重用组件/改进文档/为基础组件做贡献，而不是复制现有代码并对其进行调整或编写自己的代码？

如何使组件易于发现，易于使用，以便每个人都可以使用它？

我认为每个开发人员都知道可重用组件的好处，并想使用它们，只是我们不知道如何使它们可被发现。同样，开发人员在编写代码时，知道应该编写可重用的代码，但缺乏这样做的动力。

您需要适当的文档。它应该很容易找到和导航。您还需要纪律。如果您的可重用代码库中已经提供了一个解决方案，但是开发人员选择改用自己的解决方案（没有任何适当的理由），则应还原他的解决方案并告诉他使用现有的解决方案。

我也同意欣快对这个问题的评论。在不同项目之间重复使用任何东西通常是不可能的（通常所有CRUD操作看起来都一样，但是通常您不能重复使用它们）。

除了已经提到的因素“文档”，“易于查找和导航”，“学科”和“ codereview”

可重用代码必须是

• 易于使用（=需要示例，例如单元测试）
• 对其他模块没有太多依赖
• 它必须具有稳定的api，因此我不必更新应用程序即可使用该库。

如果没有最后两项，那么使用我们不想要的“复制和粘贴继承”就容易得多。

我认为使它们重用代码的最佳方法是动机。如果您将可重用的组件放在额外的项目中（如Euphoric建议的那样），则需要付出很多努力。在我工作的地方，我们做了一个项目，该项目在可配置的执行计划中运行一组预定义的接口，并提供一些服务（例如，针对DB_interaction，FTP-Service等的不同类）。该项目取得了巨大成功，因为我们的开发人员实际上希望使用微框架，因为这为他们节省了为类似项目编写样板代码的大量时间。清单，字符串等的实用程序库也是如此，但是在这种情况下，您只想使用现有的一次。（为什么要重新发明焊缝？）

结论：让您的开发人员体验经过良好测试的可重用组件的好处。但是我也同意Andrzej Bobak的回答：许多事情是不可重用的，因为它们是相似的，但不相同。

这将是困难的，因为人们喜欢为简单的组件编写新代码，并且他们喜欢以自己的方式进行操作。与编写具有新要求的全新实现相比，利用现有解决方案并对其进行扩展要困难得多。如前所述，您需要做的是在团队之间启动代码审查过程，以帮助确定应使用/扩展现有组件而不是新组件的情况。

您还需要维护一个非常好的和详尽的文档，以便人们可以参考它并轻松找到他们需要的东西。如果文档不完整或与真实文档不同步，则不会激励人们进行搜索或增强。

作为团队负责人，您还应该鼓励人们在创建自己的组件之前先问自己是否存在类似的组件，并将其定向到文档，以便他们查找。如果有人错过了现有组件，那么代码检查过程肯定会抓住它，但是如果他们已经在自己的实现中投入了10个小时的开发，那该怎么办？您需要通过在团队中强制执行良好的研究行为来避免这些情况。

我们在目前正在进行的一个大型项目中遇到了这个问题。在过去的几个月中，我们一直在轮换开发人员，这也是一个相当大的代码库，甚至从一开始就参与该项目的人都不知道其中的每一寸。

尽管代码通常写得很好，并且只有一个责任就可以分成几小部分，并且文档在那里，但是很容易错过已完成的工作。一致的命名约定很有用，因为在任何IDE中都可以轻松查找内容。文档可能很全面，但是随着时间的增长，通读它会有些痛苦。

在我看来，我们所做的一件事是极大地改善了这种情况，就是引入了一种我们称为闪电会谈的事情。每当有人写出自己认为应该为团队所知的一段代码时，就会安排一个简短的演示文稿（通常为5-15分钟）。我们尝试每周执行一次。主题趋向于变化，从新功能和处理最近出现的复杂问题的方式，到测试/编码方法，可重用组件，再到讨论应用程序的基础及其重构。

在类似的公司范围内的演讲中提到了某些主题。我们发现这是刺激知识共享的一种非常有效的方法。与参加简短而很少举行的培训课程或坐在那里阅读文档封面相比，观看和记住简短的演示文稿以及知道在哪里寻找其他文档或向谁寻求帮助要容易得多。

公司范围内的谈判实际上是第一位的。我们只是采用这种方法来进行特定于项目的知识共享，我认为它的效果很好。

结对编程还可以使知识传播更快。

我认为这实际上是两个问题合二为一-我会尽力回答这两个问题。

1）我们如何减少代码库中的重复代码。
它有助于提醒我们这样做的好处：由于重复的业务逻辑而导致的错误更少，并且需要维护的代码更少。减少这种情况发生的最好方法是通过交流-如其他答案所述。我强烈同意使用代码审查的建议，但要特别注意一下，您应该平均分担代码审查责任，以正确传播知识。您还应该使用日常维护，以便开发人员经常能够识别出有人在尝试解决现有有用代码的问题。您还应该考虑代码配对，因为它可以增加知识共享并有助于使程序员保持纪律。

我还建议您与开发人员尽可能地靠近，最好在同一房间。具有大量共享的白板和空间。然后一起送他们出去吃饭。您的开发人员“绑定”的越多，他们彼此之间的沟通越好。

我不同意使用维基或类似文档代码的建议。无论开发人员多么有纪律，其文档都将脱离原始代码。一种更有效的方法是通过示例样式测试使用规范。这些文件以一种清晰的方式记录了代码，如果有人在不更改示例的情况下更改了代码，则测试将失败。

您已经有一个包含大量重复代码的大型代码库，因此您可能应该进行重构。很难找到未被剪切和粘贴的重复代码。因此，我建议您分析变更历史，而不要这样做。查找经常同时更改的文件。如果它不指示实际的重复代码，并且仍然值得清除，则可能表明封装存在问题。如果您还可以根据代码更改来分析错误修复历史记录，则可能会发现通常需要修复的特定热点。分析这些热点，您可能会发现其中许多是由于重复的业务逻辑所致，开发人员仅在一个地方进行了更改，而没有意识到需要进行两次更改。

2）我们应该如何制作可以在其他项目中使用的共享窗口小部件，组件，库等。
在这种情况下，您不应尝试包装业务逻辑，而应共享有用的框架代码。这可能是一个棘手的平衡，因为创建和维护一组共享组件的成本可能非常大，并且可能很难预测在哪些情况下值得这样做。我在这里建议的方法是三击规则。不必担心重复编写两次类似的代码，但是当您需要第三次编写该代码时，可以将其重构为共享组件。在这一点上，您可以合理地确定它会很有用，并且对组件的更广泛的需求有了很好的了解。显然，开发人员之间的沟通在这里至关重要。

考虑使共享组件尽可能多地开源。这不是业务逻辑，因此不会给您的竞争对手带来太多优势，但这意味着您将免费获得额外的审阅者和维护者。

IMMO的关键不是文档或工具，关键是COMMUNICATION。10位以上的开发人员人数不多，但有一些事情可以改善这种交流：

• 结对编程：两个人在一起还有更多更改，两个人之一知道该问题已在项目的另一部分中解决，并可以重用。

• 集体代码所有权：所有人员都在系统的不同部分工作，这样一来，他们就很容易知道他们已经在项目的另一部分中完成了工作，对我而言，这是团队中的基本实践。

• 给水平项目的工作时间：例如，每月一个或两个星期五，此时的开发人员可以从事自己的项目，这些项目对您的公司项目有一定的适用性。这样，开发人员可以编写可重用的库和组件，有时其代码已经存在，但需要一些清理和文档编制。

• 进行讲座和讲习班：为开发人员的讲座和讲习班预留时间，开发人员可以谈论他的库，或者您可以进行重构研讨会，获取一些重复的代码，并删除重复项，从而创建可重用的组件。

文档可能是需要的，但仅是您需要的一小部分：改善团队内部的沟通。

使用Lucene等本地搜索引擎（或更特定于源代码的东西）为您的代码编制索引会怎么样？例如，当某人开始编写新类或新函数时，他必须尝试（作为内部策略）几次搜索，然后再编写自己的代码。这样，您可以避免过多的交流，并且可以依赖良好的注释，方法和类名称。我发现自己是通过Internet上可用的开源搜索引擎来做到这一点的：我不知道是谁写的方法或类的名称或名称，但是通过几次搜索或同义词，我总能找到我需要的东西。

您需要一个工具来帮助您的开发人员无缝地实现它。如果您的开发人员发现了通过重复使用代码段可以节省多少时间（不仅在编写代码方面，而且显然在质量保证，集成等方面），还得益于易于使用和使用的高效工具。直接集成到开发环境中，他们会祈祷您采用这种工具！

注意，很多时候实现代码重用的库不会带来巨大的优势（它们往往变得功能强大又庞大……）；相反，我只想关注简单的代码片段，即有效地解决特定任务的几行代码。

这样，您可以通过给出可供程序员直接使用的真实示例来强制使用准则和最佳实践。

用于代码段管理的工具有几种，我建议使用以下一种：http : //www.snip2code.com。

（免责声明：我是Snip2Code的创始人之一，我和我的联合创始人一起在很早以前就以相同的心态：这就是为什么我们决定启动这个项目的原因，该项目收集了我所有的功能如上所述，例如，在团队之间共享代码片段，集成在IDE中，例如Visual Studio，Eclipse，IntelliJ，Notepad ++等）