30 年间，软件开发行业为何 Bug 纷飞？

最新推荐文章于 2022-07-16 10:11:52 发布

CSDN资讯

最新推荐文章于 2022-07-16 10:11:52 发布

阅读量1.1k

点赞数

原文链接：https://edu.csdn.net/huiyiCourse/detail/1100

版权

在时间的推移历程中，软件行业早已发生了天翻地覆的变化。和曾经大家习以为常的编码日常相比，越多越多的开发者发现，如今“测试驱动开发，开发让位测试”却成为了一种常态，究竟是什么导致了这样 Bug 的出现？本文作者将从其自身三十年的软件开发经验出发，带领我们共同探寻真相。

作者 | Chris Fox

译者 | 弯月，责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

我原本打算以第三人称撰写这篇文章，希望能够客观地描述三十年来我目睹的软件开发行业的变化。然而，写到一半我又改变了注意，所以我将在本文中讲述个人的亲身经历，然后再简单地分析一下哪些因素导致了如今的软件开发世界里出现了诸多荒谬和错误。

致年轻的开发者

许多人正值风华正茂，他们未曾见过软件开发旧日的美好时光，所以他们也不理解我对以前美好的工作环境的无限怀念，他们不明白我们能够在无人打扰的环境中工作是多么至关重要。就像我的一些越南学生，十几岁的他们没有听过甲壳虫乐队，也不明白我们为什么会将这个乐队视为珍宝，如果二三十岁的你们没有见过软件公司的员工频繁被各种对话打断，而无法长时间地集中精神工作的情景，那么可能就无法想象那是一种怎样的情形。我觉得你应该试着想象一下。

我想重新唤回人们的这种意识。我不关心敏捷、Scrum或极限编程，这些只是一时的狂热，很愚蠢而且会干扰注意力，所以根本解决不了问题。我可以毫不夸张地说，微软早期的杰出表现正是因为他们建立了不打断他人注意力的企业文化，而这种杰出表现消失的直接原因也是因为他们放弃了这种意识。

本文参考了《Flow: The Psychology of Optimal Experience》，如果你希望了解学术的研究结果，那么可以读一读这本书。

早年的经历

我从1988年开始以编写软件为生。一年后，我去了微软，我在单人办公间工作，鲜有人打扰，但那是在微软享有此殊荣的最后一年。回想那时的感觉真是太棒了：我们就像王子一样，我们的工作效率之高也是空前绝后。公司围绕《Flow》建立了一种文化，让我们能够进入并保持这种状态，因为这正是我们最佳的工作方式。

《Flow》的伟大之处

虽然在我进入微软前不久，他们就举行了首次公开募股，但公司真正的变化始于1990年5月发布的Windows 3.0。我们的工作环境在一夜之间发生了巨大变化：我开始和一个烟鬼共用一个办公室，他整天大声地打电话。与此同时，我们的会议也越来越多。

1989-2009年间，我一直在微软工作，差不多一半时间是全职工作，一半时间是合同工，然而情况每况愈下，最后是Windows Vista项目。

伟大的堕落

我的人生从未如此疲惫，承受的压力也从未如此之大，我们就像奴隶一样，每周工作70个小时以上，然而，幸运的话也只能完成4-6个小时的实际工作。其他时间都在与代码管理系统苦苦作斗争，那个系统里到处充斥着尚未完成或质量低劣的功能。

2009年的时候，一切都陷入了混乱。人们对质量的热爱完全被机械化的检查框方法所取代，有几次我都在绝境中挣扎。1989年的时候永远不会发生这样的事情，因为那时严谨才是最崇高的美德。我为Windows Media Player DRM准备的威胁模型有20页之多，里面写满了漏洞和缓解措施，但是他们要求只能有1-2页，因为每个漏洞都需要经过审查然后解决掉。

