Answers:
这个高级开发人员的论点对我来说毫无意义。
他们想增加不断检索和编译内部库的开销，以便开发人员偶尔可以读取源代码吗？与让开发人员仅在需要检查功能是否可用时才去查看源代码相比，这将浪费更多的时间。
如果图书馆和客户是由不同的开发小组开发的，并且图书馆正在积极开发，则这是一个特别糟糕的主意。客户开发人员不会对库的不稳定有任何隔离。
我不明白为什么不能在不强迫开发人员将其作为其正常构建的一部分的情况下将其提供给开发人员。
建议是
通过客户端开发人员阅读库的源代码来确定所需的功能是否可用，我们可以节省时间
您可以提出其他建议
我们可以节省时间来记录文档库，以指示可用的功能。
我曾经在一家大型软件公司工作，该公司不断使用内部业务系统“淘汰”自己的软件。
他们认为这是另一层次的测试。
对于一家公司，我表示同意是一件好事。
我认为，强迫您下载并编译最新版本实在是太过分了，除非编译步骤是贵公司出售，甚至外包图书馆的重要组成部分。
尽管可以使用源代码可能是一个好处，但是如果您有一个CI构建代理来监视存储库，那么让该代理编译该库并将其作为外部复制到相关项目中，比要求开发人员更有意义。建立副本时，请执行两个不同的编译步骤。
我目前正在从事一个未与构建代理建立联系的项目，该项目要求在构建主应用程序之前先构建一个子应用程序。我的后牙疼得很厉害。要更改子应用程序，我必须首先构建整个项目，然后转到子构建文件夹，从中获取已编译的产品，然后将其复制到其他子文件夹，然后再次构建整个项目确保主应用程序的构建中包含子应用程序的最新版本。这不是应该怎么做；至少应该有一个MSBuild脚本来自动执行此过程，并且我希望每当新代码提交到主干时，构建代理都会更新外部。
既然有这么多人回答说，让每个人都建立一个内部库是没有意义的，所以我将提出相反的观点，这可以证明原因：
您经常使用该库，并且没有文档。所以每个人都应该有参考来源。如果这是一个经常使用的库，那么方便使用参考可能会有用
当人们开始编写依赖于库的代码，而库中的某些东西不起作用时，如果不使用武器，而无需在空中挥舞手臂，那么如果在本地构建库，则很容易直接进入库代码
我并不是说他的决定是有道理的，只是指出a）问题是故事的一个方面，b）可能有合理的动机。
确实最好进行这种测试。不过，应该由测试人员而不是开发人员来完成。从这个意义上讲，这既不是您的工作，也不是图书馆开发人员的工作。
从您的描述看来，项目中没有测试人员-如果是这种情况，那就是管理问题，而且是一个严重的问题。
...可以节省时间，因为他们可以读取库源代码以确定所需功能是否可用
la脚的推理。当最新版本库无法与最新版本项目一起编译时，可能有多种原因-仅钻入lib源代码可能会浪费时间。
在推理遗漏之上的另一件事是不可避免的（在我的经历中，这是非常痛苦的），当人们不得不通过在开发和质量保证活动之间进行切换来打破流程时，随之而来的就是生产力的损失。
当团队中有测试人员时，这样的事情真的很简单并且可以轻松得多地处理。您的“高级”开发人员对您的要求基本上是测试要求草稿。
对项目或库进行任何更改后，请确保构建成功。
从此处进行的步骤通常是质量检查活动：弄清需求详细信息，设计正式的测试方案，就如何处理测试失败进行协商。
高级开发人员的建议充其量对我而言毫无意义。能够浏览源代码很高兴，但是有更好的方法可以做到这一点。
您正在使用哪个工件库？您应该能够为每个版本部署一个源jar，使其驻留在已编译的库旁边。然后，大多数IDE将允许您将其附加到已编译的库中以进行源代码浏览。带有Maven插件的Eclipse将自动执行此操作。
如果您需要最新的代码，则只需部署版本快照。
这应该只在您的构建脚本中发生：
我不明白为什么或这是一个问题。同样，当参考中缺少某些内容时，您可以将其添加到源中并推送更改。当然，图书馆可以在您的脚下进行更改似乎有些令人恐惧，但是如果图书馆维护者正确地完成工作，这是一件好事。