被劣质代码“残害”的这些年

发布于:2020 年 3 月 31 日 16:14

被劣质代码“残害”的这些年

都已经 2020 年了,但我们仍然在生产劣质软件。自从计算机诞生以来,已经过去了近 70 年,但我们似乎还没有吸取所有的教训,仍然在犯着重复的错误。

科技行业的变化日新月异,或许今天看起来有意义的事情五年后就失去了其意义。我认为,这正是软件的一个迷人之处,因为它的可塑性很强。但是有一件事是不变的,那就是劣质软件带来的糟糕体验,我们似乎短期内无法克服它。

现在,开源生态系统中的优秀软件多如牛毛,以至于人们误以为劣等软件已经成为过去。其实不然,尽管开源软件在过去十年里呈现出爆炸式增长趋势,但这其中依然混迹着不少非常糟糕的软件,我每天都在“深受其害”。

劣质软件缘何而来?

编写优秀的软件的确很难,但这不能成为产出劣质软件的借口。你每天都在使用优秀的软件,所以应该知道如何来编写优秀的软件。优秀的软件总是“润物细无声”,在你没有察觉时就已完成了工作,而糟糕的软件会把你逼向崩溃边缘。但是,通常情况下,你不会看到或使用到特别多的糟糕软件,因为我们日常生活中使用的大多数软件都是消费软件,糟糕的软件无法在消费市场生存,但糟糕的软件确实存在,这是不争的事实。

据我所知,糟糕的软件在企业生态系统中普遍存在。最主要的原因有以下几点:

  • 在企业环境中,人对系统更加宽容;
  • 普通软件研发人员比消费市场型软件研发人员要少,普通软件开发者对于他们自己编写软件没有投入感情;
  • 软件所做的大部分工作是以机器对机器交互的形式完成的,当某些东西不能工作时,机器检查问题的能力不足;
  • 大多数情况下,编写企业软件的人不如为消费市场编写软件的人更了解他们的最终用户和他们的问题。

被劣质代码“残害”的这些年

糟糕的软件是缺乏思考和错误决策的结果。每一行代码都很重要,每一个接触软件的人都会对其产生影响,甚至每一个决策都会影响软件的设计走向。如果你不编写单元测试,而是利用编写单元测试的时间来进行一些新特性的开发,那么这时系统中的 Bug 就会无孔不入,这种目光短浅又无知的决定是对几十年来积攒的经验智慧的一种亵渎。

软件不只是一个冰冷的机械,它也有情感。你可能会问为什么?因为它是工程师的逻辑和情感状态的精确体现,工程师开发软件时并不是只有一种情绪,软件是在工程师的多种情绪和状态下编写而成的,或难过、或开心、或高兴、或生气、或激动、或厌烦、或充满斗志,抑或沮丧憋闷,软件既能反映工程师的情绪,还能反映出工作场所的文化氛围。糟糕的企业文化几乎总是会产生糟糕的软件,这是显而易见的,因为大多数组织在规模变大后却因为糟糕的企业文化而最终衰败。

劣质软件带来的恶果

糟糕的软件会陷入恶性循环。技术债务不断堆积,会议越来越多,完成的工作却越来越少。会议上净是些陈词滥调的方法和管理实践,却没有人懂。糟糕软件就像癌症,大多数时候在最后阶段才显现出来,它会带来非常严重的后果,它也会降低工作效率,让人失去动力。软件工程是一项充满创造性的工作,但糟糕的软件会把工程变成维护工作。花在 Bug 修复上的时间比花在为改善终端用户体验上的时间要多。公司内部的一些问题开始渗透进来。虽然糟糕的软件是源于失败的团队,但是没有人承担责任,大家开始相互指责,在此情况下很容易滋生腐败,最终让员工备受煎熬。简而言之,糟糕的软件就是糟糕的企业文化的缩影。

被劣质代码“残害”的这些年

