避免把路走窄,程序员须记住:解决问题比写代码更重要

简介: 当你手里有把锤子的时候,看所有的东西都是钉子。有时候程序员往往会陷入为了写代码而写代码的怪圈,没有意识到代码是为了解决现实问题的。当问题有更简便的解决方案时,写代码未必就是必须。记住:你不是别人花钱让你在屏幕上写字符的程序猿,而是让你解决问题的专业人士。Fagner Brack的总结非常有见地。

当你手里有把锤子的时候,看所有的东西都是钉子。有时候程序员往往会陷入为了写代码而写代码的怪圈,没有意识到代码是为了解决现实问题的。当问题有更简便的解决方案时,写代码未必就是必须。

记住:你不是别人花钱让你在屏幕上写字符的程序猿,而是让你解决问题的专业人士。Fagner Brack的总结非常有见地。

程序员似乎已经忘记了软件的真正目的是什么,是解决现实世界的问题

锤子摆在一块木板上。木板有一颗被锤弯的钉子。

程序员似乎已经忘记了软件的真正目的是什么,是解决现实世界的问题。

50年前的1968年开过一场会,会议名字叫做软件工程工作会议,是有NATO科学委员会赞助的。那时候大家已经开始注意到软件日益成为社会的基础。然而,软件也变得太难以理解。在那次会议之后,变成开始变成一个行业。软件开始摆脱商业人士的控制。

不管软件此后走上了什么样的发展道路,仍然存在着业务与软件开发(或者按照那次会议首次的说法,“工程”)分离的问题。如果开发者太过狭隘地专注于开发,就会错过了他们编写的软件背后的目的。以至于可能会看不到并不需要编写任何代码的潜在解决方案。

举个例子。

有一家初创企业是做设备的,这种设备可以让人利用蓝牙解锁开门。跟这种设备进行通信的可视化界面是一个小程序,就算是门锁上它也能看见。有一个按钮叫做“开门”。

当用户接近房子时,他们会拿出手机,找到那个小程序,然后点击按钮开门。

有人看过这套流程之后问道:

如果我们用的是蓝牙并且假设拿着这部手机的任何人都能进入房子的话,为什么还需要让某人拿出手机然后按按钮呢?当它检测到设备距离在1米之内时让他们打开不就行了吗。这样我们就不用付出设计和编写可视化界面的成本了!

这个蓝牙应用的故事是聚焦过窄的绝佳例子:目标是用尽量方便地开门。如果传感器是无线的话设计可视化界面毫无意义。

如果你意识到企业想要实现什么以及对用户的价值是什么的话,你可以将哪方面的知识跟你对技术可能做到什么的知识融为一体。只有这样你才会具备足够的信息来想出更好的答案并且得出结论说界面对产品来说毫无必要。

这是一个解决编程问题的出色例子——除了编写解锁功能以外再无编写任何额外代码之必要。然而,就像技术债务一样,任何东西都不应该用来作为编写垃圾代码的借口。

不是所有的代码都值得编写

有时候,修补重大bug未必是优先事项。假设你是加密数字货币交易所,如果你的系统允许出现一次账户副本的话,人为干预会是成本效益最佳的解决方案——如果修补漏洞的代价很大的话。

严重性于优先级之间的权衡让我想起了同事最近给我看过的一种模型。这个模型叫做优先级矩阵这是一个二维模型,可用于确定bug的优先级,其根据是影响到的用户数以及严重性。

image

二维优先级矩阵图示。Y轴表示受影响的用户,分别包含“一个”、“一些”以及“全部”这些值。X轴表示“严重性,值包括“界面性”、“造成不便”以及“无法工作”。Bug的优先级多少要取决于它在坐标上的位置。比方说,如果ug是界面性的而且仅影响到一个用户的话,则优先级为4;如果bug让某人无法工作而且影响到一些人的话,则优先级为1;如果bug导致所有人都无法工作的话,则优先级为最高,0。

前面说过的单账户副本问题算是影响了一个用户的使用便利性这类,因此其优先级为3。

不是所有的bug都值得修复

开发者想给一切都写脚本是非常常见的。然而,一些重复性的任务未必值得自动化。如果你打算隐藏一些有关底层命令如何工作的基本知识的话,就不需要花时间去写脚本了。

服装复杂逻辑和抽象有用知识之间是有区别的。有时候,信息应该明确表示方便理解。如果你对信息进行了抽象的话,可能反而产生相反效果并且难以理解。

在CLI里面使用一些类型的低级命令而不是抽象了知识的高级命令(如Git aliases)会更有用。

并不是所有的命令都值得写脚本

几年前我用Incremental Delivery做了一个项目。这是一个身份验证系统,系统会让用户提交一些个人数据,让第三方提供商进行验证。

