作为一名开发者，它把我惹毛了！！
共 2005字，需浏览 5分钟
·
2021-03-15 04:18
论让开发者不开心的二三事。
老实说，想要惹毛一名开发者很容易。有时候，一件不起眼的小事情也可能会触发程序员敏感的神经。个性越鲜明的开发者，越容易炸毛。在我看来，开发者、程序员和工程师人群的整体氛围堪称“有毒”。
直至今日，还有很多人在大张旗鼓地讨论，什么样的人算是初级开发人员，什么样的程序员又能被称为大神。同时，当一些工程师被称为“码农”时，也会非常生气。
除了以上，开发者群体中还有很多雷区，接下来，我将盘点其中的一部分，顺序不分先后。不过，因为经验、技能和理念的不同，开发者们炸毛的程度也会有所不同。
If-else 与多态
还记得，我曾经发布过一篇《停止使用 If-else》（https://medium.com/swlh/stop-using-if-else-statements-f4d2323e6e4）文章，那个时候的我，还不知道自己捅了多大的一个“马蜂窝”。
不到几天的时间，这篇文章浏览量就 10 万+（这在国外内容 Medium 平台上算是爆款文章了），同时在 Reddit 上还有一个关于这篇文章的讨论区，里面充斥着很多反驳的评论。显然，按照传统分支编写那种不良代码的做法至今仍有大批开发者，使用 if-else 就是如此。
让非技术人员来评估编程任务
刚接触编程时，我的第一个项目竟然是由一个政治学硕士出身的同事进行评估的。当时我们必须在项目期间从零开始完成整套的解决方案，包括部署三个云环境、创建数据库模型、编写业务逻辑，编写后端和前端。
他当时在评估之后，给出的预估计时间是 34–36 小时，以及需要一名开发人员的支持。万万没有想到的是，他在评估结束之后，直接把这些时间表就发给了客户，甚至都没有问过作为开发者的我们切合实际的开发者周期究竟是多长时间。
正如不懂技术的产品经理提出了一个天马行空的想法让技术来实现，像这样的破事儿毫无疑问会惹毛开发人员。
“按照我的经验，XX种技术行之有效”
很多文章常常试图挑战别人做事的方式。就我自己而言，我经常会收到这种评论，“我已有 20 年的工作经验了，并且我总是以相同的方式来完成 X 任务，而且这样行之有效”之类的。
通过这种言论，我们能知道过去 20 年来，他/她的代码风格一直没有改变，而且阅读那篇文章的目的就是因为希望证明他们古老腐朽知识仍然适用——但令他们失望的是，他们的知识已经并不适用了。
阅读其他人的代码
有时候我们真是讨厌死其他开发者的代码了。尤其是当我们不确定它的实际功能时，我们就喜欢疯狂吐槽这段代码有多么愚蠢（以掩盖我们看不懂这段代码的事实）。
在没有注释的情况下，当接手别人的代码时，任何一个细节都可能激发开发者的厌恶情绪。包括一些大括号之类的小事，不论是放在同一行，单独成行，或K＆R风格，都无法让所有人都满意。如果去 Google 一下关于大括号的争论，它的问题会让你越看越傻眼。
此外，Tabs 键和空格也会让开发者很无语。
代码审查和 pull request
在开发者群体中，code review 和 pull request 是备受争议的两个关键点。
code review 就像是公开邀请“羞辱”他人的编程能力。或者，至少有些人就是这样看待 pull request 的。当你花了很多时间准备好将功能合并到主版本中时，你的代码却被没有参与项目的其他人破坏了，还有比这更让人恼火的事吗？
从本质上讲，code review 和 pull request 是一个开放的舞台，允许别人对你所编写的代码自由评论。
代码注释，真的有帮助？
对于代码注释，不同的开发者有不同的看法。有人认为，代码注释在代码审查期间会吸引开发者很多注意力，在他们看来，“如果还需要注释，只能说明你的代码不够清晰。”
不过，多年的事实证明，认真的给代码写注释对后来阅读代码的人会有很大的帮助。甚至未来有一天，你自己也会庆幸当初写了注释。
原文地址：https://levelup.gitconnected.com/how-to-piss-off-a-developer-eea2069633fc
作者简介：Nicklas Millard，FinTech行业C#后端开发工程师，曾在四巨头大厂担任高级技术顾问。
高级程序员必知的 7 种软件架构模式！
（干货）吐血总结：技术大佬都是怎么学习的？
面试官：如何发现 Redis 热点 Key ，解决方案有哪些？