本文标题党，酸奶爸爸是反对这种观点的，特此声明。
一开始拥护啥（因为什么）让你把代码写的这么复杂？
新产品需要快速上线
产品经理：竞对出了新产品，我们也要马上跟进，新立的项目，我不管你们技术怎么实现，总之老板就是要尽快上线。
程序猿：尽快是多快呢，这都快下班了。
产品经理：今晚加班，明早上线。
于是乎，命名规则里夹杂着拼音。前台后台一套代码。别说服务化了，MVC根本都没有，界面业务数据库逻辑都混合在一个函数里了。更别提什么服务化，未来业务扩展了。
矛盾爆发
项目上线后，如果业绩不理想。那么最终关停新项目，回收服务器，代码被丢在git仓库的角落无人问津。如果业绩炸裂了，那么程序猿们的悲惨命运就要开始了，大概率这个阶段业务需求会源源不断的提来，根本没有时间来重构代码，于是只能在现有的小平房上加盖摩天大楼。
破解之法
功能需求，新立的项目不要做的大而全，只做最核心的功能。如若不然，竞争对手死没死不知道，自己先把自己搞死了。程序架构不要太先进，微服务等架构是用户日活百万千万阶段需要做的架构。立项初期只要能够应对日活过万的需求变更就可以了。好的规范要从项目的第一行代码就要实施，命名规范、核心业务的文档、单元测试等等。
职场小萌新，看不到长远的未来
微信公众号比较火，我们公司也要以公众号的形态呈现，新事物年轻人接收比较快，于是这个需求就交给了组内的职场萌新来做。过一段时间小程序也火了，再过一段时间又要上马企业微信。大概率这些后续的腾讯系需求都会由这位职场萌新来做。
矛盾爆发
由于职场萌新经验不足，开发公众号需求只关注当下业务与公众号的接口，不会考虑未来的小程序和企业微信的扩展。所以代码里充斥了各种switch-case，数据库表里充斥了各种type。加班与延期是不可避免，工作日常也大概率被各种bug缠身而无暇新功能开发。如果这位职场萌新扛不住离职了，那就是悲剧的开始。
破解之法
技术经理与组内老鸟有不可推卸的责任，如果能够及时codereview，至少能保证职场萌新所搭建的楼不会歪。公司要上一个市面上流行的技术或业务，未来肯定要大规模上新需求，这里就需要老鸟们的技术经验与业务远见。毕竟如果职场萌新的楼歪了，恰巧又离职跑路了，那么这座歪了的楼大概率会由组内老鸟接手，因为市场已经爆发，大老板已经感受到职场萌新开发周期delay的痛了。
程序猿老油条，我的代码无人可以接手
公司业务平稳，日常新增需求也很常规，但就是有这种老油条型程序员将代码写的无比复杂，不同业务之间耦合度很高。
矛盾爆发
别人计划开发一周的需要，因为涉及老油条的代码，看代码就要看3天。这种乱麻型的代码，不知道哪些需求线上在用，哪些需求线上已经下线，搞得测试同学都得跑一遍，都很痛苦。上线之后往往是按下葫芦浮起瓢，好不容易开发2周上线，后续2~3天各种线上bug报出来，各种补丁文件上线，搞得OP同学也很痛苦。
但是在老板眼里却是另外一番景象，老油条每天加班，每天帮助同事解决bug，每天上线补丁解决线上问题，办公室一派欣欣向荣的景象。于是老板疯狂招人。
直到某天，代码实在改不下去了，线上天天出bug，公司业务高度依赖线上操作，老油条跑路。公司，卒。
破解之法
这种老油条是公司的毒瘤，它不同于新项目的赶工期，也不同于职场萌新的经验不足，而是主观要将代码写烂。这样做短期会保住自己的饭碗，长期看是逆势而为。老油条把青春与经历都花在了办公室厚黑上，而没有精进技术，违背客观规律的行为终将被时代淘汰。
解决之法：开掉。
写在最后
好的代码是为了提高未来的效率，这里的效率不只是编码的效率，还有沟通的效率。接收人不问原作者就能快速读懂业务逻辑，新需求开发能够尽量少的修改现有业务逻辑。开发规范，设计模式等这些前人大牛留下的精华不是在无病呻吟的。用同样的人力支撑更大的业务规模才是王道，该重构就重构，痛一阵是必要的。
我一直深信：加班能解决的问题，一定有其他方式解决。
