原文地址：The Problem You Solve Is More Important Than The Code You Write
程序员们是否已经忘记软件的真实目标——那就是去解决真实世界的问题？
50年前，在1968年，由北约科学委员会举办了软件工程会议。在那时，人们开始注意到软件逐渐变成了社会的基本组成部分，然而，它也变得越来越难理解。在该会议之后，编程开始成为一整个行业，它也逐步脱离业务人员的控制。
从那时起，无论编程发展成什么样，一直存在着一个问题，即业务和软件开发的界限如何划分。如果开发者过于专注开发，他们往往会忽视正在开发的软件背后的目标。这样就会错过那些其实不需要任何代码的解决方案。
这里有一个例子：
有一家初创公司正在开发一款设备，目的是让用户可以通过蓝牙打开家门。和设备通讯的界面是一个widget组件，即使锁屏时也可见，那上面只有一个按钮“开门”。
当用户靠近家的时候，他们需要拿起手机，找到组件，然后按下按钮开门。
有人看了整个流程后，问道：
如果我们使用蓝牙，并且商业模式允许任何拥有手机的人进入房间，那为什么需要用户拿起手机按按钮？让设备探测手机距离，靠近1米时，自动开门就可以了。这样我们就不需要花精力去设计以及开发这个组件了。
这个关于蓝牙的小故事很好的说明了过于专注实现的结果。这个项目的目的是为了花最小代价地开门，那只要有无线传感器，设计用户界面就是没用的。
如果你了解业务目标和业务价值，然后把这些信息和技术可行性相结合，只有这样，才能让你有足够的信息去得出结论，那就是，这款产品不需要界面。
这个例子也很好的说明了，除了核心代码，如何不写代码去解决问题。当然，没有任何理由可以成为编写垃圾代码的借口。
不是所有代码都值得编写
有时候，严重bug的修复并不是高优先级的。这有一个案例，用户的存款记录会出现重复两条。如果解决问题的开发成本过高，人工干预可能是最佳的方案。
严重性和优先级之间的权衡让我想起最近一个大学同学跟我提及的模型。它叫做优先级矩阵，是一个二维模型，可以通过bug影响的用户数量和影响程度来决定bug优先级。
Y轴展示的是用户影响数量，值包含一个、多个、所有人。x轴展示的是严重性，值包含不好看、困扰、阻断工作。bug的优先级通过轴上的位置来决定，例如：一个外观问题，影响了一个用户，那优先级是4；一个问题阻断多个人的工作，那优先级是1；如果一个问题阻断了所有人的工作，那它就是最高优先级，0。
上文提到的那个重复存款记录的问题只是让一个用户使用困扰，所以，优先级是3。
不是所有Bug都值得修复
开发者常常会写代码去做任何事情。但是，一些重复度高的任务其实不值得自动化。如果只是为了隐藏底层命令如何运行，那没必要花时间去编写脚本。
对复杂逻辑的封装和对有用知识的抽象是有区别的。有时，传达的信息应该更直接，让别人便于理解；如果你抽象了它们，反而起到负面作用，会让它变得难以理解。
在命令行使用多种低级命令比使用抽象的高级命令（例如Git别名）更有用。
不是所有脚本都值得编写
几年前，我在做一个增量迭代的项目，这是一个身份验证系统，要求用户提交一些个人数据给第三方验证。
这个项目一开始准备做一个酷炫的字段验证提示特性。然而，随着截止日越来越近，这个功能的优先级在每一期迭代中都被往后排。到最后，团队认为，把这个酷炫的验证特性放在第一位开发是没有意义的。
原因是，验证是强制性的！
这个特性的目的是为了引导用户提供正确信息，但如果用户填了错误信息，他们就无法进入系统。所以，无论有没有这个功能，用户都会自发的提供正确信息。此外，浏览器自带的html验证功能已经足够好了。
在最糟糕的情况下，那些无法验证通过的用户更愿意寻求人工帮助来通过验证。
不是所有特性都值得开发
作为一个开发者，如果你理解你要解决的问题，你就有能力写出更合适的代码，甚至，不需要代码。你不应该被当做一个只在屏幕上敲字符的码农，你应该是一个专业解决问题的人。
如果你试图用技术去解决每一个问题，而不经过思考，把代码当做解决任何问题的银弹。你会变得越来越难理解你能给用户带去的价值，变得越来越难提出好意见。
你的目的，以及写的代码的目的都是去创造价值，让这个世界变得更好，而不是去满足你自认为的世界应该是怎么样的。
有句俗话：如果你有的只是一个锤子，那其他东西都看起来像一个钉子。
正确的应该是，先有一个钉子，然后你再考虑是否需要一个锤子。
也就是说，你首先需要一个钉子。
