只要代码足够乱，老板就不可能开了我

本文标题党，酸奶爸爸是反对这种观点的，特此声明。

一开始拥护啥（由于什么）让你把代码写的这么复杂？

新产品须要快速上线

产品经理：竞对出了新产品，咱们也要立刻跟进，新立的项目，我无论大家技术怎么实现，总之老板就是要尽快上线。

程序猿：尽快是多快呢，这都快下班了。

产品经理：今晚加班，明早上线。

因而乎，命名规则里夹杂着拼音。前台后台一套代码。别说服务化了，MVC根本都没有，界面业务数据库逻辑都混合在一个函数里了。更别提什么服务化，将来业务扩展了。

矛盾爆发

项目上线后，若是业绩不理想。那么最终关停新项目，回收服务器，代码被丢在git仓库的角落无人问津。若是业绩炸裂了，那么程序猿们的悲惨命运就要开始了，大几率这个阶段业务需求会源源不断的提来，根本没有时间来重构代码，因而只能在现有的小平房上加盖摩天大楼。

破解之法

功能需求，新立的项目不要作的大而全，只作最核心的功能。如若否则，竞争对手死没死不知道，本身先把本身搞死了。程序架构不要太先进，微服务等架构是用户日活百万千万阶段须要作的架构。立项初期只要可以应对日活过万的需求变动就能够了。好的规范要从项目的第一行代码就要实施，命名规范、核心业务的文档、单元测试等等。

职场小萌新，看不到长远的将来

微信公众号比较火，咱们公司也要以公众号的形态呈现，新事物年轻人接收比较快，因而这个需求就交给了组内的职场萌新来作。过一段时间小程序也火了，再过一段时间又要上马企业微信。大几率这些后续的腾讯系需求都会由这位职场萌新来作。

矛盾爆发

因为职场萌新经验不足，开发公众号需求只关注当下业务与公众号的接口，不会考虑将来的小程序和企业微信的扩展。因此代码里充斥了各类switch-case，数据库表里充斥了各类type。加班与延期是不可避免，工做平常也大几率被各类bug缠身而无暇新功能开发。若是这位职场萌新扛不住离职了，那就是悲剧的开始。

破解之法

技术经理与组内老鸟有不可推卸的责任，若是可以及时codereview，至少能保证职场萌新所搭建的楼不会歪。公司要上一个市面上流行的技术或业务，将来确定要大规模上新需求，这里就须要老鸟们的技术经验与业务远见。毕竟若是职场萌新的楼歪了，恰巧又离职跑路了，那么这座歪了的楼大几率会由组内老鸟接手，由于市场已经爆发，大老板已经感觉到职场萌新开发周期delay的痛了。

程序猿老油条，个人代码无人能够接手

公司业务平稳，平常新增需求也很常规，但就是有这种老油条型程序员将代码写的无比复杂，不一样业务之间耦合度很高。

矛盾爆发

别人计划开发一周的须要，由于涉及老油条的代码，看代码就要看3天。这种乱麻型的代码，不知道哪些需求线上在用，哪些需求线上已经下线，搞得测试同窗都得跑一遍，都很痛苦。上线以后每每是按下葫芦浮起瓢，好不容易开发2周上线，后续2~3天各类线上bug报出来，各类补丁文件上线，搞得OP同窗也很痛苦。

可是在老板眼里倒是另一番景象，老油条天天加班，天天帮助同事解决bug，天天上线补丁解决线上问题，办公室一派欣欣向荣的景象。因而老板疯狂招人。

直到某天，代码实在改不下去了，线上每天出bug，公司业务高度依赖线上操做，老油条跑路。公司，卒。

破解之法

这种老油条是公司的毒瘤，它不一样于新项目的赶工期，也不一样于职场萌新的经验不足，而是主观要将代码写烂。这样作短时间会保住本身的饭碗，长期看是逆势而为。老油条把青春与经历都花在了办公室厚黑上，而没有精进技术，违背客观规律的行为终将被时代淘汰。

解决之法：开掉。

写在最后

好的代码是为了提升将来的效率，这里的效率不仅是编码的效率，还有沟通的效率。接收人不问原做者就能快速读懂业务逻辑，新需求开发可以尽可能少的修改现有业务逻辑。开发规范，设计模式等这些前人大牛留下的精华不是在无病呻吟的。用一样的人力支撑更大的业务规模才是王道，该重构就重构，痛一阵是必要的。

我一直深信：加班能解决的问题，必定有其余方式解决。