假设一个叫“二狗”的程序员，喜欢做以下事情。

二狗十分认可微服务的设计思想。认为微服务可以独立开发和发布，每次改动不会影响其他系统。大大提高了开发人员的效率和线上稳定性。还可以在新服务里使用新的技术，例如JDK 21。

于是狗哥把微服务的思想发挥到极致，每一张表都是一个服务。系统的应用架构图十分壮观。狗哥自豪地跟新同学讲解自己设计的系统。新同学看着十几个服务陷入了思考，不停地问着每个服务的作用，干了什么。狗哥很满足。

新同学第一次开发需求，表现很差。虽然他要改10个服务，但是每个服务只改动了一点点。并且由于服务之间都是Rpc调用，需要定义大量的接口，他需要发布好多的 jar，定义版本号，解决测试环境版本冲突，测试和上线阶段可把他忙坏了。

光是梳理上线顺序，新同学就请教了狗哥三次。最后还是狗哥帮他上线了3 个服务，新同学才赶在凌晨 3 点前把所有的服务发完。看着新同学买了奶茶的份上，狗哥这次才没有和领导吐槽，“这个同学不行啊，上个线都这么费劲”。

微服务过多，也困扰着狗哥。虽然线上流量不高，但是由于“微服务太多，系统架构复杂”，接口性能不行。

于是狗哥开始进行重构，他重新加了一个开关，新逻辑可以减少Rpc，调用提高性能。狗哥在代码中加了注释“新逻辑”。

狗哥把代码上线了，但是在线上环境不敢放开，只在测试环境打开了开关。

狗哥喜欢对代码进行重构，狗哥和领导吹牛，说“重构后的代码性能更强，更稳定”。狗哥还添加了注释“这是新逻辑”。

但是狗哥在线上比较谨慎，并没有进行放量。只是在测试环境，放开了全量。

新接手的同学不知道线上还没放量，看到“这是新逻辑”，他就在狗哥的“新逻辑”上改代码。测试环境验证一切正常，到了线上阶段却怎么也跑不通。

此时新同学才发现“新逻辑”的开关没有打开，你猜，他敢打开这个开关吗？于是他只能删代码，在旧逻辑上重新开发。等到改完代码，再上线时，已经天亮了。

由于这次上线问题，大家一起熬夜加班，需求上线被推迟。新同学被产品和测试一顿骑脸输出。新同学委屈得想要离职。

二狗写代码天马行空。二狗认为提炼新方法会打断自己的编码思路，代码越长，逻辑越连贯，可读性越高。二狗还认为，优秀的程序员写的方法都是非常长的。这能体现个人的能力。

二狗不光自己写超长的方法，在改别人的代码时，也从不提炼新的方法。二狗总是在原来的方法中添加更长的一段代码。

新同学接手代码时速度很慢，即使加班到凌晨，也不理解狗哥代码设计的艺术。狗哥还向领导抱怨，“你最近招的人不行啊，一个小需求开发这么久，上线还出了bug”。

二狗写代码十分认真，想到哪里就写哪里。if/else/try catch 层层嵌套。狗哥的思路很快，并且思考全面。

嵌套十几层的代码一点bug都没有，测试同学都夸赞狗哥“代码质量真高啊，一个bug都没有”。

新同学接手新代码时，看到嵌套十几层的代码，大脑瞬间就要爆炸。想要骂人，但是看到代码作者是狗哥……

无奈之下，自己实在看不懂这段代码，于是点了一杯奶茶，走到了狗哥工位旁，“狗哥，多喝点水，给你点了一杯奶茶。…………这段代码能给我讲讲吗？”

狗哥过几天和领导闲聊天，“新来的同学人不错，还给我点奶茶喝”。

二狗觉得写代码是艺术，就好像画画一样。“你见过几个人能看懂梵高的画？” 狗哥曾经和旁边人吹牛。

二狗写代码思路十分奇特，有时候来不及想变量如何命名，有时候是懒得想变量命名。狗哥经常随便就命名了，例如 str1，str2，list1，list2等等。不得不说，狗哥的思维还是敏捷的，这么多变量命名都能记住，还不出bug。

但是狗哥记性不大行，过一两个月就不太记得这些变量的意义了。

一个成熟稳重的程序员改别人代码时会十分慎重，如果有代码注释，他们一定会十分认真阅读并尝试理解它。

