standards - 自定义工具指南

Question

在开发产品时，我们经常需要创建专有工具来测试它们的一些独特功能或诊断问题。事实上，这些工具至少与产品本身一样有趣，我们的一些内部小组已经要求提供它们的副本。

因此，除了明显的业务驱动规则（例如，不要检索敏感数据）之外，在构建个人或内部工具时，与销售产品相比，您有什么不同，为什么？

在内部工具中，什么对您来说更重要（或不那么重要），您在构建它们时是否考虑对公司的整体价值？

谢谢你的想法！

Answer 1

1. 首先，内部工具总是开发得又快又脏。几乎没有测试——它只需要完成工作。
2. UI 不如面向客户的应用程序重要。
3. 内部工具可以使用他们测试的产品和框架的内部/私有/专有知识。例如，我们的上一个产品绕过了我们已发布的 API 的一部分，并使用了未记录的 Web 服务调用来获得更好的结果。
4. 这一点很重要，但却是一场失败的战斗：永远不要将内部工具留给客户。作为一名顾问，我有时不得不在现场使用甚至开发这些工具。我试图对我的客户隐藏它，但他们不时要求我把工具留在他们身边（或者更糟糕的是，打电话给销售代表并要求那个“神奇工具”）。您不希望客户根据第 1-3 点构建的工具来判断您整个公司的生产水平。

Answer 2

从工程的角度来看，我不会做任何不同的事情：

• 内部和销售工具都需要编写良好并有据可查
• 两者都需要根据一组要求、截止日期、预算限制等来创建。
• 两者都需要测试或验证

我看到的一大区别适用于待售产品，而不是内部工具：待售产品需要营销、支持等，而内部工具则不需要。

此外，由于内部工具将在更受控制的环境中使用，因此无需针对不同的计算机系统、Internet 浏览器等进行测试。

Answer 3

最大的不同：

借助个人和内部工具，您可以更自由地尝试新技术、最新时尚。您可以承担实际交付给客户的应用程序不会承担的风险。

Answer 4

由于我构建的诊断程序通常具有非常特殊的用途，因此我倾向于提供比面向客户的产品更多的选项和内置示例。换句话说，我假设用户比客户通常更熟悉该技术，并且我提供了更多调整工具操作方式的能力，而不必担心它可能会让用户不知所措。但我也尝试让它满足 80% 的用例，而无需用户提供太多“帮助”。