场景一
在功能需求的大会上，产品总监问技术：“这个功能大约须要几天能实现啊？”，技术：“一周吧”，产品总监：“给你三天时间，代码先跑上去再说”。我靠，有木有，有木有，别想太多，先让代码跑上去，你们都是这样干的，先实现功能，代码之后再改，在优化。这简直就是心安理得的神托词。多少有心写好代码的人都死在了这样的托词之中。打算时间不足，前期没有好好的思索整个需求框架，没有周密的逻辑思索，没事，先跑上去再说，这只是我们代码质量差的诱因之一。
场景二
在每周的会议中，产品总监和老总问：怎样样，上周任务都完成了吧，这周给你5天时间，必须把剩余功能全部实现，赶快的。技术那疲倦的样子，在睡眼迷蒙的状态下，爱答不理的说：好。
过了两天，总监又来问：做的如何样啊，快完了吧？实在不行，再加加班吧！这时，技术心中肯定在想：加你MB，气死老娘了。
瞧瞧，大多数程序员根本没时间考虑代码的执行效率哪些的，在仅有的短时间内，能省则省，能快则快，哪些高质量的代码啊，这也只有在加班的梦中想像。
场景三
在新人介绍会中，行政带着新来技术人员，给你们一一做介绍，产品总监过来说：一会过来一下，我把上个辞职人员的代码给你，顺便给你分配一下任务，你先把代码熟悉一下，然后马上投入开发中。
新来技术在领到代码后，看了一会说：靠，哪些烂代码啊，写的真烂。
哈哈，中枪了没有，中枪的有木有，多人的迭代和代码交接，各类风格乱入，一眼望去代码如同被猪啃过的草原。见到头痛的代码，都懒得更改了。代码质量高？也搞不过多个神人的迭代和写码。
听到以上三个场景，有木有中枪，是不是深有同感？有时侯是不是想有心杀贼，却无力回天啊？其实我前面说的都是大部份普通程序员的艰辛经历，并不代表所有的程序员，前辈，大牛或则大公司并不会这样。并且总结前面的三个场景，可以用一句话说：时间不够，代码来凑；人走人来，代码混乱。
代码质量差，bug多？我们都是被逼的，有时侯多想产品总监或则老总给我们足够的时间去整理逻辑和代码，优化出一道亮丽的景色线。多么想每位人都能把代码带上注释，看上去舒心啊，由于你没做到，你就没资格要求他人做到。还记得那种关于写注释的精典话吗？程序员最痛恨的两件事:1.写注释2.他人不写注释。就是这样的道理。
代码质量差，bug多？我们都是被逼的，让我们小声呐喊下来吧，别憋着，再憋坏了。产品总监啊，老总啊，晓得大家也不容易，时间紧也是迫不得已，希望大家也能多责怪一下我们程序员。我们都不容易，我们更是被逼的。
