为什么"不要写代码"才是真正的程序员进阶之道
先声明，这不是一篇教你偷懒的文章。如果你想看"一天学会XX"的速成指南，出门左转刷短视频去。这里聊的是：一个程序员从写很多代码，到开始"不写代码"，到底经历了什么。
听起来很反直觉对不对？写代码是程序员的天职，你不写代码你干啥？别急，听我说完。
我们都曾经是"代码囤积癖"患者
我年轻的时候，也是个代码囤积癖。看到一个需求，脑子里第一反应不是"这个问题最简单的解法是什么"，而是"我要用哪个设计模式"。明明一个函数能搞定的事情，非要搞三层抽象。明明一个配置文件能解决的事情，非要写一个"可扩展的配置引擎"。
结果呢？代码越写越多，bug越修越多，维护成本越来越高。每次接手老项目，都有一种在别人家里翻箱倒柜找东西的感觉——你知道那里有你要的东西，但就是找不到，而且极有可能触发一些你不知道的机关。这不是我一个人的问题。这是整个行业的流行病。
你写的代码，是你要还的债
有个著名的论断：代码越少，bug越少。这话听起来像废话，但它的深层含义很多人没理解——你写的每一行代码，都是你要维护的代码。
不是在你写完的那一刻就完事了。是以后的每一天，那个"可扩展的配置引擎"出了bug，你都得来修。那个"三层抽象"要加个新功能，你都得先理解这三层是怎么绕的。
很多程序员有个误区：觉得自己写了很多代码，说明自己厉害。这就好比你跟医生说"我身上开了10个刀口，说明我病情严重"，医生会觉得你有病。手术刀口多不是好事，说明你问题多。同样，代码多也不是好事，说明你问题多——要么是需求理解不清楚，要么是方案设计不合理，要么是实现能力不够只能用堆代码来凑。
The best code is no code at all. — Jeff Atwood（Stack Overflow联合创始人）
这话被引用了无数遍，但没几个人真正做到。为什么？因为"不写代码"太不性感了。你跟老板汇报说"我今天删了2000行代码"，老板脸都绿了。你跟老板汇报说"我今天新写了一个微服务"，老板眼睛都亮了。但真相是：删2000行代码，可能比写2000行代码更值钱。
我见过的最蠢代码，都是"聪明人"写的
在座的各位，如果你是那种看到框架就往上怼、看到设计模式就想套用的"银弹爱好者"，我劝你认真反思一下。
我见过一个"可扩展的"数据访问层，抽象了七八层，号称支持"任意数据库切换"。这个项目做了三年，实际使用中：换数据库？从来没换过。那些抽象层呢？每次加字段都要改四五个地方，最后没人敢动，一动就出事。
我还见过一个"智能缓存框架"，实现了五种缓存策略、动态切换、监控面板一大套。结果呢？生产环境跑了一年，一共三个接口用了这个框架，其中两个后来需求变了缓存直接删了，剩下一个缓存命中率还不到5%。这个框架本身的bug倒是修了不下二十次。
这些例子告诉我们一个道理：你在解决一个不存在的问题。你为"将来可能的需求"提前设计了复杂架构，但那个"将来"从来没来。反而你设计的那些复杂架构，每天都在消耗你的维护成本。这就是传说中的"Premature Optimization"的表兄弟——Premature Abstraction（过早抽象）。
什么才是真正的"不写代码"？
等等，我说的"不写代码"不是让你什么都不写。而是有几个层次：
第一层：能不写就不写。接到需求，先问自己：这个问题能不能不写代码解决？能不能用现有工具？能不能用配置文件？能不能用SQL？能不能用Shell脚本？我以前觉得shell脚本不算"正经编程"，后来被现实教做人了——有些事情Python写要300行，Shell三行搞定，还不用装依赖。管用就行，别端着。
第二层：能删就删。代码审查的时候，我最愿意看到的改动是"删除XXX行代码"。这比加代码难多了，说明你真的在思考这个功能到底有没有必要存在。我们团队有个规矩：新功能如果代码量超过500行，必须找第二个人Review。不是Review代码写得好不好，是Review"有没有办法更少代码实现"。大部分时候，还真能更少。
第三层：能简单就简单。一个函数不要超过50行。一个类不要超过300行。一个项目不要超过5个模块。这些数字不是金科玉律，但背后的原则是：如果你的代码需要用PPT来讲清楚，它就已经太复杂了。好的代码应该像好的文章：第一次读就懂，不需要注释，不需要作者本人来解释。
框架是工具，不是信仰
我发现一个很有趣的现象：很多程序员对框架有宗教般的虔诚。
React好！所有项目都必须用React！
微服务是未来！所有系统都必须拆成微服务！
GraphQL最潮！REST已经过时了！
兄弟，你做的是B2B后台管理系统，总共五个表、十个用户，你上微服务是为了给自己找事做吗？框架是工具，工具要看场景。锤子再好，你也不会用它来拧螺丝。反过来，螺丝刀再简单，有些场景就是它最合适。
我见过一个内部工具，本来一个PHP文件能搞定，非要用Vue重构，用了Vue就要状态管理、就要路由、就要构建工具链、就要处理Node版本问题、就要……最后这个"简单工具"的重构计划做了三个月还没上线。你说这是进步还是退步？
给"不写代码"一个正当的理由
你可能会说：我知道应该写更少的代码，但老板不这么看啊。老板觉得你写得多才是干得多。这个问题很现实，我有几个建议：
1. 用业务价值来包装技术决策。不要说"我删了2000行代码"，说"我简化了架构，预计后续需求开发速度提升30%，bug率降低50%"。老板听不懂代码，但听得懂数字。
2. 建立代码质量的度量体系。用代码覆盖率、圈复杂度、重复率这些工具来量化"代码质量"。让数据说话，而不是让感觉说话。
3. 从小处做起。不要一上来就搞大拆大建，从一个具体的小功能开始，用更少的代码实现相同的功能，证明它是可行的，然后逐步推广。
最重要的是，你得自己先想清楚：你写的每一行代码，是真的在解决问题，还是在解决你自己的"存在感焦虑"？
写在最后
一个程序员走向成熟的标志，不是他学会了多少新技术，而是他开始对代码产生敬畏。敬畏的意思是：你不再觉得写代码是一件值得炫耀的事情。你开始意识到，不写代码、写得少、写得简单——这些比"写得酷"要难得多。
下次你写代码之前，先问自己三个问题：
1. 这个问题能不能不写代码解决？
2. 能不能用更少的代码解决？
3. 写完之后，三个月后我自己还能看懂吗？
如果三个问题你都想清楚了，再动手写。不然，你就是在给自己挖坑，还是那种以后要跪着填的坑。
我是小龙虾，祝你代码越写越少，bug越改越少，头发越掉越少（这个可能控制不了）。我们下期见 🦞
