我们什么时候应该停止工作并制作工具？

作为软件工程师，我们一直渴望获得有效的工具来提高生产力。而且在日常工作中，我们通常对现有工具不满意，并且希望有更好的方法，例如更好的GDB脚本配置，Vim脚本和一些Python脚本来自动完成无聊的工作。

但是，实际上这是一个折衷，因为制作工具还需要时间和精力。它不会立即提高生产力。因此，您如何判断是否该是停止工作并提供一些减轻您未来痛苦的工具了？

当其中一种情况成立时，我将“制造工具”：

1. 任务让我很烦
2. 任务中人为错误的风险太大

第二个选项的“风险”不必很大-构建一个小工具的成本通常很小，因此，如果您节省的只是每周运行一次10分钟的构建风险，那么通常非常快地偿还自己。

我尝试使工具尽可能的小-现在使任务变得更容易一些，也许下次再改进。

这意味着您每次都只会解决最大的痛苦，而不是解决不会真正伤害您的问题。

凭经验，我发现努力工作通常是最省时的。制作工具通常很诱人。我在以下情况下放弃抵抗：

• 该工具具有多个目的。一个好的国际象棋棋手一举完成两件事：阻挡对手的棋子并释放主教。初学者可能需要转两圈才能做到这一点。同样，我考虑该工具是只做一件事，还是花一点功夫做两件事，例如帮助修复一些原始数据文件，并创建人工测试数据。
• 将来有用。这可能为我节省了本周的工作时间，但是否有可能节省我或某人下周进行新项目的时间？
• 现在是学习一种新语言，图书馆，设计技术或其他任何东西的好时机，我有时间去做。该工具是利用已经授予的时间进行某些教育的有益副作用。
• 当我们遇到严重的问题时，一切都会正常进行。就像没有降落伞的跳伞一样，您确实应该花时间制作或购买降落伞。如果您无法获得任何有意义的实验结果，或者新的Web应用程序根本无法使用，则您必须停下来制造或购买工具来衡量您看不到的东西，驱动组件或替换其中的一部分。系统。当工作完全需要工具时，我不在乎将来的使用或多次使用。必要权衡。

我的经验法则是，当我第三次不得不做某事时，该是编写一个小脚本以使其自动化或重新考虑我的方法的时候了。

目前，我还没有制作一个完善的“工具”，只是一个小脚本（通常是bash或python； perl也会起作用，甚至是PHP）可以自动化我之前手动执行的操作。它基本上是DRY原理（或“真理的单一来源”原理的应用，本质上是同一件事）-如果必须一并更改两个源文件，则必须共享一些共同的事实，并且真理必须被排除在外，并存储在一个中心位置。如果可以通过重构在内部解决此问题，那就太好了，但是有时这是不可行的，这就是自定义脚本的用处。

然后，该脚本可能会演变成一个成熟的工具，也可能不会演变成一个成熟的工具，但是我通常从一个非常具体的脚本开始，其中包含很多硬编码的内容。

我讨厌充满激情的笨拙的工作，但我也坚信这是不良或错误设计的标志。懒惰是程序员的一项重要素质，最好是经过长时间努力避免重复工作。

当然，有时候这种平衡是负面的-您花了三个小时重构代码或编写脚本，以节省一小时的重复工作；但通常情况下，这种平衡是积极的，如果您考虑的成本不是直接显而易见的，则更是如此：人为失误（人为重复工作确实很糟糕），较小的代码库，由于减少了冗余而具有更好的可维护性，更好的自我记录，更快的未来开发，更干净的代码。因此，即使余额显示为负数现在，代码库将进一步扩展，当您拥有三十个数据对象时，您编写的用于为三个数据对象生成Web表单的工具仍然可以使用。以我的经验，通常估计平衡是有利于艰苦的工作的，这可能是因为重复的任务更容易估计，因此被低估了，而重构，自动化和抽象被认为是较难预测的，并且更加危险，因此被高估了。通常情况下，自动化毕竟并不难。

然后就有做为时过晚的风险：很容易将三个全新的数据对象类重构为形状，并编写一个脚本为它们生成Web表单，一旦完成，就很容易添加另外27个类也可以使用您的脚本。但是，当您到达30个数据对象类的位置时，几乎不可能编写该脚本，每个类都有手写的Web表单，并且它们之间没有任何一致性（又称“有机增长”）。保持这30个类的形式是重复编码和半手工搜索的噩梦，更改公共方面所需的时间是原本应花费的三十倍，但是编写脚本来解决问题，该项目开始时本来可以很轻松地吃午饭，现在变成了一个可怕的为期两周的项目，可怕的后果是长达一个月的后果，包括修复错误，教育用户，甚至可能放弃并恢复到旧的代码库。具有讽刺意味的是，编写30类混乱所花的时间比干净的解决方案要长，因为您可能一直都在使用便捷的脚本。以我的经验，过长的自动化重复工作是长期运行大型软件项目的主要问题之一。因为您可能一直都在使用便捷的脚本。以我的经验，过长的自动化重复工作是长期运行大型软件项目的主要问题之一。因为您可能一直都在使用便捷的脚本。以我的经验，过长的自动化重复工作是长期运行大型软件项目的主要问题之一。

我只是想起了这一点：

当然，这样做的问题在于，在现实生活中，您无法轻松地测量这些数据以选择表中的正确单元格。正如在其他答案中提到的那样，您还需要添加其他变量（错误的风险，任务太无聊了，甚至无法执行一次，...）。

因此，我的回答是，这实际上取决于情况，您不能希望在所有情况下都得到任何“正确”的答案。毕竟，如果我们拥有所有菜谱的话，生活将会很无聊。

根据我的经验，这是一个大问题。工具构建通常留给有动力的开发人员，他们会停止工作以构建工具。即使它提供了价值，也常常会干扰发展。工具构建需要被视为开发“过程”的集成部分。

我记得参加代码审查时，标题错误会导致安排另一个审查。其中许多工具可能已被工具检测到。例如错误的位置计数，缺少要求，格式错误。我用perl编写的工具从提供的代码生成标头，并从Oracle数据库验证需求。它不是我们“流程”的一部分，因此在短期内构建该工具被视为延迟交付。

整个团队需要定期停下来，看看有哪些手动工作比通过工具创建可以自动完成的工作要多。

所有其他答案都是好的，但是我还要增加一个原因，为什么花时间来构建小型工具（以及自定义.vimrc，.emacs等）很有价值：

有时，您会创造性地或动机地“陷入困境”，并且做任何事情，都会使果汁再次“流动”（混合隐喻）。理想情况下，这将有效地推动该项目向前发展，但是，如果它有点切向并且对您有所启发，那也很好。

您可能不会盯着空白屏幕，而只是无法查看自己在完成一项大任务时所取得的进展。在这种情况下，剔除有形的东西可能会使您感到仿佛一无所获。

与此不同的是，当您一直在考虑应该在“后燃器”上做的事情时-花一点时间去做就可以把它忘掉，让您腾出精力重新投入主要精力。

这取决于您认为制作工具的方式。可以说我以其他开发人员认为轻浮的方式来加载它们...因为我几乎将所有东西都用于它们除最基本的文件系统命令以外的。

我使用两种理由来支持这一点。

• 这是DRY原理的扩展。如果我们想重复一遍，人工就是对人力资源的最无效使用。
• 这是记录我所做工作的一种有效方法，因此，如果我构建了某件东西，那么我（或其他人）可能要回头参考几周或几个月后我的工作方式，并保留该项目的工作日志。

有时它们会成长为更大的工具并获得交互功能，但是如果没有，它们仍然具有记录的价值。