程序员似乎已经忘记了软件的真正目的是解决实际问题。
50年前，即1968年，在北约科学委员会的支持下组织了
一次软件工程工作会议 。 那时，人们开始注意到软件正在成为社会的基本组成部分。 但是，它也变得太难以理解。 这次会议之后，编程已成为一个行业。 并且它开始摆脱控制商人的控制。
此后无论编程如何进行，业务与软件开发之间的分离还是一个问题，即会议首次将其称为“工程”。 如果开发人员过于专注于开发，他们可能会错过编写软件的目标。 他们可能看不到不需要任何代码的隐藏解决方案。
这是一个例子。
一家初创公司创建了一种设备，该设备允许人们通过蓝牙打开自己的房屋的门。 窗口小部件用作可视界面，即使手机被锁定也可以看到。 他只有一个按钮，叫做“打开门”。
当用户离家较近时，他接了电话，找到了小部件，然后按了一个按钮以打开门。
有人看着它问：
如果我们使用蓝牙，并且我们的商业模式允许拥有电话的任何人进入房屋，为什么我们要强迫某人拿起电话并按下按钮？ 当设备接近1米时，让门打开。 因此，我们无需为可视界面的开发和编程付费！
蓝牙故事就是狭窄关注的一个很好的例子：目标是以最小的努力打开门。 如果传感器是无线的，那么开发可视界面是没有意义的。
如果您知道企业想要实现的目标以及对用户来说有价值的东西，那么您可以将此知识与技术知识相结合。 只有这样，您才有足够的信息来提出最佳答案，并得出结论，该产品不需要界面。
这是一个很好的示例，说明了如何解决技术问题而无需编写除解锁代码之外的任何其他代码。 但是，与
Tech Debt一样 ，
没有什么理由证明编写低劣的代码是
合理的 。
并非每个代码都值得编写。
有时，修复严重错误可能不是优先事项。 如果您有一个加密货币交易所，并且系统两次支付相同的费用，那么解决成本高昂的问题，就成本和收益而言，人为干预可能是最佳的解决方案。
重要性和优先级之间的权衡使我想起了我的
同事最近向我展示的模型。 它被称为“优先级矩阵”，这是一个二维
模型 ，可用于根据错误影响的用户数量和严重性来对错误进行优先级排序。
上述的重新存款问题属于影响一个用户的不便类别。 因此，优先级为3。
并非每个错误都值得修复。
当开发人员尝试为所有内容编写脚本时，这是很常见的事情。 但是，某些重复性任务不值得自动化。 如果您要隐藏有关主团队工作方式的必要知识，则无需花费时间来编写脚本。
封装复杂的逻辑和有用的知识的抽象是有区别的。 有时需要澄清信息。 如果将它们抽象化，它们可能会产生相反的效果，并且将更加难以理解。
在CLI中使用某些类型的低级命令比抽象化知识的高级命令（例如
Git ）更有用。
几年前，我正在从事使用
增量交付的项目。 这是一个身份验证系统，要求用户提供一些个人数据以供第三方提供商进行验证。
这是团队想要创建的特殊字段验证功能。 但是，随着截止日期越来越近，审核历史记录在计划每个Sprint时被优先考虑。 最终，该团队发现完全没有奇异的验证是没有意义的。
原因如下：验证是强制性的！
提供可靠的信息符合用户的利益。 如果用户提供了不正确的数据，则将不会对其进行验证，也将无法使用系统。 此外，大多数浏览器都支持标准HTML验证，这相当不错。
在最坏的情况下，无法验证自己的用户可以致电支持部门以手动检查所有内容。
并非每个功能都值得编程。
如果您是开发人员，并且了解要解决的问题，则可以提供更好的代码，有时甚至可以完全不用代码。 您不是付钱在屏幕上写字符的“
代码猴子 ”。 您是获得报酬解决问题的专业人员。
但是，如果您尝试在技术的帮助下解决所有问题，则一无所知，您将难以理解对客户有价值的东西并提出出色的想法。
您的目标和编写代码的目标是创造价值并使现有世界变得更美好，而不是满足您对世界应该如何的自我中心的看法。
俗话说：“如果只有锤子，一切看起来就像钉子。”
最好先拥有钉子，以便您考虑需要锤子。
也就是说，如果您首先需要指甲。
感谢您阅读本文！
如果我的翻译有误，请在评论中写出来！
另外，请访问我的网站以快速访问javascript问题和解答-JavaScript
问题与解答我将非常感谢和感谢您）
我在
Twitter和
VK上非常感谢您的关注！