本文主要是介绍太坑了，降低 代码可读性的 12 个技巧，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
工作六七年以来，接手过无数个烂摊子，屎山雕花、开关编程已经成为常态。 下面细数一下 降低代码可读性，增加维护难度的 12 个编码“技巧”。
假设一个叫”二狗“ 的程序员，喜欢做以下事情。
1. 二狗积极拆分微服务，一个表对应一个微服务
二狗十分认可微服务的设计思想。认为微服务可以独立开发和发布，每次改动不会影响其他系统。大大提高了开发人员的效率和线上稳定性。还可以在新服务里使用新的技术，例如JDK 21
于是狗哥把微服务的思想发挥到极致，每一张表都是一个服务。系统的应用架构图十分壮观。狗哥自豪的跟新同学讲解自己设计的系统。新同学看着十几个服务陷入了思考，不停地问着每个服务的作用，干了什么。狗哥很满足。
新同学第一次开发需求，表现很差。虽然他要改10个服务，但是每个服务只改动了一点点。并且由于服务之间都是Rpc调用，需要定义大量的接口，他需要发布好多的 jar，定义版本号，解决测试环境版本冲突，测试和上线阶段可把他忙坏了。
光是梳理上线顺序，新同学就请教了狗哥 三次。 最后还是狗哥帮他上线了3 个服务，新同学才赶在 凌晨 3 点前把所有的服务发完。看着新同学买了奶茶的份上，狗哥这次才没有和领导吐槽，“这个同学不行啊，上个线都这么费劲”
微服务过多，也困扰着狗哥。虽然线上流量不高，但是由于 “微服务太多，系统架构复杂"，接口性能不行。
于是狗哥开始进行重构，他重新加了一个开关，新逻辑可以减少Rpc，调用提高性能。狗哥在代码中加了注释 "新逻辑"。
狗哥把代码上线了，但是在线上环境不敢放开，只在测试环境打开了开关。
2. 二狗积极重构代码，但是线上不放量
狗哥喜欢对代码进行重构，狗哥和领导吹牛，说“ 重构后的代码性能更强，更稳定”。 狗哥还添加了注释 ”这是新逻辑“。
但是狗哥在线上比较谨慎，并没有进行放量。只是在测试环境，放开了全量。
新接手的同学不知道线上还没放量，看到“这是新逻辑” ，他就在狗哥的“新逻辑”上改代码。测试环境验证一切正常，到了线上阶段却怎么也跑不通。
此时新同学才发现 ”新逻辑“ 的开关没有打开，你猜，他敢打开这个开关吗？ 于是他只能删代码，在旧逻辑上重新开发。 等到改完代码，再上线时，已经天亮了。
由于这次上线问题，大家一起熬夜加班，需求上线被推迟。新同学被产品和测试一顿骑脸输出。新同学委屈的想要离职。
3. 二狗喜欢挑战自我，方法长度一定要超过1000行
二狗写代码天马行空。二狗认为提炼新方法会打断自己的编码思路，代码越长，逻辑越连贯，可读性越高。二狗还认为 优秀的程序员写的方法都是 非常长的。这能体现个人的能力。
二狗不光自己写超长的方法，在改别人的代码时，也从不提炼新的方法。二狗总是在原来的方法中添加更长的一段代码。
新同学接手代码时速度很慢，即使加班到凌晨，也不理解狗哥代码设计的艺术。狗哥还向领导抱怨，”你最近招的人不行啊，一个小需求开发这么久，上线还出了bug。“
4. 二狗喜欢挑战自我，一个方法 if/try/else 要嵌套10层以上
二狗写代码十分认真，想到哪里就写哪里。 if/else/try catch 层层嵌套。 狗哥的思路很快，并且思考全面， 嵌套十几层的代码一点bug都没有，测试同学都夸赞狗哥 ”代码质量真高啊“，一个bug都没有。
新同学接手新代码时，看到嵌套十几层的代码，大脑瞬间就要爆炸。想要骂人，但是看到代码作者是狗哥……
无奈之下，自己实在看不懂这段代码，于是点了一杯奶茶，走到了狗哥工位旁，”狗哥，多喝点水，给你点了一杯奶茶。…………这段代码能给我讲讲吗？“
狗哥过几天和领导闲聊天，“新来的同学人不错，还给我点奶茶喝”
5. 二狗认为变量命名是艺术，要随机命名，不要和业务逻辑有关系
二狗觉得写代码是艺术，就好像画画一样。”你见过几个人能看懂 梵高的画？” 狗哥曾经和旁边人吹牛。
二狗写代码思路十分奇特，有时候来不及想变量如何命名，有时候是懒得想变量命名。狗哥经常随便就命名了，例如 str1，str2，list1，list2等等。不得不说，狗哥的思维还是敏捷的，这么多变量命名都能记住，还不出bug。
但是狗哥记性不大行，过一两个月就不太记得这些变量的意义了。
6. 二狗积极写注释，但是写了错误的注释
一个成熟稳重的程序员改别人代码时会十分慎重，如果有代码注释，他们一定会十分认真阅读并尝试理解它。
二狗喜欢把注释引入错误的方向，例如 “是” 改成 “不是”，“更好”改成”更差“，把两处不相干的注释交换一下位置 等。
新接手的同学点了一杯奶茶，虚心求助二狗，“狗哥，你写的这段注释有什么深意啊，我看了三天，也不理解啊”。
到时候狗哥就可以给新同学一边装B，一边讲代码了。当然还要看心情，要是不口渴，可以讲讲。
7. 二狗改代码很认真，但是注释从来不改
二狗改代码真的非常认真，但是他不喜欢改注释。最终代码大改特改，注释纹丝不动。最终代码和注释不相干，部分正确，部分错误。
新接手的同学研究了两天也没搞明白。于是求助了狗哥
到时候狗哥就可以大展神威了 。”那段注释是错的，你别管，就当没有！“
狗哥顺便还说了一句，”优秀的代码不需要写注释，也不知道是哪个XX 写的注释“，成功收割新同学的＂钦佩＂之情。
8. 二狗喜欢复制代码
狗哥写代码十分着急，根本来不及重构。他总是想到一段代码，就复制过来。神奇的是，狗哥经常这么写，但是也没出什么问题。
但新同学就惨了，在改完狗哥的代码后，总被测试同学背地里吐槽，“一点小需求咋这么多bug，跟狗哥比差远了”。原来新同学改了一处，忘了改另外几处，代码被复制了好多遍，他实在无法全面梳理。
于是每次代码写完，新同学都要不停的研究代码，总是害怕自己少改了哪些地方，下班时间越来越晚。并且新同学也不敢把雷同的代码重构到一起。（“你们猜猜他为什么不敢？）
慢慢的，组里的人都被迫向狗哥学习，狗哥成功输出了自己的编码习惯。
9. 二狗积极写技术方案，但是最终代码实现不按照技术方案来
二狗非常喜欢写技术方案，大部分时间都花在技术方案上，总是把技术方案打磨的 滑不留手。 但是在写代码时，狗哥总觉得按照方案设计写代码，时间上根本来不及啊，还是简单来吧，凑活实现吧。
例如狗哥曾经设计了一套复杂的Redis秒杀库存系统，但是实现时选择了最Low的 数据库同步扣减方案。
狗哥写的流程图和实际代码也没什么关系。 但是流程图旁边加满了注释和说明，让人觉得 ”这个技术方案很权威“。
新同学熟悉项目时，从公司文档中搜到了很多技术方案，本以为可以很快熟悉系统，但是发现技术方案和代码不太一样。越看越迷惑。
于是点了奶茶再次走向了狗哥，狗哥告诉他，“那个技术方案太复杂，排期紧张，开发来不及。你就当没那个技术方案。”
10. 二狗十分自信，从不打日志。
二狗对自己的代码十分自信，认为不会出现任何问题，所以他从来不打日志。每次开发代码时，狗哥的思维天马行空，但是从来不想加个日志会有助于排查问题。
直到有一天，线上真的出问题了，除了异常堆栈，找不到其他有效的日志。大家面面相觑，不知道怎么办。狗哥挺身而出，重新加了日志，上线。 故障持续了不知道有多久……，看着狗哥忙碌，领导不停地询问还需要多久才能上线。
复盘会上，有人对狗哥不写日志的行为进行批判，狗哥却在 狡辩 “加了日志，就能避免这次故障吗？ 出问题还不是因为你们系统出了bug，跟我不打日志有啥关系。” 双方陷入了无限的扯皮之中……
11. 二狗积极学习，引用一个高大上的框架 解决一个小问题
二狗非常喜欢学习，学习了很多高大上的框架。最近二狗学习了规则引擎，觉得这是个好东西，恰好最近在进行重构。于是二狗把 drools、avatior、SPEL等规则引擎、表达式求值 等框架引入系统。只是为了解决策略模式的问题。即何种条件下使用哪种策略。 狗哥在系统架构图里，着重讲了规则引擎部分，十分自豪。
新同学熟悉系统后，光是规则引擎部分就看了足足一周。但是还是不知道怎么修改代码。于是向狗哥请教。狗哥告诉他说，" 你在这个地方 加一行代码 rule.type == 12 ，走这个 CommonStrategy 策略类就可以了。“
新同学恍然大悟，原来这就是规则引擎啊。但是为什么不用策略模式呢？好像策略模式不费事啊！ 狗哥技术就是强啊，杀鸡用核弹。
12. 二狗积极造轮子，能造轮子的程序员才是牛掰的程序员
二狗非常喜欢造轮子，他对开源软件的大神们心向往之，觉得自己应该向他们学习。狗哥认为 造轮子才能更快地成长。
于是在狗哥的积极学习下，组里的 分布式锁 没有使用 redission，而是自己用setnx搞的。虽然后面出了问题，但是狗哥的技术得到了锻炼。# 不用Redssion硬造轮子，结果翻车了…
总结
降低代码可读性的方式方法 包括但不限于以上12种；
像二狗这样的程序员包括但不限于二狗。
大家不要向二狗学习，因为他是真的。
这篇关于太坑了，降低 代码可读性的 12 个技巧的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
