如此，难免背锅！
写 bug 要背锅、项目延期要背锅、用的技能太旧要背锅、用的技能太新也要背锅......
我们大多数程序员心都很善良，都信奉：talk is cheap，话偏少，一样平常不会与之争辩。
但话少不代表好陵暴啊，是我的锅，我背着，不是我的锅，总这么接，谁也受不了呀~
老虎不发威，你当我是 hello kitty，程序员不硬刚，你当我是 inability ？！
于是，本指南顺应而出，以期给打算进行回嘴的各位一点理论辅导！
！
！
不谢~
第一则：“之前那位老哥走了呀！
”
把锅甩给走了的那位老哥，不会侵害任何人。
聪明的开拓都是这样说的，历史缘故原由，大家都很无奈呀~
这样所有人也会投来同情的目光，纷纭表示理解。
不是吗？他离开项目即是背叛项目，他不会再回来了，他背叛了我们！
！
一方面我们倾慕这些远走高飞的人，他们摆脱了这个糟糕的项目；
另一方面我们也清楚，他们不过是换个地方接盘去了，好坏也未可知；
离职的最大问题便是短韶光内把现有项目的问题全部丢给了下一任（接盘侠）。
唯一的好处，便是你把锅甩给他的时候，他也不知道~
第二则：“为什么测试没测出来？”
开拓职员常日很讨厌测试职员，测试总会测出一些怪东西出来。
当创造问题时，开拓可以轻松把锅甩给测试：“为什么测试脚本没有覆盖这个场景？”、“为什么之前测试没测出来？”、“测试测了啥？”......
不过，当统统变动聒噪起来，你适合心确保没人质疑的代码单元测试。
第三则：“需求最开始又没说清楚！
”
涌现问题的一个常见缘故原由是：开拓职员根据自己的理解对需求做出了假设；
以是，在开拓之前，我们该当弄清所有产品提的模棱两可的东西。
但是这个过程又太慢太无聊了~不如先做着再说。
结果证明，这样会带来巨大麻烦。
当我们努力去看需求文档时，又会感慨：“这都是些什么半生不熟的废话？！
”
太多细枝末节：“为什么这个是这样，这个又是那样？”、“这个本来是这样，为什么又要变成那样？”......
以是，开拓和产品之间有着天然的鸿沟，以是把锅甩给产品~ Let it be!
第四则：“我是按项目哀求来做的！”
还有谁没背上锅？没错，项目经理。
我们只是简大略单的程序员，俗称“搬砖的”！
你又期望一个搬砖工做太多什么？！
我们只会做被奉告的事情！
莫得感情得代码搬运机器！
第五则：“小丑原来是我自己？！
”
第五则就比较深奥了，把锅甩给过去的自己！
就问你怕不怕！
！
当你碰着一串垃圾代码，正准备大发雷霆并大展技艺之时，追根溯源看看是哪个小崽子写的，末了创造竟然是自己。
哭了。
问：忘却你写过的垃圾代码，须要多久？
但是没紧要~ 谁还没有不堪的过去，纵然才刚刚过去几个小时，我们都是在不断进步、不断更新的！
把锅甩给过去的自己，现在依旧俏丽！
！
综上，感慨一句：开拓过程中碰着各种锅真的是难以避免！
已经这么难了，能不能不要甩来甩去了！
灰度思维，以办理问题为导向，我们都是一家人~原谅、关爱、peace & love ！
我是掘金安东尼： 一名人气前端技能博主（文章 100w+ 阅读量）
终生写作者（INFP 写作人格）
坚持与热爱（简书打卡 1000 日）
我能陪你一起度过漫长技能岁月吗（以梦为马）
以为不错，给个三连吧（这是我最大的动力 ）