俗话说得好：代码撸得好，搬砖搬到老。如果你不是程序员里的top 5%精英，高质量的代码与升职加薪，迎娶白富美的相关系数几乎为0，除了给你带来一种虚幻的优越感与满足感。
难道我们这么多年接受的教育是错误的？不好好写代码，怎么升职加薪？教育是没错的，高质量的代码是我们追求的目标，也是我们必备的技能。但是，作为普通码农，我们日常工作的目标是面向人民币编程，而不是教科书式的面向对象编程。没有人民币，你都new不出一个对象。
会写高质量代码和日常工作中如何写代码其实是两回事，做为有追求的程序员，我们一定要掌握如何编写高质量代码的各种技能，因为我们还需要：
- 面向面试编程：大厂面试必须有足够的理论基础加忽悠能力，不然不足以体现你的过人之处。业内某技术大咖曾放话：只要代码不上线，PK从来不会输。面试造火箭，工作拧螺丝是大多数大厂员工得现实生活。
- 能力展示：文无第一武无第二，功夫用不用是一说，但如果一点不会同事们是肯定不会服你的。如果代码评审，设计评审说不出点有分量的，除非有其它过人之处，兄弟们是不会高看你一眼的。
- 装B：比如著名的博客技术专家耗子老师和阮老师，工程能力怎么样不评价，起码理论水平摆在那里，相关博客本熊也是时不时上去学习一二，开内容收费韭菜割起来嗖嗖的。看不起？不存在的，只恨自己做不到，羡慕嫉妒恨都来不及呢。
为什么要在日常工作中写烂代码，这要从资本家如何赚钱说起。对于资本家来说，利润越高越好，成本越低越好。大多数情况下，资本家们更懂如何赚钱，但是对编程基本一无所知。他们关注的是产品能否以最低的成本交付，至于怎么实现的并不关心。我付了钱就得在规定时间内把活干了。说两个真实的笑话，某市值千亿上市公司CEO亲口所说：
- 这个功能有什么复杂的，不就一个页面，为什么一晚上画不出来？
- 为什么不能把Excel的功能做到我们的系统里？Excel这么简单的东西，微软已经有了，抄一下不是很快的事吗？
对于大多数业务驱动公司来说，程序员的牛B与否是无法改变甲方爸爸能给多少钱的，真正决定的是甲方爸爸的现有业务能赚多少钱。这也就是为什么我们发现大多数牛B程序员都在互联网大厂或者底层厂商（操作系统，数据库等等），因为对于这些厂商来说业务是由技术驱动的，而且有足够的利润率支持用来招聘牛B的程序员和支持他们试错。甲方只为产品和服务付费，不为中间过程和看不到的地方付费。架构设计再好，编码质量再高，设计模式运用炉火纯青，Nobody cares...反正项目就这么点预算。
对于团队来说，个人的牛B无法改变整体产出的。大厂的牛B程序员们大多数是因为站在了正确的行业风口，而他们又比其他人更为出色一点，当然也有少数人是凭一己之力开创一个时代。对于一个作坊里一个超过5人的程序员团队，即使有一个人编码效率是别人的3倍，但是他一个人不可能把所有的活做了。而且与我们想象的程序员每天工作埋头编码不同，大多数时间是在与产品撕B，排查线上故障，编写文档，偶尔还要跨部门扯个蛋，每天真正有效编码时间不超过30%。所以3倍生产力在老板看来也就撑死多个30%的产出，而且项目也不是天天排满，加个15%的工资已经是天地良心。
所以，对于程序员来说去大厂并不是你干的活更有难度，而是享受了大厂高利润率的红利。说白了就是粮仓里的老鼠与粪坑里的老鼠的区别。那么，对于大多数混迹与软件作坊的普通程序员来说，该如何最大化我们的利益呢？简单说就是写烂代码！！！如果对自己技术自信就赶紧跳槽去大厂，或者挤出业余时间努力自学，如果都做不到，那么就乖乖的按我下面说的去做。
老板关注的是产出的结果，只要功能都做完，bug别太离谱，那么你就是安全的，对得起老板的这份工资。真有外包公司按代码量考核工作量，对于不懂得老板，这是最简单得考核指标。什么重复功能封装抽象，业务解耦合，参数配置话，统统扔一边去，把功能实现了就行。反正这代码我天天打交道，要改哪些地方我都知道，大不了多报几个bug多修几次。什么，你说工作量大效率低容易出错？不！老板不会这么想，工作量大你加班解决就是，没准我还能向甲方多报几个工时；容易出错？那是因为项目复杂啊，加钱。对于老板总不见得跟甲方说因为这个项目我用了牛B程序员，1周能把原来1个月得活干完，你得加钱？
烂代码是职位安全的有效保障。功能交付了，运行稳定无故障，甲方后续需求因为架构设计合理，随便上个实习生就满足了，对于老板来说这些都是理所当然的工作，后面随便找个便宜的人替代维护，提高利润才是重要的事情啊，类似的项目找人抄抄就行。这种事情听着魔幻，但在各种作坊里却是真实发生的事实。如果代码写得烂，就需要不断有人维护，要加新功能，就不能随便找个人接手，不然等工期结束原来的代码都还没整明白。而且只要这个系统还在线上运行不能下来，老板基本上得捏着鼻子付你工资，因为找人接手不是那么容易的事情。不如你的大概率不知道哪里有坑捅了大娄子没法收拾；比你强的去哪不好非得来收拾这个烂摊子。老板即使各种不满意，也磨合这么久了至少对下限有个底，不能忍还咋的？
写烂代码也要对自己负责，烂的地方自己要心中有数，线上出现不可控的bug是不允许的。曾看过一段代码，下面列的问题差不多基本都齐了，开发做需求每天工作量满满，我去和他聊重构，啪，这哥们掏出一本笔记...不怕，坑都有记录，保证不出大问题。重构出了故障算谁的？重构能增加业务营收吗？重构好了系统不需要我维护了怎么办？灵魂三问！得了，咱继续这么愉快的玩耍吧。员工每天很有安全感充实的工作，老板觉得大家每天很忙，而且系统老出bug是因为难度大，所以不稳定，大家每天加班都很努力了，态度端正是最重要的吗。
下面简单说下我见过的某公司内部核心管理系统的一些见闻，因为系统烂，所以...
- 大量业务信息硬编码，修改挂一漏万，上线了用户就是最好的测试。
- 前端混合业务逻辑，上千行的函数到处都是，反正东西都在脑子里，不怕死的自己琢磨去。
- 封装看心情，类似的功能写了十几个地方，能一次找到改完算你赢。
- 业务紧密耦合牵一发而动全身，动不动某个功能就要全部重写。一个星期后想用？咱哥们这么多年的交情就等一个月吧。
- 数据库查询大量字符串拼接，想注入攻击分分钟。
- 大量业务逻辑存储过程写死，查询效率感人...
虽然公司一直想动这个系统，但是不管业务方还是技术部门，都没有不怕死的跳出来，所以整个系统还在继续忍辱负重...相关人员还得继续养着，多好啊。
