自定义工具指南
在开发产品时，我们经常需要创建专有工具来测试其一些独特功能或诊断问题。 事实上，这些工具至少可以像产品本身一样有趣，我们的一些内部团队已经要求提供它们的副本。
因此，除了明显的业务驱动规则（例如不要检索敏感数据）之外，当您构建个人或内部工具（与销售产品相比）时，您有何不同，为什么？
在内部工具中，什么对您来说更重要（或不那么重要）？当您构建这些工具时，您是否考虑对公司的整体价值？
感谢您的想法！
While developing products, we often need to create proprietary tools to test some of their unique features or diagnose problems. In fact the tools can be at lest as interesting as the products themselves, and some of our internal groups have asked for copies of them.
So, aside from the obvious business-driven rules (e.g. don't retrieve sensitive data), what do you differently when you build personal or internal tools, as opposed to for-sale products, and why?
What's more (or less) important to you in internal tools, and do you consider overall value to the company when you build them?
Thanks for your thoughts!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
作为一名顾问，我有时不得不在现场使用甚至开发这些工具。 我试图向我的客户隐瞒它，但有时，他们要求我把这个工具留在他们身边（或者更糟糕的是，打电话给销售代表并索要那个“神奇工具”）。 您不希望客户根据第 1-3 点构建的工具来判断整个公司的生产水平。
As a consultant, I sometimes had to use and even develop those tools in the field. I try to hide it from my clients, but from time to time, they demand I leave the tool with them (or worse, call the sales rep and ask for that "magic tool"). You don't want customers judging your entire company's production level based on tools build according to points 1-3.
从工程角度来看，我不会做任何不同的事情：
我发现的一个很大的区别适用于待售产品，而不是内部工具：待售产品需要营销、支持等，而内部工具却可以不需要。
此外，由于内部工具将在更受控制的环境中使用，因此不需要针对不同的计算机系统、互联网浏览器等进行测试。
From an engineering perspective, I wouldn't do anything differently:
The one big difference I see would apply to the for-sale products as opposed to the internal tools: for-sale products need marketing, support, etc that internal tools can do without.
Additionally, since internal tools will be used in a somewhat more controlled environment, they don't need to be tested against different computer systems, Internet browsers, etc.
最大的区别是：
有了个人和内部工具，你可以更自由地尝试新技术、最新时尚。 您可以承担在实际交付给客户的应用程序时不会承担的风险。
The biggest difference:
It's with the personal and internal tools that you can be more free to try out a new technology, the latest fashion. You can take risks that you wouldn't take with the application that you are actually shipping to customers.
由于我构建的诊断通常具有非常特殊的用途，因此我倾向于提供比面向客户的产品更多的选项和内置示例。 换句话说，我假设用户比客户通常更熟悉该技术，并且我提供了更多调整工具操作方式的能力，而不必担心它可能会让用户不知所措。 但我也尝试让它满足 80% 的用例，而无需用户提供太多“帮助”。
Since the diagnostics I build are usually very special-purpose, I tend to provide more options and built-in examples than I would for customer-facing products. In other words, I assume the user is more familiar with the technology than a customer would generally be, and I provide more ability to tweak the way the tool operates without worrying that it might overwhelm the user. But I also try to make it satisfy 80% of the use cases without much "help" from the user.