Web 开发人员和认知偏差
在这篇文章中,我们将研究 Web 开发人员(尤其是前端开发人员)所陷入的一些认知偏见,这些偏见最终导致他们做出一些错误的决定,从而给他们的工作带来沉重的损失。
认知偏差基本上是由于各种原因而在情绪影响达到顶峰时做出的思考错误和错误判断。
这篇文章更多的是探索我们开发人员和工程师在日常工作所需的决策中如何无意识地屈服于认知偏见和思维错误。
这篇文章的灵感源于我读完The Art of Thinking Clearly
罗尔夫·多贝利 (Rolf Dobelli) 和Influence
罗伯特·西奥迪尼 (Robert Cialdini) 等人的著作。我希望分析、观察并总结我们在工作决策过程中所面临的各种偏见。书中大多数例子都与前端开发有关,但我确信这些偏见同样适用于 Web 开发的所有领域,例如后端、DevOps 等等。
社会认同
社会认同也被称为群体本能。这是开发者中最常见的认知偏差之一。
这种偏差的定义如下:
Individuals feel they are behaving correctly
when they act as the same as other people.
在前端世界中,使用某个 JavaScript 框架的人越多,我们就越认为或认为该框架比其他框架更好。
其他人都在用它,所以它肯定适合我们的项目。这种偏见在不确定的时候也会发挥作用。当你不确定自己的选择时,随大流是合理的。当你不确定自己的选择时,社会证据会产生很大的影响。
有时情况是这样的,我不知道该选择哪种工具,所以我会选择最受欢迎的工具并使用它。
默认效果
默认效应也称为现状偏差。
The Default Effect is a strong tendency to cling to the
ways things are, even it puts us at a disadvantage.
尽管现在生态系统中已经有更多更好、更高效、性能更好的工具,但人们仍然倾向于使用 create-react-app 来引导新的前端项目。
尽管有更好的选择,但人们倾向于使用像 React 或 Angular 这样的现状框架。
这是因为我们不想在为项目选择合适的框架上投入太多时间和精力。即使项目的性质和需求在各个方面都存在差异,选择大众的安全性也是一件简单易行的事情。
即使是经验丰富的开发人员和高级工程师,当他们想要避免花时间选择合适的框架或工具时,也容易成为默认效应的受害者。
游泳者的身体错觉
React 是否让你的前端变得非常棒?
This is a tendency to confuse selection factors with
results
选择正确的工具只是一个起点,工作只是完成了一半。仅仅因为你决定使用一个框架或库并不一定意味着它就能解决你所有的问题。它只是达到目的的一种手段。
游泳者的身体错觉倾向于得出错误的因果关系,例如“React 帮助我们构建出色的前端,因此所有出色的前端项目都使用 React”。
权威偏见
不要仅仅为了提高覆盖率而编写测试
It is a deep-seated sense of duty to authority within
us all.
我使用这个框架或库只是因为管理层告诉我们要这么做。也可能是高层管理人员(例如高管、经理或架构师)自上而下做出的决定。
这是由于对相关权威机构的专业知识缺乏信任而导致的状态。
无论何时做决定,都要思考哪些权威人士可能会对你的推理产生影响。当你遇到权威人士时,要尽力挑战他们,努力寻找反证。
可用性偏差
为什么我们更喜欢使用 Webpack 而不是任何捆绑器?
The tendency to create a picture of the world using
the examples that most easily come to mind.
这是一种宁愿接受错误信息也不愿没有信息的倾向。由于可得性偏差,我们倾向于仅根据现有或呈现给我们的数据做出错误的决定和判断。
对于前端开发者来说,这就像追逐热门框架、npm 下载量、GitHub 上最高星级的仓库,并根据热门调查做出关键决策一样。一个框架或库不流行或评分不高,并不一定意味着它不好或不值得。
沉没成本谬误
为什么你应该放弃 jQuery?
Sunk cost fallacy is most dangerous when we have invested a
lot of time, money, energy or love in something.
即使我们正在处理一个注定失败的事业,这项投资也成为我们继续前进的理由。
大多数时候,沉没成本谬误出现在团队或组织中,他们可能一开始就使用一个旧的、低效的便捷平台,并且由于业务和其他类似原因而非常不愿意改变或升级技术堆栈。
他们必须尽快放弃它并迁移,因为他们只是在浪费钱。说起来容易做起来难。显然,组织积累了太多的技术债务和维护任务,以至于它们从未得到优先处理,也从未真正被重视。
你的公司一开始就选择了一个方便的平台,结果却给自己挖了一个潜在的维护风险坑。所以,别再挖了,赶紧建个逃生梯吧。——
StackOverflow 评论
非我发明综合症
NIH Syndrome is a tendency that causes you to fall
in love with your own ideas.
一些组织和开发人员通常会在内部构建自己的工具、库和框架,这通常意味着一遍又一遍地重复做事,这是一种相当不常见的倾向。
这会导致大量的成本和精力浪费,因为市场上已经有高效且久经考验的工具了,他们只需要选择合适的工具并使用它即可。
这通常发生在一些不太热衷于使用或认可开源工具和库的闭源组织。他们制定了一项政策,限制开发人员在内部项目中使用开源代码。
幸存者偏差
为什么要检出已存档的 Github 存储库?
People systematically over-estimate their chances of success.
这就是重复造轮子的倾向。我自己在早期职业生涯中就多次陷入这种偏见。作为一名开源贡献者,我曾经想过要创建更多新的库和工具,但并不确定它们对公众到底有多大用处。
直到一段时间后我才意识到开源不仅仅是创造新的和闪亮的东西,更重要的是支持和维持生态系统。
许多刚进入开源领域的新人都想着以自己的名义创建下一个热门的 JavaScript 框架或库,然后发布到 npm。GitHub 上堆满了成千上万的存档/存储库。npm 上也有很多多年未更新的废弃和孤立软件包。
在决定创建一个新工具来解决新库或框架的常见问题之前,请三思没有它你该如何应对。你可以在现有软件包中创建问题,也可以为该问题创建拉取请求,甚至可以查看现有的拉取请求。许多开源维护者(包括我自己)都在努力保持他们的软件包更新、文档完善且不出现问题,如果我们充分理解幸存者偏差对我们思维的影响,就能做得更好。
集群错觉
为什么自动化对于边缘情况来说很糟糕?
The human brain seeks patterns and rules.
In fact, it takes it one step further: if it finds no
familiar patterns, it simply invents some.
倾向于将最枯燥的任务自动化,往往会给我们的模式识别能力带来一些麻烦。我们发现一个模式,并认为只要编写一个自动化工具来专门处理这些模式,我们的工作就完成了。但很多时候,我们高估了自己识别模式的能力,完全忽略了边缘情况或反面证据。直到最后一刻,我们才发现,我们解决手头问题的方法远比表面上看起来复杂得多。
行动偏见
为什么看架构图是一种折磨?
The tendency to look active, even if it achieves nothing.
这种情况发生在你直接开始通过编写代码来解决问题,而不是思考问题本身,并提出设计或架构来正确理解问题陈述时。在这种情况下,我们感到必须尽快编写代码。关于这个过程存在一些相互矛盾的论点,例如,这种方法可能适用于小型项目,但并不适用于大型项目。
行动偏见导致我们用徒劳的过度活跃来抵消不清晰的认识,当情况模糊、混乱或矛盾时,行动偏见就会发挥作用。
总体而言,组织仍然更青睐那些反应迅速的开发人员,而不是那些采取理性观望策略的开发人员。或者,更确切地说,组织更推崇“消防员”,而不是“消防预防者”。
新狂热
忽略全新的 JavaScript 框架
The mania for all things shiny and new
这种特殊的偏见在各种形式的文学作品、博客、书籍、文章和视频中已经被讨论过无数次了。然而,我们受其影响的次数比我们想象的要多。它指的是我们倾向于系统地选择或采用炫酷的新框架、库或工具,并渴望用全新的东西取代现有的旧东西。
这也部分归因于当前 JavaScript 框架生态系统的高度不稳定性,尤其是 Web 开发和前端领域。
根据这篇使用 Stackoverflow 统计数据的帖子,平均而言,小型 JavaScript 框架的生命周期约为 2 年,而大型框架则主导市场长达 8-10 年。
未来更新
我计划不断完善这篇文章,不断添加新的偏见或用更多示例更新现有的偏见。我的目的并非贬低某些流行的框架或库,而是指出我们在没有理性思考过程的情况下做出这些决策时思维的局限性和易错性。
请在评论部分让我知道您的想法和反馈,如果您觉得还有其他偏见,请随时在评论中添加它们,以便我可以将其添加到此处的列表中。
相关文章
- https://dev.to/andylim0221/the-art-of-thinking-clearly-book-review-4h0k
- https://dev.to/gtanyware/cognitive-bias-and-software-engineering-4cci
- https://dev.to/frosnerd/ten-cognitive-biases-to-look-out-for-as-a-developer-3bjm
- https://dev.to/x-team/12-hurtful-cognitive-biases-and-how-to-overcome-them-2m9j
- https://dev.to/johnpaulada/sense-driven-development-443
参考
图书
- 罗尔夫·多贝利的《清晰思考的艺术》
- 尼古拉斯·纳西姆·塔勒布的《黑天鹅》
- 受罗伯特·西奥迪尼的影响
- 《思考,快与慢》(丹尼尔·卡尼曼和阿莫尔·特沃斯基著)