有时候,解决问题比写代码更重要!
当你手里有把锤子的时候,看所有的东西都是钉子。
有时候程序员往往会陷入为了写代码而写代码的怪圈,没有意识到代码是为了解决现实问题的。当问题有更简便的解决方案时,写代码未必就是必须。记住:你不是别人花钱让你在屏幕上写字符的程序猿,而是让你解决问题的专业人士。Fagner Brack 的总结非常有见地。
锤子摆在一块木板上。木板有一颗被锤弯的钉子。
程序员似乎已经忘记了软件的真正目的是什么,是解决现实世界的问题。
50 年前的 1968 年开过一场会,会议名字叫做软件工程工作会议,是有 NATO 科学委员会赞助的。那时候大家已经开始注意到软件日益成为社会的基础。然而,软件也变得太难以理解。在那次会议之后,变成开始变成一个行业。软件开始摆脱商业人士的控制。
不管软件此后走上了什么样的发展道路,仍然存在着业务与软件开发(或者按照那次会议首次的说法,“工程”)分离的问题。如果开发者太过狭隘地专注于开发,就会错过了他们编写的软件背后的目的。以至于可能会看不到并不需要编写任何代码的潜在解决方案。
举个例子。
有一家初创企业是做设备的,这种设备可以让人利用蓝牙解锁开门。跟这种设备进行通信的可视化界面是一个小程序,就算是门锁上它也能看见。这个玩意儿有一个按钮叫做 “开门”。
当用户接近房子时,他们会拿出手机,找到那个小程序,然后点击按钮开门。
有人看过这套流程之后问道:
如果我们用的是蓝牙并且假设拿着这部手机的任何人都能进入房子的话,为什么还需要让某人拿出手机然后按按钮呢?当它检测到设备距离在 1 米之内时让们打开不就行了吗。这样我们就不用付出设计和编写可视化界面的成本了!
这个蓝牙应用的故事是聚焦过窄的绝佳例子:目标是用尽量方便地开门。如果传感器是无线的话设计可视化界面毫无意义。
如果你意识到企业想要实现什么以及对用户的价值是什么的话,你可以将哪方面的知识跟你对技术可能做到什么的知识融为一体。只有这样你才会具备足够的信息来想出更好的答案并且得出结论说界面对产品来说毫无必要。
这是一个解决编程问题的出色例子——除了编写解锁功能以外再无编写任何额外代码之必要。然而,就像技术债务一样,任何东西都不应该用来作为编写垃圾代码的借口。
不是所有的代码都值得编写
这里推荐一下我的JAVA架构学习交流群:835544715 ,想要学习Java高架构、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频都有整理,送给每一位JAVA小伙伴,有想学习JAVA架构的,或是转行,还有工作中想提升自己能力的,正在学习的小伙伴欢迎加入学习。
有时候,修补重大 bug 未必是优先事项。假设你是加密数字货币交易所,如果你的系统允许出现一次账户副本的话,人为干预会是成本效益最佳的解决方案——如果修补漏洞的代价很大的话。《告别狗屎代码,请记住这 11 条编码秘诀!》建议你看一下。
严重性于优先级之间的权衡让我想起了同事最近给我看过的一种模型。这个模型叫做优先级矩阵这是一个二维模型,可用于确定 bug 的优先级,其根据是影响到的用户数以及严重性。
二维优先级矩阵图示。Y 轴表示受影响的用户,分别包含 “一个”、“一些” 以及 “全部” 这些值。X 轴表示 “严重性,值包括 “界面性”、“造成不便” 以及 “无法工作”。Bug 的优先级多少要取决于它在坐标上的位置。
比方说,如果 ug 是界面性的而且仅影响到一个用户的话,则优先级为 4;如果 bug 让某人无法工作而且影响到一些人的话,则优先级为 1;如果 bug 导致所有人都无法工作的话,则优先级为最高,0。
前面说过的单账户副本问题算是影响了一个用户的使用便利性这类,因此其优先级为 3。
不是所有的 bug 都值得修复
开发者想给一切都写脚本是非常常见的。然而,一些重复性的任务未必值得自动化。如果你打算隐藏一些有关底层命令如何工作的基本知识的话,就不需要花时间去写脚本了。
服装复杂逻辑和抽象有用知识之间是有区别的。有时候,信息应该明确表示方便理解。如果你对信息进行了抽象的话,可能反而产生相反效果并且难以理解。
在 CLI 里面使用一些类型的低级命令而不是抽象了知识的高级命令(如 Git aliases)会更有用。
并不是所有的命令都值得写脚本
几年前我用 Incremental Delivery 做了一个项目。这是一个身份验证系统,系统会让用户提交一些个人数据,让第三方提供商进行验证。
团队想要开发一个非常棒的字段验证功能。然而,验证这个功能每次 sprint 计划都被列到低优先级的位置,眼看着截止期限越来越近了。到最后,团队发现这项功能根本就没有必要。
原因是:验证是必须的!
提供合法信息关乎用户的利益。如果用户提供的数据是错的,验证就不会通过也就无法使用系统。此外,大多数浏览器都支持标准的 HTML 验证,这已经足够了。
最糟糕的情况下,本人无法验证通过的用户会打电话给支持进行人工验证。
不是每一项功能都值得编写
作为开发者,如果你理解了自己试图要解决的问题的话,你就能想出更好的代码,甚至有时候根本不需要编码。你不是别人花钱让你在屏幕上写字符的程序猿。你是别人花钱来帮忙解决问题的专业人士。
不过,如果试图不经思考只想用技术解决每一个问题,就好像把代码当成银弹的话,你就很难理解什么东西对客户有价值,也很难想出很好的点子。
你的目的以及所写代码的目的都是为了产生价值,让世界更美好,而不是为了满足你以自我为中心的世界观。
有句话是这么说的:“当你手里有把锤子的时候,看所有的东西都是钉子。”
最好还是先有颗钉子这样你才会考虑需要一把锤子。
也就是说,如果你本来就需要钉子的话。
想要学习Java高架构、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频免费获取 架构群:835544715
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
IT公司老板落水,各部门员工怎么救?
公司高层 公司副总A:咱们开个会研究一下这个事情怎么处理。 公司副总B:如果老板没有救成功,下任是谁呢?会不会影响公司的上市? 公司副总C:我认为咱们开会应该讨论两个方案,一个是救人方案,一个是危机公关方案。 公司专聘高级管理专家:作为公司高管,听到公司老板落水,第一时间电话秘书部预定会议室,紧急召集公司全体会议。会上先摆明问题,说明事情严重性,要求大家集思广益,头脑风暴讨论拯救方法。工会,就会议中提及的N种方法进行投票,根据民意选出前五种方法。公司高管立即成立拯救小组,并亲自担任组长。要求组内根据五种援救方式分为五小队,并认命队长,直奔公司领导落水处展开救援。就地安营扎寨,准备紧急生活用品、援救设施,认命第一小队作为突击队,直奔落水地点考察,收集最新资料,并整理成文档,进行汇报,由援救小组组长、副组长先进行救援可行性研究,上报质量管理部门,申报可救援执照。 (PS:如果这样,那老板会不会早已经漂到长江下游了,被钓鱼者发现,雇佣他做保镖直接打跑那个出主意的专家?) 公司副总D:嘘!专心工作,老板是游泳高手。 公司副总E:为了防止万一,我还是吩咐各部门准备营救方案吧。 小秘书:(边记录边...
- 下一篇
程序员因太过耿直,致苹果官网出现bug......
产品的绝大部分bug,会在测试阶段被消灭,但仍然有不少的bug,脱离测试工程师的魔掌,展现在了用户面前。有些bug十分影响用户体验,不过有些bug,反而会娱乐大众,让人笑翻了天。 中国高铁,已经让外国人领略到,什么是中国速度。“复兴号”高铁已经可以达到350km/h,让外国人震惊不已,可这还不是极限速度。 当高铁荧屏上,速度显示出现bug时,速度即可达到55785km/h,这个速度都超越宇宙第三速度了,这样一来,这列高铁,可以直接摆脱太阳系,甚至冲出银河系都不是梦。 欢迎您乘坐G2333次和谐号动车组列车,本次列车开往冥王星北站,沿途停靠火星站、土星北站、天王星南站…… 蒂姆·库克:小王啊,你去把台湾官网左上角的“Jobs at Apple”改成繁体字。 小王:“好的。” 于是苹果官网左上角真的变成了繁体字! 这里推荐一下我的JAVA架构学习交流群:835544715 ,想要学习Java高架构、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频都有整理,送给每一...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Red5直播服务器,属于Java语言的直播服务器
- SpringBoot2全家桶,快速入门学习开发网站教程
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8编译安装MySQL8.0.19
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS关闭SELinux安全模块