著者|ケントのSia
翻訳|明らか月、Zebian | yugao
出品 | CSDN（ID:CSDNnews）
プログラマは、一部の人々がそれらのコード農家、開発者を呼ぶかもしれない、これは生活のためのコンピュータソフトウェアを開発するグループが、また、地球の最も重要な生物学的未来です。より多くの世界は、プログラマがより強力になり、世界の仕組みを定義するためにコンピュータに依存しています。PATRONUM（ハリー・ポッターの呪文）
あまりにもまだですね？
プログラマの厳しい現実として、
私は多くの年のチームリーダーとテクニカルディレクターとして、プログラマです。人々はしばしばそれに対する書き込みコードにプログラマーとして、だと思います。しかし、仕事で、物事は簡単に非常にするときに複雑になることができます：
あなたは、上級管理職の責任になりたいです
あなたは、大規模なチームを管理する必要が
あなたは、複数のプロジェクトを処理する必要があります
あなたの顧客は、彼らが望むものを知りません
あなたのスケジュール等、混沌としています
ほとんどのプログラマは、通信が得意ではありません。上記事情に直面して、プログラマは、時々パニックにすると、一部の人は避ける傾向にある、愚かな何かを言うか、自分のミスをカバーするために、空の約束を与えます。
今私は、多くの場合、言葉のいくつかを聞いて、上記に直面しています。私は、あなたが作業環境に聞いたことがあるかもしれないと確信している、またはあなた自身がそれらの何かを言っている場合があります。
どのように開発の進捗状況 - ？90％の完全な
プログラマーとして、我々は推定プロジェクトの時間とワークロードに非常に悪いです。私たちは、常にお客様のニーズを理解するために努力するが、変化の方向におけるすべてのニーズ毎日、短納期に直面するだろう、プロジェクトやその他の条件を完了するためのリソースが不足しています。私たちは、多くの場合、時間と私たちは事前に開発プロセス全体に予見していなかったその他の費用を、支払うべきタスクを過小評価します。
「月に行うことができますプログラマは、2人のプログラマは、2ヶ月以内にそれを行うことができるようになります。」
- フレッド・ブルックス
一人の以上のプログラマーのチームが、手元の作業を完了するために、彼らは、コラボレーションと通信する必要がある場合、コードの統合を実行し、コードレビューを行います。これらのすべての通信は、プログラマの数の指数関数的な成長、プロジェクトの遅延につながる要因の増加に伴っていました。
事実：それは起動しないことがあります。
何も大きな問題は、私は後でそれを修正します
あなたはテスターや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 生态系统报告出炉
☞深耕技术，与实践赛跑：一文告诉你如何稳妥快速完善区块链技术并有序推动商用？
你点的每一个在看，我认真当成了喜欢