二狗喜欢把注释引入错误的方向，例如 “是” 改成 “不是”，“更好”改成“更差”，把两处不相干的注释交换一下位置 等。

新接手的同学点了一杯奶茶，虚心求助二狗，“狗哥，你写的这段注释有什么深意啊，我看了三天，也不理解啊”。

到时候狗哥就可以给新同学一边装B，一边讲代码了。当然还要看心情，要是不口渴，可以讲讲。

二狗改代码真的非常认真，但是他不喜欢改注释。最终代码大改特改，注释纹丝不动。最终代码和注释不相干，部分正确，部分错误。

新接手的同学研究了两天也没搞明白，于是求助了狗哥。

到时候狗哥就可以大展神威了 。“那段注释是错的，你别管，就当没有！”

狗哥顺便还说了一句，“优秀的代码不需要写注释，也不知道是哪个XX 写的注释”，成功收割新同学的“钦佩”之情。

狗哥写代码十分着急，根本来不及重构。他总是想到一段代码，就复制过来。神奇的是，狗哥经常这么写，但是也没出什么问题。

但新同学就惨了，在改完狗哥的代码后，总被测试同学背地里吐槽，“一点小需求咋这么多bug，跟狗哥比差远了”。原来新同学改了一处，忘了改另外几处，代码被复制了好多遍，他实在无法全面梳理。

于是每次代码写完，新同学都要不停地研究代码，总是害怕自己少改了哪些地方，下班时间越来越晚。并且新同学也不敢把雷同的代码重构到一起。（你们猜猜他为什么不敢？）

慢慢的，组里的人都被迫向狗哥学习，狗哥成功输出了自己的编码习惯。

二狗非常喜欢写技术方案，大部分时间都花在技术方案上，总是把技术方案打磨得滑不留手。但是在写代码时，狗哥总觉得按照方案设计写代码，时间上根本来不及啊，还是简单来吧，凑活实现吧。

例如狗哥曾经设计了一套复杂的Redis秒杀库存系统，但是实现时选择了最Low的数据库同步扣减方案。

狗哥写的流程图和实际代码也没什么关系。但是流程图旁边加满了注释和说明，让人觉得“这个技术方案很权威”。

新同学熟悉项目时，从公司文档中搜到了很多技术方案，本以为可以很快熟悉系统，但是发现技术方案和代码不太一样，越看越迷惑。

于是点了奶茶再次走向了狗哥，狗哥告诉他，“那个技术方案太复杂，排期紧张，开发来不及。你就当没那个技术方案。”

二狗对自己的代码十分自信，认为不会出现任何问题，所以他从来不打日志。每次开发代码时，狗哥的思维天马行空，但是从来不想加个日志会有助于排查问题。

直到有一天，线上真的出问题了，除了异常堆栈，找不到其他有效的日志。大家面面相觑，不知道怎么办。狗哥挺身而出，重新加了日志，上线。故障持续了不知道有多久，看着狗哥忙碌，领导不停地询问还需要多久才能上线。

复盘会上，有人对狗哥不写日志的行为进行批判，狗哥却狡辩“加了日志，就能避免这次故障吗？出问题还不是因为你们系统出了bug，跟我不打日志有啥关系。”双方陷入了无限的扯皮之中……

二狗非常喜欢学习，学习了很多高大上的框架。最近二狗学习了规则引擎，觉得这是个好东西，恰好最近在进行重构。于是二狗把 drools、avatior、SPEL等规则引擎、表达式求值等框架引入系统。只是为了解决策略模式的问题。即何种条件下使用哪种策略。狗哥在系统架构图里，着重讲了规则引擎部分，十分自豪。

新同学熟悉系统后，光是规则引擎部分就看了足足一周。但是还是不知道怎么修改代码。于是向狗哥请教。狗哥告诉他，“你在这个地方加一行代码 rule.type == 12 ，走这个 CommonStrategy 策略类就可以了”。

新同学恍然大悟，原来这就是规则引擎啊。但是为什么不用策略模式呢？好像策略模式不费事啊！狗哥技术就是强啊，杀鸡用核弹。

二狗非常喜欢造轮子，他对开源软件的大神们心向往之，觉得自己应该向他们学习。狗哥认为造轮子才能更快地成长。

于是在狗哥的积极学习下，组里的分布式锁没有使用 redission，而是自己用setnx搞的。虽然后面出了问题，但是狗哥的技术得到了锻炼。

降低代码可读性的方式方法包括但不限于以上12种；