软件开发中的强制函数

这里有一个不可避免的事实：您正在工作的软件项目有一些没人知道的缺陷。不是你，不是你的用户，也不是你团队中的任何人。这些可能是UI中的错误假设，也可能是体系结构中有漏洞的抽象，或者是容易出错的发布过程。

只要有足够的时间，这些缺陷就会被发现。但是时间就是金钱。你越早发现它们，修理它们就越便宜。那么你怎么能更快地发现他们呢？

好消息是，你可以做一些事情来迫使问题浮出水面。你可能已经在做其中的一些了。

找出一部旧的或便宜的手机，试着在上面运行你的应用程序。任何主要的性能瓶颈都会突然变得明显起来。

假设您是Team 1中的新开发人员。从您的开发计算机中删除项目，克隆源代码并从头开始设置。自述文件和过时的安装脚本中的差距很快就会变得明显。

尝试添加对完全不同的数据库的支持。泄露到数据层抽象中的当前数据库的详细信息很快就会变得显而易见。

将几个屏幕从您的前端应用程序移植到不同的平台。例如，编写一个原封不动地重用业务层和数据层的命令行界面。架构的“平台无关”部分可能很快就会显示为任何东西-但是。

开始每周发布手机应用的测试版。每月释放过程中的痛苦部分将开始变得不那么痛苦

将您的软件交到真正的用户手中，而不告诉他们如何使用。然后仔细观察他们实际是如何使用它的。

借用交互设计的术语，这些都是强制函数的示例。它们以一种很难忽视的方式将隐藏的问题带到意识中，因此很可能被解决。

当然，在生产或现场演示中出现问题也是如此。不同的是，强迫函数是自愿应用的。用你自己的方式去发现问题，压力更小，更不用说更便宜了。

如果您将您的软件想象为随时间演化的东西，那么战略性地应用强制函数是加速此演化过程的一种方式。

这样做有风险吗？强迫功能就像是高强度的训练环境。虽然培训很重要，但它并不完全是真实的世界(“地图不是领土”)。强迫函数通常以一种成功标准为标准，并强化它，以强制适应。由于他们只关注一个标准，而忽略了其他所有东西，因此有可能在这一点上投资太多，而牺牲了更大的图景。

换句话说，你不想花几个月的时间让你的手机游戏在一部7年前的手机上运行得非常流畅，结果却发现没有人觉得游戏有趣，你的钱也花光了。

强制函数是一种工具；知道在您的团队中应用哪些函数以及应用它们的频率是另一次的主题。

然而，给出部分答案：我有一种感觉，定期与潜在客户进行面对面测试可能是最终的强制功能。为什么？它们不仅揭示了许多意想不到的、独一无二的问题，而且还让您了解您可能想要应用哪些其他强制函数。它们就像是“强制函数的强制函数”。

制造顾客想要的东西的唯一方法是在他们面前拿到一个原型，然后根据他们的反应进行改进。

保罗·格雷厄姆--如何启动一家初创企业。

如果你觉得这篇文章有用，请给我留言，或者考虑使用下面的按钮之一与你的朋友和同事分享它-Matt(@kiwiandroiddev)