是不是有些大公司的人写的代码也很烂,为什么设想一下你是一个只有10个人小团队的软件公司，老板亲自跑业务接项目，喝了半个月白酒好不容易拉来一单生意，告诉你，这个app客户要得很急，从设计到交付只有20天的工期，你们赶紧弄吧，客户尾款打过来偶请大家新马泰出去玩一圈。
然后你和你的兄弟们就开始点灯熬油的加班，加班，加班。
设计有缺陷？不影响使用就行。
测试没到位？不影响使用就行。
代码不美观？不影响使用就行。
这种情况下，要求什么代码质量，美观，简洁，不太现实。现实的是什么？要赚钱，要完成这件事。
他当然知道代码质量不行，在某处有隐患，但那不是当务之急。而且，为什么说代码质量好坏不是程序员一个人决定的？因为整个软件开发流程就不是只有他一个，还有测试，还有设计，还有产品经理，如果这些人缺席（小公司测试缺席很常见），代码质量是很难好起来的。
到头来，20天紧赶慢赶交付的软件，所有的功能都处于一个“凑合能用”的状态，这就是小软件公司的常态。
这就好像，有人要过河，请你出个解决方案。
方案一：你可以在旁边捡几块烂木板搭在两岸；方案二：也可以仔细量好尺寸、排定工期、选购材料、召集人马来造一座漂亮结实的大桥。
两座桥，都能解决问题，甚至根据场景的不同，都可以很好的运转下去。对于客户，或者使用方来说，这个桥怎么造的、用什么材料造的，造得过程如何，这些都不重要，重要的是，偶能用。
而对于造桥的人来说，你是如何造起一座座桥，如何经历这个过程，跟自己的职业生涯是息息相关的。
小公司的程序员，要经常面对一个“快速出活”的问题，老板要你快，客户要你快，所以很多功能上、代码质量上、测试范围上就欠考虑；
大公司的程序员，很多都处于甲方视角，没有什么项目周期的压力，代码可以得到很多人的审视、走读和检查，一些公司测试人员数量是开发人员的两三倍，并且测试场景也能够得到充分保证，客观上决定了，他们的代码质量不可能很低，就算低也没关系，有人、有时间教你提升质量。
在选择公司的问题上，偶始终主张：如果有得选，那么第一份工作最好选择去稍大、相对正规的公司。
因为，偶在大公司、小公司和中等规模公司都待过之后，悟出一个道理：
当你在小公司，为制度不合理、流程有问题而感到困扰的时候，如果你没在大公司待过，你压根都不知道正规的流程和正常的制度是什么样的。
就像你上学的时候，如果考到一个稍好的学校，你遇到好老师、厉害的学长学姐的概率会远比你在普通大学就读时来得高，对不对？
职场也是同理，大公司总会聚集一些行业大牛，跟他们多接触，会从根本上提升你的业务素质，还有职业视野。
这些并不是虚的东西，相反，这些东西有些时候比具体的工作能力还要有用，还要实在，而且能够影响你整个职业生涯。人的格局和视野，是很重要的，可以决定未来几十年活在哪个层次上。
说远了，扯回来。
说起来可能会有人笑话偶，但是偶想说，偶对于自己从事的工作，不管是测试还是写作，都有一定的荣誉感和责任感。偶觉得有些软件是不能崩溃也不能闪退的，因为这种事情一旦发生，用户所付出的代价太大。比如你写了大半夜的稿件，word突然闪退，windows突然黑屏，就问你暴躁不暴躁？如果明天就是deadline，没法按时交差，谁来承担这个后果？
写到这里，回头看看刚才用造大桥来比喻软件工程，偶真心觉得现在很多app的代码质量跟大桥完全不能比。再凑合的大桥，它也不会动不动就垮塌吧？但是却有很多app或者页面，就连几千几百的并发访问都扛不住。你要问为什么扛不住？真的就是程序员能力太差这一个原因吗？不，最大的可能是，老板没有给团队一个测试的时间。再复杂的程序，只要有足够的时间，大多都可以做到坚固美观和耐用——就像一座正常的桥梁一样。
道阻且长，大家努力哇～