您如何跟踪团队编写的类和职能？

在编写代码时，我遇到了许多与队友一样的挑战，并且编写了一些有用的函数和类，它们也是如此。如果能保持良好的沟通，我会听说有人将一些很棒的东西组合在一起，六个月后，当我需要它时，我可能会记住它并调用该函数，从而节省了时间。如果我不记得它，或者从不知道它，我可能会重新发明轮子。

是否有记录此类事情的特殊实践？您如何使它们容易找到？

如果您的团队没有这样的文档，您如何查找车轮是否已经存在？

编辑：

到目前为止，除了一个答案以外，所有答案都与理想情况有关。因此，让我总结一下这些解决方案：文档和通讯；这些都是很棒的事情，但是它们依赖于程序员有时间（和技能）来编写文档，参加会议，做笔记并记住一切。

到目前为止，最流行的答案（Caleb答案）是程序员无法使用的唯一答案，它没有文档和会议的能力，并且只做一件事：编程。编程是程序员的工作，是的，一个优秀的程序员可以编写文档，进行单元测试等，但是让我们面对现实吧-我们大多数人都喜欢编程而不是文档。他的解决方案是程序员识别可重用的代码并将其拉到其自己的类或存储库等中，并且由于它是孤立的，因此变得可查找并简化了使用它的学习曲线。这是通过编程来完成的。

从某种角度来说，我是这样看的：我刚刚编写了三个函数，我想到其他人应该也了解它们。我可以记录它们，编写它们，在会议上宣布它们，等等。-我可以做，但是这不是我的强项-或....我可以将它们提取到一个类中，命名好，使它们像一个黑盒子，然后将其粘贴到其他类文件所在的位置。然后，一封简短的电子邮件宣布它很容易。其他开发人员可以扫描代码并更好地理解代码，而不是使用他们无法完全理解的代码中使用的隔离功能-删除上下文。

我之所以喜欢它，是因为这意味着拥有一组具有良好名称的类文件以及具有良好名称的方法，是一个很好的解决方案，可以通过良好的编程来实现。它不需要开会，并且可以减轻对详细文档的需求。

在这种情况下，还有其他想法吗……针对孤立的且时间紧迫的开发人员？

图书馆。构架。版本控制。

如果您具有可重用的代码，那么最后要做的就是让不同的团队成员将源代码复制到他们的项目中。如果这样做的话，它们很可能会在此处进行一些更改并在那里进行一些调整，很快您就会获得数十个功能或方法，它们的名称相同，但每个函数或方法的作用却有所不同。或者，也许更有可能的是，原始作者将继续完善代码以修复错误，提高效率或添加功能，但是复制的代码将永远不会更新。它的技术名称是一个巨大的怪胎。

正确的解决方案是将这些可重用的内容从您最初为其构建的任何项目中提取出来，并将其放入其自己的版本控制存储库中的库或框架中。这使查找变得容易，但不鼓励进行更改，而不考虑可能正在使用它的所有其他项目。您可能会考虑使用几种不同的库：一种用于经过测试的，不再可能更改的代码，一种用于看起来稳定但尚未经过全面测试和审查的东西，一种用于建议的添加。

一种方法是为此目的建立一个Wiki，并编写一些高级文档，介绍您拥有哪些可重用的组件，如何解决问题等。

困难的部分是让团队中的每个人都不断维护该Wiki。但是任何其他类型的文档都会遇到相同的问题。

您的某些代码可能还不错，足以放入可重用的库中。这也使得以后再次查找代码更加容易。

我在一家拥有700名员工的公司中，在2至20人之间的团队中，这是我的经验。

在团队层面

我们每天举行15至20分钟的“站立会议”。我们可以快速分享一些常识，例如“我昨天做了这个功能，非常困难”。

每个项目都有一个Wiki。这意味着我们可以共享有关项目完成情况的（技术）信息，包括内置的自定义类/功能。

在代理商一级

在代理商一级，我们有4种工具：

• 另一个维基。在这里主要是为了向我们提供有关硬件和材料的信息，但是有时我们会使用它来共享技术信息，以便在将其置于公司级别之前进行审查。
• 每周会议。他们主要是了解每个团队/项目的进度，但是由于我们主要是技术爱好者，因此我们可以提出一些很棒的建议。
• 邮件列表。我们与代理商中的每个人都有一封邮件。许多很酷的东西/有趣的东西/有用的东西穿过那里。
• VCS存储库。每个机构都有自己的个人资源库，我们在那里有一些小型项目，大部分是我们在不同项目中使用的模块。

在公司层面

在公司层面，它更具组织性。

“代理商级别” Wiki实际上是公司Wiki的一部分。

然后根据技术拆分Wiki。因此，任何人都可以对其进行改进，搜索并从根本上赋予Wiki以生命。

还有一些我们可以订阅的邮件列表。该机构中的任何人都可以订阅，并且大多数人都遵循至少一种或两种技术，实际上大多数人都遵循其中的5-10种。

VCS当然是最好的代码共享系统。

结论

总而言之，没有明确的解决方案。知识共享一直是一个大问题，并且可能会一直存在。创建知识库的解决方案很多，而且可能很适合您的要求。但是，由于当前的解决方案并不总是很聪明，因此有人尝试获得更好的知识库。

好吧，一切都取决于沟通。

Wiki很棒，您绝对应该安装并使用它。一个好的内部程序员Intranet如果人们可以阅读并更新它，那将是一个很好的选择，因此您实际上是在谈论那里的人员问题。您可以建议每周召开一次“团队更新”会议，每个人都聚在一起，并概述正在进行的工作。技术负责人（至少！）应该聚在一起讨论每个团队的工作。“ Brown Bag”非正式会议很棒，可以在午餐时间安排它们，并让人们交谈。

您还需要一种共享代码，打包，版本控制和分发代码的方法。如果您拥有一个管理得很好的源代码存储库，并且将其很好地排列在“公共”文件夹和项目文件夹中，那么事情将会变得容易。

如果什么事情都没做，请与您的老板一起提出来，说明如何使公司受益，并提出前进的方向:)

代码审查会议可以提供帮助。如果您的团队定期开会讨论开发的内容，那么提出解决方案的人可以向其他人展示如何使用它。如果有人提出要坚持的观点，其他团队成员可以提出一种增加现有组件重用性的方法。

处理类似问题的最佳方法是拥有一个具有一些简单约定的存储库结构，以便作为程序员，我知道如果有一个函数doXYZ，大约应该在哪里寻找该函数。无论您使用的是名称空间，目录，模块，插件，包还是其他东西，您的代码都应该是模块化的，以使执行相同操作或访问相同数据源的函数位于同一位置。

理想情况下，除了作者对每个签入进行代码审查之外，还应该至少有一个其他人。代码审查过程可以帮助减轻许多签入方法的问题。当然，您会受到审查者知识的束缚。

TL; DR：每次签到均进行代码审查。