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