什么是管理开发人员脚本的正确方法？

开发人员创建脚本来帮助他们的工作。例如，使用某些参数运行Maven，杀死在开发中突然出现的不需要的后台任务，或者连接到特定的服务器。这些脚本不是核心构建脚本，也不在我们的Continuous Integration服务器中使用。

最好的管理方式是什么？要将它们放入目录（也许是 /scripts）并将其检入Git？要将它们分别维护在某些文件服务器中？

将它们视为源代码的理由是它们是源代码并且可以更改。不这样做的理由是它们只是辅助工具，并非所有开发人员都需要任何给定脚本（例如，某些Windows上工作的Linux特定脚本）。

开发人员脚本也用于版本控制，因为通常这些脚本也取决于版本控制中的项目，例如文件路径。

如果对这些脚本进行了版本控制，它们也应该为所有开发人员所用，以避免每个开发人员都编写自己的脚本集，这将成为维护难题。

此外，这些脚本的错误修正或改进会通过版本控制自动发布给每个开发人员。

除了@simon的答案。

并非软件工程中的所有内容都与编程，设计或建模有关。在工作日内，我们要连续执行许多任务。您已经提到过一个- 在IDE外部构建项目 -但还有更多。

有经验/积极主动的开发人员往往会自动执行这些任务。当这些任务成为SDLC的一部分时，有些甚至是构建工具，而且这些任务很繁琐- 容易出错 -手工完成。程序无论多么繁琐，都擅长做重复性工作。我们- 人类 -并不那么好。

这些工具/脚本还有其他积极的副作用

1. 生产率
2. 知识转移
3. 自主权（对于新来者）

因此，是的，脚本应该位于SCM中，并且应该是开发人员工具箱中的又一个工具。

关于文件夹，/scripts我会说没关系。为简单起见，我将它们保留在项目的根目录中，以便脚本中声明的所有路由都相对于项目的文件夹。如果我需要访问外部文件夹或文件，则可以创建软链接。

将脚本检入SCM之前需要考虑的事项。

• 为了安全起见，请确保脚本没有经过硬编码的凭据- 理想情况下，应对脚本进行参数设置 -

• 确保脚本不会对系统造成任何影响，例如执行无法撤消的命令（最典型的rm -rf）。

• 由于这些已成为项目来源的一部分，因此高度赞赏文档。

• 脚本不是火箭科学。使脚本简洁。而不是一个人统治所有事物……在黑暗中将它们束缚起来，制造出更多，更小和更简洁的产品。就像您正在应用SRP。

我将提供一些负面意见。一方面，通用，有效和有用的开发人员脚本当然应该与其他开发人员共享，而做到这一点的最佳方法是让它们与代码放在同一存储库中。

但是，我会为提交脚本设置一个高门槛。脚本就是代码，就像软件本身一样。这意味着它们需要与其他代码段类似地对待：

• 进行代码审查
• 经过测试和自动化（如果可能）
• 在更改代码库时考虑（特别是，如果许多开发人员使用了脚本，则进行更改以破坏脚本会引起很多冲突）
• 维护（包含所有内容-优先级，时间，文档等）。

还有许多其他考虑因素比脚本本身更适用于脚本：

• 首先，要说服一个人的组织和利益相关者投资于维护使开发人员的工作更加轻松的脚本，要困难得多。这意味着很难花时间来满足上述条件-编写适合您的环境的脚本很容易，但是对其进行参数化，使其稳定，记录它需要更多时间。这意味着脚本可以并且将变成无效代码，除非开发人员可以证明保持脚本为最新。
• 多个开发人员对一个复杂的脚本进行足够的维护以使其更熟悉，或者多个开发人员感觉到代码的所有权的可能性要小得多。当原始开发人员离开时，寻找其他人来获取所有权可能很困难（找到并证明他们学习脚本工作原理的时间可能会更加困难）。
• 脚本更有可能以某种方式与开发人员机器交互并构建环境。您也很有可能会拥有多个具有多个不同环境的开发人员。如果脚本由于维护不当或没有考虑到极端情况而使环境混乱，那么您不仅在破坏软件的夜间构建，还可能使开发人员花费一天或更多的时间来获得他们的软件。环境恢复正常。这可能会导致流血和失去信任。
• 由于脚本通常在软件本身外部，因此对其进行维护可能是一个挑战。如果脚本不是通过自动化运行的，它们很容易过时或被遗忘，这时它们已成为无效代码，只是技术欠债，有人需要花费一些时间进行清理。

总而言之，脚本对单个开发人员可能非常有帮助，但是作为代码库本身的一部分进行共享可能是一项困难得多的任务，并且可能导致更多问题得到解决。