作者 | Kent Sia

译者 | 明明如月，责编 | 夕颜

出品 | CSDN（ID:CSDNnews）

程序员，有些人可能称他们为码农，开发人员，这是一群以开发计算机软件为生的人，也是地球上未来最重要的生物。世界越是依赖计算机来定义世界的运作方式，程序员就会变得越强大。呼神护卫（哈利波特咒语）

 

听起来太过了吗？

 

作为一个程序员的残酷现实

 

我是一个程序员，担任一个团队主管和技术主管多年了。人们常常认为，作为一个程序员只是写写代码而已。然而在工作中，事情很容易变得很复杂，当:

 

• 你要向高层管理人员负责

• 你有一个庞大的团队要管理

• 你需要处理多个项目

• 你的客户不知道他们想要什么

• 你的时间计划比较混乱，等等

 

大多数程序员都不善于沟通。当程序员在面对上述情况时而感到恐慌时，一些人倾向于逃避，说一些蠢话或者给出空头承诺来掩盖自己的错误。

 

下面我面对上述情况时，经常听到的一些话。我敢肯定，你们可能在工作环境中也听到过，或者你们自己可能也讲过其中的一些话。

 

开发进度如何? —完成了90%

 

作为程序员，我们在估计项目时间和工作量方面非常糟糕。我们经常努力理解客户的需求，但是需求方向每天却都在变化，会面临交付时间短，缺乏资源来完成项目等状况。我们还经常低估任务所要付出的时间和其他代价，而这些是我们在整个开发过程中没能提前预见到的。 

“一个程序员在一个月内能做到的，两个程序员在两个月内就能做到。”

— Fred Brooks

当一个团队由一个或多个程序员组成时，为了完成手头的任务，他们必须进行沟通、协作、执行代码集成、执行代码审查。所有这些沟通都随着程序员数量的增加呈指数增长，成为导致项目延迟的因素。

 

事实: 可能还没有开始。

 

没啥大问题，我稍后会修复它

 

如果您是测试人员或 QA，您可能经常听到这种说法。程序员相信在这个世界上没有完美的软件。

 

时间是软件开发的本质，我们往往没有时间去完成所有的事情。我们可能会告诉你要推迟计划，并告诉你稍后将对其进行修复，并在项目发布到生产环境后再发布一些补丁。然而，在大多数情况下，都没下文了。

 

事实: 以后永远不会出现，或者低估了在生产中造成更大问题的影响。

 

嘿，bug 我已经修好了。现在应该可以了(实际上还不行)

 

并非所有程序员都擅长测试，而且大多数程序员都不擅长测试。我认为这也测试人员和 QA 会存在的原因。糟糕的程序员经常发现修复 bug 比较困难。他们搞不懂产生 bug 的根本原因，或者因为修复不完全导致新的问题。

 

事实: 修复之后还不行；或者修复了一个 bug，又产生了新的 bug。

 

奇怪, 在我的电脑上能用的

 

这是我时常能听到的一句话。通常是在部署后发生故障或者程序员完全不知道出错的原因时说的。可能是一些命令或语法不兼容不同的操作系统，如 Windows 和 Linux 导致的。

 

事实: 其他东西坏了，部署了错误的版本，或者问题没有得到妥善修复。

 

我不知道这个[要求 / 界限 / ticket]

 

活是干不完的，有时候虽然程序员已经完成了足够对多的任务，但仍然会从上级 / 管理层那里得到更多任务。我们倾向于表现得好像我们从来不知道或者接受过这个需求。这可能是一个信号，表明开发者们感到筋疲力尽或者在偷懒，他们只是想把事情都推开。

 

还有一些情况下，程序员可能会错过一些要开发的界限，并且表现得像他们以前从未见过的那样。

 

事实: 我们知道这事，但我们不想知道。我怎么会错过这个？

 

昨天还好好的。谁动了我的代码？

 

当团队中多个成员一起合作时，这句话非常常见。我们常常没有足够的时间来完成一个项目。当需要紧急开发一个新功能时，程序员倾向于忽略测试并直接部署代码。我们也遇到过这样的案例，程序员在不考虑或不理解对其他服务的影响的情况下推送代码，最终破坏了代码。

 

事实: 有人弄乱了你的代码，或者你忘记了你昨天做了其他修改。

 

代码不是我写的

 

“不是我！不是我! ” 当程序员试图否认他们所做的一切时，我经常听到这样的说法。这是很多人的天性。当出现错误或故障时，程序员倾向于开始指责除他们编写的代码以外的任何事情。

 

真正的领导者在指出问题之前，会先竖起大拇指。

 

在某些情况下，团队领导是指责别人的人，而不是指责自己。如果你想成为一个伟大的领导者，我建议你不要这么做，你要承担责任，把功劳推给别人。敢于承认错误并不丢人。

 

事实: 我不记得我是什么时候写的这个 sh!t，或者我怎么会犯这个错误? ！

 

这只是临时的解决办法，不会用于生产

 

在项目开发中期很难保证质量。我们经常会身处这样的窘境: 是应该重写整个程序，还是只做一个快速修复，然后让它先运行。

  

       

这是一个艰难的决定，是否重新开发有缺陷的项目可能拖延进度，匆忙修补缺陷又不是一个好的设计。特别是当你遇到不耐烦的客户，测试人员或同行时，我们别无选择，只能告诉他们这只是暂时的，并期望他们以后会忘记。

 

事实: 当你想做出另一个改变或出现问题时，你会发现，临时解决方案变成了永久解决方案。

文档马上写好

 

我们程序员希望别人写出好的文档，但是自己却讨厌写文档。

 

Dick Brandon 说得最贴切:

“文档就像性，好的时候非常非常爽，坏的时候总比什么都没有好。”

ー Dick Brandon

坦率地说，程序员通常并不擅长写作，开始写第一句话就需要花费他们很长时间。在技术和业务流程快速变化的情况下，程序员很难同时处理代码变化和维持文档更新。

 

事实: 文档交付需要很长时间。

 

结尾

 

我希望你喜欢这篇文章。我不是想要指出谁对谁错。我们也应该记住，事情总是两面性的。

 

如果你还听过的有趣的黑话，请在评论中分享出来。

 

感谢阅读！

 

原文链接：

https://medium.com/swlh/decode-your-programmers-language-31f45877b960

本文为CSDN翻译文章，转载请注明出处。

【End】

《原力计划【第二季】- 学习力挑战》

正式开始

即日起至 3月21日

千万流量支持原创作者

更有专属【勋章】等你来挑战

推荐阅读 

☞近一半程序员单身、年薪低于 15 万，程序员扎心现状大调查！

☞被高估了的测试驱动开发？

☞大脑芯片公司Neuralink计划在人脑内植入芯片，他们到底想干什么？

☞Java 老矣，尚能饭否？2020 Java 生态系统报告出炉

☞Spark大数据分布式机器学习处理实战 | 博文精选

☞深耕技术，与实践赛跑：一文告诉你如何稳妥快速完善区块链技术并有序推动商用？

你点的每一个在看，我认真当成了喜欢