你解决的问题比你编写的代码更重要！

软件的目的有时会被遗忘

---

程序员似乎忘记了软件的真正目的，那就是解决现实问题。

50年前，在1968年，由北约科学委员会主办的软件工程工作会议召开。那时，人们开始注意到软件正在成为社会的基本组成部分。然而，它也变得难以理解。在那次会议之后，编程开始成为一个新的行业。它开始摆脱商界人士的控制。

无论从那时起编程的路径如何，业务和软件开发之间的分离仍然存在问题 - 或者是第一次召开会议时的“工程”。如果开发人员过于专注于开发，他们可能会错过他们编写的软件背后的目的。他们可能看不到不需要任何代码的隐藏解决方案。

这里有一个例子。

有一家初创公司正在建造一种设备，允许一个人使用蓝牙解锁他们家的门。与设备通信的可视界面是一个小部件，即使手机被锁定也可见。它只有一个名为“打开门”的按钮。

当用户靠近房子时，他们会抓住手机，找到小部件，然后单击按钮打开。

有人看着那个工作流程并问：

如果我们使用蓝牙，我们的商业模式接受任何拥有手机的人都可以进入房子，为什么我们需要让某人拿起手机并按下按钮？当检测到设备靠近1米时，我们允许门解锁。这样我们就不需要为设计和编写可视化界面付出代价了！

蓝牙故事是狭隘焦点的一个很好的例子：目标是以最小的努力解锁门。如果传感器是无线的，那么设计可视界面是没有意义的。

如果您了解业务正在尝试实现的目标以及对用户的价值，您可以将这些知识与您对该技术可能性的了解相结合。只有这样，您才能获得足够的信息以获得更好的答案，并得出结论。

这是如何解决编程问题的一个很好的例子，而不必编写除解锁功能代码之外的任何其他代码。然而，就像技术债务一样，没有什么可以作为在其余部分编写垃圾代码的借口。

并非每个代码都是有价值的

有时，严重bug的修复可能不是优先事项。如果您是加密交换，并且您的系统允许重复存款一次，那么如果解决问题的成本很高，人工干预可能是最佳的成本效益解决方案。

严重性和优先级之间的这种权衡让我想起了一位同事最近向我展示的模型。它被称为优先级矩阵，这是一种二维模型，可用于根据错误影响的用户数量和严重程度确定错误的优先级。

前面描述的单个重复存款问题属于影响一个用户的不便类别。因此，优先3。

并非每个bug都值得修复

作为开发人员，尝试为所有内容编写脚本是很常见的。但是，一些可重复的任务可能不值得自动化。

复杂逻辑的封装和有用知识的抽象之间存在差异。有时，信息应该明确，以便易于理解。如果你抽象它们，它们会产生相反的效果并且更难理解。

在CLI中使用某些类型的低级命令比抽象知识的高级命令（如Git别名.）更有用。

并非每个命令都值得编写脚本

几年前，我使用Incremental Delivery进行了一个项目。这是一个身份验证系统，要求用户提交一些个人数据以供第三方提供商验证。

团队想要建立这种奇特的现场验证功能。然而，随着截止日期变得越来越近，验证在每个sprint规划中被排除优先级。最后，该团队发现，首先存在的花式验证没有任何意义。

原因如下：验证是强制性的！

提供有效信息符合用户的利益。如果用户提供了错误的数据，则不会对其进行验证，也无法使用该系统。此外，大多数浏览器都支持足够好的标准HTML验证。

在最糟糕的情况下，无法验证自己的用户会调用支持手动验证。

并非每个功能都值得编码

作为开发人员，如果您了解了您尝试解决的问题，那么您将能够提供更好的代码，有时甚至根本没有代码。您不是为在屏幕上书写字符而付费的 Code Monkey。你是一个专业的解决问题的人。

您编写的代码的目的是为了创造价值并使现有世界变得更美好，而不是满足您对自我世界应该是什么的以自我为中心的观点。

有人说：“如果你拥有的只是一把锤子，那么一切看起来都像钉子一样。”

最好先钉一个钉子，以便你可以考虑锤子的需要。