卓越消失了、死了、被掩埋了。2008年底，我的经理要求我在应用程序外部编写蹩脚的代码，以方便他们在这些代码上运行单元测试（目的只是为了证明该项目“有单元测试”），于是我决定跳槽。当他告诉我一个名叫“测试驱动开发”的新事物时，我决定更新自己的简历，然后离职。可惜我没有立即付诸行动，没想到后面还有更糟糕的事情。当他们让我做结对编程的时候，我愤然离职了。

十年前：敏捷

我曾在西雅图市中心的Real Networks工作。西雅图的交通是个大问题，很多人的人生使命似乎就是造成堵塞交通。但是，由于我一般都在9:30离家，早高峰已经过去，路上只需要花费30分钟，因此还算不错。

后来，我们团队开始尝试一种名叫“敏捷”的新事物。对我而言，这意味着我必须参加“清晨站立会议”，会议在8:30举行，因此我到达办公室的时间需要提前90分钟。这意味着我不得不在早高峰期上路，原本30分钟的路程现在变成了90分钟，每次我都会迟到而且感觉筋疲力尽。我问他们是否可以推迟会议。他们说，不行，这可是清晨站立会议啊。（可是，我们并没有站起来啊）。

这个会议本身也极其荒谬。参加会议的每个开发人员几乎都会说他正在继续昨天的工作，偶尔也会提到开始了某个新工作，目前尚无进展。

项目经理的表现则更糟，他看上去总是生气勃勃的样子，声音欢快而愉悦，听起来他“参与了很多工作”，但实际上我知道大部分时间里他们都在Facebook上玩游戏。我经常听他们提起“故事”，后来才意识到这不是指某款我们正在发售的游戏。请问，“故事”究竟是什么意思？

后来，我发现“故事”指的是我们所说的用户场景、使用案例。我对敏捷的了解越深，我遇到的新名词就越多，然而迄今为止，我还没有看到太多的附加值。不过，还有更多会议。

我抗议“故事”。这个词感觉很幼稚，就像强迫收银员穿上可笑的服装搞促销活动或庆祝假期。他们告诉我，就像开会一样，“故事”也是敏捷的一部分，我们需要遵守这些规则。然而，我感觉“Scrum”不过就是报告进度，为什么我们不能像过去20年一样通过邮件直接报告？

就因为这些无厘头的原因，我就需要在上下班的路上多花一个小时（无偿）。真是个无畏的新世界。

独立工作

2010年，我去了越南两次，去看我的新房子，第一次去的时候还在建，第二次在里面住了三个星期。在我与Real的合同多次续约的过程中，有一半的同事都被解雇了，但最终我的合同也结束了，很长一段时间以来最愉快的一段工作结束了。我跟每个人相处得都很融洽，而且也取得了一些重大成就，公司里唯一的一个混蛋没有与我共事，而且在一次裁员中也被裁退了。

我在越南的家

我打算到2019年退休的时候就搬家。每次想到沉闷的白板面试和一系列高压力的工作，我就浑身难受，我非常享受在美丽的新家的生活，所以我决定打包出发，2010年11月15日我离开了美国，打算在56岁的时候退休，弹弹吉他，看看物理书籍，在一个非常陌生的语言环境中生活，放松身心。

后来，我学会了说越南语，否则我会无聊。我是闲不住的人。

一位朋友建议我学习 iPhone 和 iPad 编程，这些工具都是免费的，而且我怀念编程。于是，我购买了MacBook，学习了iOS、Objective C 和 XCode，而且很快就构建了一款应用。我又一次回到了软件开发的世界。

2011年-2016年间，我先是为自己，后来又为客户编写 iOS 和 MacOS 应用程序。这虽然很好，但我想赚更多钱，所以我找到了自由职业中介所。2017年，我获得了在加利福尼亚的一家公司从事服务器端工作的机会。我学习了C#、实体框架和 ASP.NET，后来当初推荐了我的朋友离开了公司，于是我接管了服务器和数据库。这份工作一直持续了30个月，是一段愉快的经历，我掌握了一些最新的技术。我喜欢服务器和数据库。

