如何惹毛一名开发者？

直至今日，还有很多人在大张旗鼓地讨论，什么样的人算是初级开发人员，什么样的程序员又能被称为大神。同时，当一些工程师被称为“码农”时，也会非常生气。

除了以上，开发者群体中还有很多雷区，接下来，我将盘点其中的一部分，顺序不分先后。不过，因为经验、技能和理念的不同，开发者们炸毛的程度也会有所不同。

让非技术人员来评估编程任务

刚接触编程时，我的第一个项目竟然是由一个政治学硕士出身的同事进行评估的。当时我们必须在项目期间从零开始完成整套的解决方案，包括部署三个云环境、创建数据库模型、编写业务逻辑，编写后端和前端。

他当时在评估之后，给出的预估计时间是 34–36 小时，以及需要一名开发人员的支持。万万没有想到的是，他在评估结束之后，直接把这些时间表就发给了客户，甚至都没有问过作为开发者的我们切合实际的开发者周期究竟是多长时间。

正如不懂技术的产品经理提出了一个天马行空的想法让技术来实现，像这样的破事儿毫无疑问会惹毛开发人员。

阅读其他人的代码

有时候我们真是讨厌死其他开发者的代码了。尤其是当我们不确定它的实际功能时，我们就喜欢疯狂吐槽这段代码有多么愚蠢（以掩盖我们看不懂这段代码的事实）。

在没有注释的情况下，当接手别人的代码时，任何一个细节都可能激发开发者的厌恶情绪。包括一些大括 之类的小事，不论是放在同一行，单独成行，或K＆R风格，都无法让所有人都满意。如果去 Google 一下关于大括 的争论，它的问题会让你越看越傻眼。

代码审查和 pull request

在开发者群体中，code review 和 pull request 是备受争议的两个关键点。

code review 就像是公开邀请“羞辱”他人的编程能力。或者，至少有些人就是这样看待 pull request 的。当你花了很多时间准备好将功能合并到主版本中时，你的代码却被没有参与项目的其他人破坏了，还有比这更让人恼火的事吗p>

从本质上讲，code review 和 pull request 是一个开放的舞台，允许别人对你所编写的代码自由评论。

不过，多年的事实证明，认真的给代码写注释对后来阅读代码的人会有很大的帮助。甚至未来有一天，你自己也会庆幸当初写了注释。

原文地址：https://levelup.gitconnected.com/how-to-piss-off-a-developer-eea2069633fc

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92496 人正在系统学习中