工作六七年以来，我接手过不少烂摊子，屎山雕花、开关编程几乎成了日常。下面盘点 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 二狗积极写注释，但是写了错误的注释
一个成熟稳重的程序员改别人代码时会非常慎重。如果代码里有注释，他们一定会认真阅读并尝试理解。
二狗喜欢把注释引向错误方向，例如“是”改成“不是”，“更好”改成“更差”，再把两处不相干的注释交换位置。
新接手的同学点了杯奶茶虚心求助：“狗哥，你写的这段注释有什么深意啊？我看了三天也不理解。”
到时候狗哥就能一边装，一边给新同学讲代码。当然还要看心情，要是不口渴，可以讲一讲。
7 二狗改代码很认真，但是注释从来不改
二狗改代码确实非常认真，但他不喜欢改注释。最终代码大改特改，注释纹丝不动。代码和注释互不相干，部分正确，部分错误。
新接手的同学研究了两天也没搞明白，只能再次求助狗哥。
这时狗哥就可以大展神威了：“那段注释是错的，你别管，就当没有！”
狗哥顺便还补了一句：“优秀的代码不需要写注释，也不知道是哪个 XX 写的注释。”成功收割新同学的“钦佩”之情。
8 二狗喜欢复制代码
狗哥写代码十分着急，根本来不及重构。他总是想到一段代码就复制过来。神奇的是，狗哥经常这么干，居然也没出什么大问题。
但新同学就惨了。他改完狗哥的代码后，总被测试同学背地里吐槽：“一点小需求咋这么多 bug，跟狗哥比差远了。”原来新同学改了一处，却忘了改另外几处。代码被复制了好多遍，他实在无法全面梳理。
于是每次写完代码，新同学都要不停研究，总害怕自己少改了哪些地方，下班时间也越来越晚。而且新同学也不敢把雷同的代码重构到一起，你猜他为什么不敢？
慢慢地，组里的人都被迫向狗哥学习。狗哥成功输出了自己的编码习惯。
9 二狗积极写技术方案，但是最终代码实现不按照技术方案来
二狗非常喜欢写技术方案，大部分时间都花在打磨方案上，总能把方案写得滑不留手。但真正写代码时，狗哥总觉得按方案实现来不及，还是简单来、凑活实现吧。
例如，狗哥曾经设计过一套复杂的 Redis 秒杀库存系统，实现时却选择了最简单的数据库同步扣减方案。
狗哥画的流程图和实际代码关系不大。但流程图旁边加满了注释和说明，让人觉得“这个技术方案很权威”。
新同学熟悉项目时，从公司文档里搜到不少技术方案，本以为能快速熟悉系统，却发现方案和代码对不上，越看越迷惑。
于是他又点了杯奶茶走向狗哥。狗哥告诉他：“那个技术方案太复杂，排期紧张，开发来不及。你就当没那个技术方案。”
10 二狗十分自信，从不打日志
二狗对自己的代码非常自信，认为不会出现任何问题，所以从来不打日志。开发时他思维天马行空，却从没想过加条日志会有助于排查问题。
直到有一天，线上真出问题了。除了异常堆栈，大家找不到其他有效日志，面面相觑，不知道该怎么办。狗哥挺身而出，重新加日志、上线。故障持续了不知道多久，领导只能不停追问还需要多久才能恢复。
复盘会上，有人批判狗哥不写日志。狗哥却狡辩：“加了日志，就能避免这次故障吗？出问题还不是因为你们系统有 bug，跟我不打日志有什么关系？”双方陷入无限扯皮之中……
11 二狗积极学习，引用一个高大上的框架解决一个小问题
二狗非常爱学习，研究过很多高大上的框架。最近他学了规则引擎，觉得这是个好东西，恰好项目正在重构，于是把 drools、aviator、SPEL 等规则引擎、表达式求值框架一股脑引入系统，只是为了解决策略模式的问题：即何种条件下使用哪种策略。狗哥还在系统架构图里重点讲了规则引擎部分，十分自豪。
新同学熟悉系统时，光规则引擎部分就看了足足一周，还是不知道怎么改代码。他只好向狗哥请教。狗哥告诉他：“你在这个地方加一行代码 rule.type == 12，走这个 CommonStrategy 策略类就可以了。”
新同学恍然大悟：原来这就是规则引擎啊。可转念一想，为什么不用 策略模式 呢？好像策略模式也不费事啊。狗哥技术就是强，杀鸡用核弹。
12 二狗积极造轮子，能造轮子的程序员才是牛掰的程序员
二狗非常喜欢造轮子，对开源软件的大神们心向往之，觉得自己应该向他们学习。狗哥认为，造轮子才能更快成长。
于是在狗哥的积极推动下，组里的分布式锁没有使用 Redisson，而是自己用 setnx 搞了一套。虽然后面出了问题，但狗哥的技术确实得到了锻炼。
总结
降低代码可读性的方式方法，包括但不限于以上 12 种。
像二狗这样的程序员，包括但不限于二狗。
建议大家不要向二狗学习，因为他是真的。
代码可读性、变量命名、日志规范、方案落地，这些看似基础的事情，往往最能体现一个团队的真实工程水平。你在项目里又遇到过哪些让人血压升高的“二狗式”操作？欢迎在评论区聊聊。
发表于 1 小时前
|
查看: 5|
回复: 0