Bug 是软件工程中不可避免的存在,但是如果 Bug 一直存在下去,那就是危险的信号,它会产生连锁反应。由于没有动力和缺少奖励,情况会变得更糟,在一切以交付为首要目标的情况下,鲜有人会对软件进行改进或在其中增加新的特性。它变成了一个没人敢碰的、失控的烂摊子,后患无穷。

如何改善劣质软件?

如何将糟糕的软件变成优秀的软件?这是个棘手的问题。我虽然不是专家,但我也愿意在这里与读者分享我的观点。首先,它变得如此糟糕,很大程度上说明了该组织的文化也出现了严重问题。改变文化比改变代码要难得多。文化是一个组织的支柱,即使有望改善它,也要面临很大的阻力,因为已经投入的资源是一个更大的问题,预防胜于治疗。

关于这个主题的文章不多。也许这个行业发展得太快了,以至于人们都来不及进行反思,或者与其把精力浪费在写作上,不如去解决其他紧迫的问题。总有更多的东西被发明,更多的问题等待着我们去解决,更多的工具要开发,但投入一点时间反思将有助于整个行业的发展。

原文链接:
https://techimadions.com/the-misery-of-bad-software/

阅读数:2487 发布于:2020 年 3 月 31 日 16:14

更多 语言 & 开发、AI、编程语言 相关课程,可下载【 极客时间 】App 免费领取 >

评论 (1 条评论)

发布
用户头像
糟糕的代码真的有可能让所有努力付之东流
2020 年 04 月 01 日 14:11
回复
没有更多评论了
  • 程序员如何用技术变现(上)

    “手艺人”陈皓手把手教你如何通过自己的手艺“编程”变现。

    2017 年 10 月 10 日

  • 软件建模与设计文档学习总结

    第一周 软件建模与设计文档

    2020 年 6 月 9 日

  • 如何在更少的时间内完成更多的工作

    由于不恰当的工作方式,Jason Lengstorf感觉自己的身体开始分崩离析,于是他决定将电脑使用时间限制在每周40小时,以90分钟为单位,培养一种高度专注的工作方式。减少工作时间可以防止过度疲劳或注意力不集中。我们应该像重视工作时间一样重视休息时间,利用休息时间进行创造性连接、充电并提醒自己我们工作是为了什么。

    2018 年 7 月 9 日

  • 第一周学习笔记

    软件架构 是有关软件整体结构和组件的抽象描述

    2020 年 6 月 10 日

  • 第 29 讲 | 被 80% 的人误解的工程师文化

    团队成员们做人做事的风格不完全一样,因此我们需要一种叫做“团队文化”的东西,通过它让大家的心聚集在一起。

    2018 年 6 月 4 日

  • 他们在努力工作吗?

    Esther Derby最近发表了一篇文章,提到“管理者思维”,及太关注员工个人发挥最大的能力,对团队合作、团队交付最大价值是有害的。她质疑了一种普遍的看法:团队需要“看上去”是在努力奋斗,才会被认为是工作“努力”。此文也提到了工作太长时间对生产效率的危害。

    2012 年 5 月 1 日

  • 实干家 vs. 理论家:可以工作的软件胜过面面俱到的文档

    在《你是实干家还是理论家?》一文中,Coding Horror的Jeff Atwood对敏捷宣言中的“可以工作的软件胜于面面俱到的文档”产生了共鸣。他通过引用John Taber的一篇文章,对交通运输学科研究和交通运输建设工程进行了对比。

    2008 年 1 月 17 日

  • 初心:为什么成为一名程序员?

    初接触程序,大学选专业和换专业,工作换城市和换行业……这几个重要的人生选择点,连起来就是我自己的成长线。从初心未明,到心已明、行将远。

    2018 年 8 月 3 日

  • Bug 的反复出现:重蹈覆辙与吸取教训

    为什么 Bug 总是反复出现?其中有哪些原因和教训呢?

    2018 年 9 月 3 日