该程序的目标有时会被遗忘
说谎在黑板的锤子的图象。 螺丝钉在板上，他们在那里刻得很厉害程序员似乎已经忘记了软件的目的-解决实际问题。
50年前，即1968年，北约科学委员会组织了
一次软件工程工作会议 。 然后他们开始注意到软件正在成为社会的基本组成部分。 同时，这也变得更加难以理解。 这次会议之后，编程开始变成一个真正的行业。 它开始摆脱业务控制。
不论行业的命运如何，业务和软件开发（或“工程”）的分离仍然存在问题，正如会议首次宣布的那样。 如果程序员过于狭窄地专注于开发，则他们可能会错过创建程序的目标。 他们可能会错过根本不需要代码的隐藏解决方案。
这是一个例子。
一家初创公司创建了一种设备，该设备通过蓝牙打开了房屋的大门。 与设备通信的图形界面-锁定的电话屏幕上的小部件。 他有一个名为“打开门”的按钮。
当用户接近房屋时，他接电话，找到小部件并按下按钮。
有人看着这个技工问：
如果我们使用蓝牙并假设电话的所有者可以进入房屋，为什么要强迫他拿起电话并按下按钮？ 当手机在1米半径范围内时，让门自己解锁。 无需在设计和GUI代码上浪费时间！这是狭窄关注的一个很好的例子：目标是以最小的努力打开锁。 如果传感器是无线的，则创建图形界面是没有意义的。
如果您知道业务挑战和用户需求，则可以将此知识与技术知识相结合。 只有这样，您才有足够的信息来提出更好的解决方案，并了解该程序不需要接口。
除了用于实际打开锁的代码之外，
无需一行新代码即可解决软件问题的绝佳示例。 但是，
像技术职责一样 ，
没有任何理由可以证明对其他所有事物都不必要的编程。
并非每个代码都值得编写。
有时，修复严重的错误不是主要任务。 如果您是一家加密货币交易所，并且系统允许进行
两次存款 ，那么在成本效益比方面，如果解决方案的成本很高，则人为干预可能是最佳的解决方案。
重要性和优先级之间的这种权衡使我想起了一位
同事最近展示的模型。 它称为优先级矩阵-一种二维
模型 ，可用于根据受影响用户的严重性和数量对错误进行优先级排序。
优先级的二维矩阵。 纵轴表示值为“一个”，“几个”和“全部”的“受害者”数量。 横轴表示“严重”，值为“化妆品”，“不舒服”和“停止工作”。 错误的优先级取决于轴上的位置。 例如，如果错误是表面错误并影响一个用户，则优先级为4（最小）。 如果错误停止了某些用户，则优先级为1。如果停止所有用户，则优先级最高。上述双重存款问题属于影响
一个用户的
不便之类。 因此，优先级为3。
并非每个错误都值得修复。
开发人员经常试图预见所有情况。 但是某些重复性任务可能不值得自动化。 如果结果是隐藏了有关主团队工作的重要知识，则无需浪费时间编写脚本。
封装复杂的逻辑和有用的知识的抽象是有区别的。 有时只能理解清楚的信息。 如果我们抽象它，那么我们可以得到相反的效果：理解是困难的。
在CLI中使用某些类型的低级命令比具有抽象知识的高级命令（
例如Git别名 ）更有用。
并非每个团队都值得描述。
许多年前，我正在从事一个
增量交付的项目。 这是一个身份验证系统，要求用户提供一些个人数据以供第三方进行验证。
团队在那里想要对一种不寻常的现场验证功能进行编码。 但是，随着截止日期的临近，这种验证被推迟到每个种植者身上。 最后，他们认为此异常功能根本没有意义。
这就是为什么：已经强制进行验证！
提供可靠的信息符合用户的利益。 如果他提供了不正确的数据，则他们将无法通过验证，因此他将无法使用该系统。 此外，大多数浏览器都支持相当不错的标准HTML验证。
在最坏的情况下，如果无法验证用户，则他会致电支持部门进行手动验证。
并非每个函数都值得编码
如果您了解要解决的问题的本质，那么作为开发人员，您可以拿出更好的代码，有时甚至根本不需要代码。 您不是付钱编写任务行的
byldoder 。 您是获得报酬解决问题的专业人员。
但是，无需考虑技术问题，就好像程序代码是所有事物的通用解决方案一样。 否则，您将难以理解客户的需求并产生出色的想法。
代码的目标和任务是创造价值并使世界变得更美好，而不是满足您对世界应该如何的自我中心的想法。
俗话说：“如果只有锤子，一切都会变得像钉子。”
最好先看看钉子，以考虑需要锤子。
如果您真的需要锤钉子。