内部代码是否应与组织中的非开发人员共享？

在我工作的地方，我们有很多开发人员，并且有大量代码在运行我们的员工和客户使用的专有应用程序。

我们也有很多聪明的支持人员，他们希望了解我们系统的内部工作原理，以便更好地为客户提供支持，甚至不时提交补丁。

我们是否应该开放我们的代码以供非开发人员阅读？做出此决定时，应考虑哪些因素？我以各种方式遇到了很多论点和反论点，并希望根据他人的经验以及容易理解的风险来做出决定。

迄今为止的一些争论：

• VCS中的密码是公开的（解决方案：删除密码-不应从那里开始）
• 代码对白盒安全攻击开放（反参数：这只能阻止诚实/懒惰的攻击者）
• 支持人员可以询问开发人员“工作”的方式（计数器：教男人钓鱼等）

是否有人向其组织的员工开放代码？有什么问题吗？

我认为对此没有普遍的答案。组织在规模，地理分布，公司文化，版权政策，正在开发的软件种类等方面存在巨大差异。

例如，对于一家开发商品/基础设施类型的软件的公司而言，很容易打开源代码，甚至可以将其开源，就像思科几年前使用其打印机驱动程序软件（IIRC）所做的那样。

对于开发某些稀有专有软件的公司，其中可能包含特殊算法或使他们在竞争中具有竞争优势的东西，我可以很好地理解他们是否正在努力保持其代码的秘密。例如，AFAIK Google严格限制了获得访问其核心搜索算法实施权限的人数。

如今，跨国公司也分布在许多国家，时区和文化中，并且出于安全原因，他们可能会对其Intranet进行分段，并使用防火墙来控制不同网段/域之间的流量。因此，要使“整个公司”都可以使用SCM存储库，实际上可能需要为系统管理员做大量的额外工作，并带来额外的安全风险。虽然它通常通常不会带来任何好处，但是由于在不同大陆工作，使用完全不同的东西的雇主甚至可能根本不了解我们的项目，因此对它的积极贡献要少得多。

因此，如果在您的部门内和/或以某种方式对与项目相关的人员有意义，为什么不这样做。但是总的来说，仅出于“开放”的目的，我不确定这样做是否值得。

最后一点：即使支持人员很聪明并且渴望提供补丁，我也要说，在集成到系统中之前，开发人员应始终审查他们的贡献。

在我工作过的大多数组织中，代码存储库对所有开发人员开放。

在某些情况下，它还用于存储文档（例如规格和要求）以与软件一起对它们进行版本控制。在这种情况下，大多数其他员工也可以访问。在回购仅用于代码的地方，非开发人员通常无权访问-但我从未听说过有人抱怨，因此这两种方式可能都没什么大不了的。

我会建议尽可能的开放-因此，如果人们想要访问，除非有明显的问题，否则请给他们。但这确实是组织文化的一个问题...

我确实对此有一个普遍/务实的看法，也可能取决于工作/组织的性质。但是我确实认为代码库应该对所有人开放（也将显示组织内的开放性和信任感）。

我也使用与您提到的类似的设置来工作，我们有一个支持/服务台团队来处理客户的请求。但是，系统的某些复杂区域需要其他帮助。就我而言，代码库向所有人开放，我们还没有遇到任何问题。

• 我认为，通过开放代码库，其他热心的支持团队成员也可以签出代码库，熟悉他们感兴趣或需要找到答案的业务规则/领域（并可能会提高他们的技术理解能力，并着眼于某些事物）如果时间允许，则不同于单调的例程；））。当支持团队成员获取客户问题和日志，并且能够通过查看堆栈跟踪（例如，显然取决于问题等）来指出/协助发生代码的可能区域时，这可能也很有用。这当然也可以节省与开发人员的时间，但要视问题而定。

同样，拥有包含所有业务规则/决定的产品的最新文档/ Wiki也将有所帮助。但是，当然，您需要确保不断更新Wiki，以影响新的增强功能和/或错误修复（行为发生变化）。我的诚实想法

一般而言，从组织的角度来看-人们来来往往；项目（或产品）需要继续发展。因此，在大多数组织中，通常会向所有存储库开放以维护代码。

通常，具有访问权限等可以防止未注意到的未经授权的访问（以防止代码被盗等），但是实际上并没有禁止大多数高级用户访问。在组织内部，必须（足够）信任人们，您可以使用代码信任他们。隐藏员工（或同事）的代码是一个很大的消极因素。

在我们的组织中，即使人们并没有真正为代码做任何贡献，他​​们也可以直接访问代码，这很有帮助，因为他们试图在现场（拥有所有权）解决/解决问题，而不是将事情交还给开发人员并入睡！