这期间内我一直是单独工作。我是团队的一员，我们的团队成员包括：一位居住在悉尼的浏览器开发，还有身在越南的我。我们需要协作开发REST API，但我们两个都是独立工作的。

令人费解的当前世界

去年8月，那份工作结束了，我发现找远程的工作很简单，我的独立性和承担责任的意愿都是优秀的品质。

然而，我发现软件行业发生了翻天覆地的变化。

术语和时尚

“故事”仅仅是个开端。在我之前的工作中，有两名开发主管在讲话的时候喜欢使用一连串的术语。除了“工业标准”之类争论时常用的词语外，还有“技术债务”实际上只是“未完成的工作”的婉转说法。“分支清理”的实际意思就是针对Git分支上积累的提交记录做无用功。

如今，这个行业到处都充斥着术语。“敏捷”无处不在，意味着每个人都有不同的理解。“重构”也是如此，虽然我认为它只是“编辑”的同义词。“冲刺”是一个小里程碑，带有加班的含义，但也没有任何新意。

原来我们会说用户场景、未完成的工作和编辑，只要我还在这个行业里，这些旧的术语对于我来说也挺好。小小的里程碑也没有革命性。加班，就更加无需我多说了。

如果非要我参加“冲刺回顾会议”（“花4个小时来讨论我们刚刚学到了哪些团队合作知识”），我会发疯。

除此之外，还有一堆的其他会议，毫无新意。

独立而又自负

这是让人不寒而栗的思想：虽然我可以独自管理大型项目，但我算不上杰出的开发人员，我们是自负的“暴君”，我们的下场是被降职或解雇。这全都是为了团队精神：一起工作，一起在上班时间玩游戏，站在桌子上，高举着酒杯为团队鼓舞士气，还有结对编程等等。

这简直形同身于地狱的最深处。

奇怪的是，求职广告似乎仍然偏爱那些可以独立工作、不需要监督以及高度主动的开发人员。也许需要别人来告诉他们，这样的开发人员都不好，他们应该雇佣可以像连体双胞胎那样工作的团队。

Flow的尽头

开放的办公室实际上形同虚设；协作式编程意味着不断与人交流，谁也别想舒服地坐着，本来这个过程的目的是代码审查，但实际上却完全不可能集中精力。持续不断的交谈，我们不能关上门保持沉默和集中注意力，戴着耳机就意味着你不配合团队合作。

Flow创造了过去的辉煌，而它已离我们远去，如今平庸却成了可达到的最高标准。

开发让位于测试

这可能是软件开发界最怪异的变化。

诚然，过去我们没有认真对待测试。微软经常开玩笑说，大家都不应该使用版本号为偶数的软件，因为这些软件在等着用户报告错误。请勿使用2.0版，因为2.1版将修复客户报告的所有错误，至少会修复值得修复的bug。

我笑不出来。

我认为如今受“测试驱动开发”这一荒谬方法论的刺激，我们表现出了过激的反应。

测试驱动开发是这个错误的根本。

很多网上的讨论都说，软件中没有什么比单元测试更重要的工作了，单元测试比它们比可交付成果本身更重要，文档已经过时，单元测试就是设计文档，单元测试定义了API；根据完整的设计编写测试太不够格，在实现前根据猜测编写测试才是时尚；不足100%的覆盖率就是玩忽职守，100%的覆盖率才是荣耀，开发人员应该全权负责测试他们产品，我们不需要黑盒测试，也不需要找别人再看一眼。

这些态度的偏执根本不需要我来指出。

任何一个有经验的人都能看出最后一个的荒谬。我们每个人都有盲点，我们会忽略某种情况，我们肯定会在编写测试和在编写代码的时候漏掉某些情况。这是人之常情，并不难理解。