团队想要开发一个非常棒的字段验证功能。然而,验证这个功能每次sprint计划都被列到低优先级的位置,眼看着截止期限越来越近了。到最后,团队发现这项功能根本就没有必要。

原因是:验证是必须的!

提供合法信息关乎用户的利益。如果用户提供的数据是错的,验证就不会通过也就无法使用系统。此外,大多数浏览器都支持标准的HTML验证,这已经足够了。

最糟糕的情况下,本人无法验证通过的用户会打电话给支持进行人工验证。

不是每一项功能都值得编写

作为开发者,如果你理解了自己试图要解决的问题的话,你就能想出更好的代码,甚至有时候根本不需要编码。你不是别人花钱让你在屏幕上写字符的程序猿。你是别人花钱来帮忙解决问题的专业人士。

不过,如果试图不经思考只想用技术解决每一个问题,就好像把代码当成银弹的话,你就很难理解什么东西对客户有价值,也很难想出很好的点子。

你的目的以及所写代码的目的都是为了产生价值,让世界更美好,而不是为了满足你以自我为中心的世界观。

有句话是这么说的:“当你手里有把锤子的时候,看所有的东西都是钉子。”

最好还是先有颗钉子这样你才会考虑需要一把锤子。

也就是说,如果你本来就需要钉子的话。

原文发布时间为:2018-07-04
本文来自云栖社区合作伙伴“Java程序员联盟”,了解相关信息可以关注“Java程序员联盟

相关文章
|
1月前
|
设计模式 算法 程序员
程序员为何需要反复修改Bug?探寻代码编写中的挑战与现实
作为开发者,我们在日常开发过程中,往往会遇到反复修改bug的情况,而且不能一次性把代码写的完美无瑕,其实开发项目是一项复杂而富有挑战性的任务,即使经验丰富的程序员也难以在一次性编写完美无瑕地完成代码,我个人觉得一次性写好代码是不可能完成的事情。虽然在设计之初已经尽力思考全面,并在实际操作中力求精确,但程序员仍然需要花费大量时间和精力来调试和修复Bug。那么本文就来分享程序员需要反复修改Bug的原因,以及在开发中所面临的复杂性与挑战。
35 1
程序员为何需要反复修改Bug?探寻代码编写中的挑战与现实
|
6月前
|
测试技术
解决Bug应有的心态和解决方法的一些思路、方法和心得
永远要相信程序是不会骗你的,是自己在处理理逻辑中出问题,而在特定的环境中才会出现或者是自己压根就想不到情况下出现。 前几天在处理一个接口任务时,在测试环境跑是一点都没有,但在正式环境却没有将数据拉下来。没有报任何错误,一度怀疑、抱怨! 还好最后找到问题解决了!
33 0
|
27天前
|
算法 程序员
为何程序员在编写程序时难以一次性将所有代码完美无瑕地完成,而是需要经历反复修改Bug的过程?
为何程序员在编写程序时难以一次性将所有代码完美无瑕地完成,而是需要经历反复修改Bug的过程?
18 7
|
2月前
|
数据可视化 测试技术
测试范围不清晰该咋办?
测试范围不清晰该咋办?
|
7月前
|
安全 测试技术
不会写测试用例咋办?牢记这5点,你也能写出高逼格案例
不会写测试用例咋办?牢记这5点,你也能写出高逼格案例
|
10月前
|
架构师 测试技术 uml
这才是业务用例,别再搞错了!
这才是业务用例,别再搞错了!
303 0
|
Java C语言
看似无害的代码如何搞垮系统
编程就像魔法。最近遇到一个诡异的问题:添加一段看似无害的简单代码后,系统原有功能不可用了。 ## 复现演示 jdk 8 可使用如下演示代码复现这个问题。 `TaskCenter` 是一个任务框架,可添加多个任务,随后框架将执行这些任务。 `First` 任务是新增代码,看起来简单无害,且看不出对原有任务 `Count` 有何影响,但添加 `First` 任务后,其自身执行正常,原本正常的 `C
|
测试技术
零基础学软件测试难吗 选好合适的学习方式就不难
近些年,软件测试岗成了我国最受欢迎的就业技术岗位,因为工资高,还不需要加班,所以越来越多的人想要转行到了软件测试行业,而这其中也包含了80%没有任何计算机基础的外行人员,那么零基础学软件测试难吗?
150 0
零基础学软件测试难吗 选好合适的学习方式就不难
|
设计模式 Java 程序员
怎样才能写出规范的好代码?
最近发现一件事情,自己写的代码和公司里工作5到10年的前辈写的代码虽然功能一样,但是他们的代码更规范,更优雅。比如有时候我会给一个需求写一个方法,但是有些人就可以好几个需求通过同一个方法实现。因此有了今天这个疑问,怎样才能写出规范的好代码?