Ruby 10 年开发后，我后悔坚持的 8 个技术信仰，不知你踩中几个
今天，我在生产环境排查一个莫名其妙的崩溃。日志里布满了层层抽象的调用栈，像一张无边的蜘蛛网。
代码里的每一行都符合“最佳实践”，架构精雕细琢，可 Bug 还是来了。那个瞬间，我突然想起四年前的自己——曾无比自豪地告诉新人：“优雅架构就是一切。”
可现在，我只想对那时候的自己说：“别装了，写能跑的代码吧。”
十年开发生涯让我推翻了许多曾深信不疑的技术理念。今天，我把这些踩坑经历整理出来，希望能帮你少走些弯路。
01 | 技术理念的崩塌
- “简单”从来不是免费的，它是最昂贵的选择
四年前，我坚信“简单至上”。后来我才发现，让代码保持简单，需要持续的投入。业务需求膨胀时，每个“简单”的架构决策，都要付出昂贵的代价去维护。
真正的“简单”，不是一开始就写出完美代码，而是有能力在复杂性爆炸前，把代码逐步“修剪”回合理状态。
- “优雅”是幻觉，能跑才是道理
曾经，我会在代码里反复推敲命名，调整缩进，优化模式，追求某种“美感”。但经历了几次生产事故后，我意识到：“优雅”从来不是一个真实的技术指标。
系统能否稳定运行、团队能否快速交接，远比代码的“形式美”重要。优雅的代码，不如无 Bug 的代码。
- ORM 是恶魔，SQL 才是答案
我曾经推崇 ORM，认为它能屏蔽数据库差异，提升开发效率。后来被它坑惨了：复杂查询写不出来，性能优化受限，Debug 像拆炸弹。
最终，我回归了最原始的方式——直接写 SQL。数据库优化的最佳方式，就是尊重 SQL，而不是绕开它。
- “类型安全”是团队的保护网
过去，我对强类型语言嗤之以鼻，觉得动态语言写起来灵活高效。直到一次团队交接，动态代码的“魔法”变成了无尽的痛苦。
Typed 语言像护栏，帮团队里经验不同的人保持代码质量。个人写代码可以随性，团队协作必须稳健。
- 前端开发已经卷成了噩梦
十年前，前端是 HTML+CSS+JS，简单直白。现在，前端是一套复杂的工程体系，动不动就要学框架、学编译、学服务端渲染。
我越来越觉得，前端的“工程化”并没有带来应有的幸福感，而是让开发变得越来越焦虑。
- Serverless 未来是好东西，但现在还是坑
Serverless 的愿景很美好，可落地时，我无数次因为它的冷启动、调试难、监控难而崩溃。
如果你要做长期稳定的业务，老老实实选传统架构，Serverless 还没成熟到能承载大部分业务的程度。
- “软件工程”大多时候只是沟通问题
这几年，我越来越发现，软件开发不是“写代码”这么简单，而是沟通、协作、妥协的过程。技术难点从来不是代码，而是“如何让所有人理解代码”。
会编码是一回事，能让别人看懂你的代码，才是真本事。
- “管理”比技术重要，但真正好的管理极为稀缺
我花了很长时间才意识到，一个烂的管理，会让优秀的工程师一身狼狈；而一个好的管理，能让普通人也做出优秀的产品。
好管理者太少了，大多数的管理者，只是在消耗开发者的创造力。
02 | 如何避免踩坑？ 十年后的我，给刚入行的开发者 3 个建议：
“代码洁癖”适可而止，写业务代码时别钻牛角尖 不要为了“优雅”而牺牲实用性，别陷入“最佳实践”的执念。实用 > 形式美。
直接写 SQL，别太信任 ORM ORM 适合简单查询，但复杂业务逻辑，SQL 才是终极答案。与其踩坑，不如早点学会手写 SQL。
沟通能力比技术能力更值钱 代码能跑很重要，但能解释给别人听，能让团队顺畅协作，才是更核心的能力。
03 | 技术思维的升级 “代码简单”不是靠写出来的，而是靠不断重构出来的
“优雅”不是工程目标，稳定和可维护才是
“工程师文化”最重要的是沟通，不是编码
04 | 你踩过这些坑吗？ 如果你也在开发生涯中经历了类似的转变，欢迎留言分享你的故事。
你现在的信仰，四年后还会坚守吗？
- 对于 Ruby 来讲，大多数时候还是 ORM，复杂查询才需要写 SQL，并不需要二选一
- 现代前端确实是噩梦，我也受不了，Hotwired 才是能发挥 Rails 开发效率的方案，SPA 看起来美好，但是美好的代价太高，很多都没达到那个高度，实际的体验并不会比普通 HTML 应用好或者好多少
- Serverless 最近几年比较沉迷，但也没想承载所有业务，而是结合
Serverless，如果这玩应省的钱，可以给你雇佣几个工程师，那为什么不用？如果不能，用它不是闲的吗。不是说技术怎么样，而是你理不理解，用的对不对。ORM 也类似，知道为什么用，知道它的上限在哪。再多数一句，多数 web 服务，性能都不是什么大问题，可扩展性才是。
别太相信自己的经验，一个人的经验是有限，方向错了，时间也很难弥补。推荐看看 Berkeley cs50 和 MIT 的 system design 或者 distributed system。--- 我特别喜欢给那些喜欢琢磨命名的程序员推荐这些，个人的恶乐趣。
- 简单和优雅永不过时，虽然不推荐“屎上雕花”，但是坏习惯不是一天养成的，如果一个团队连基本的形式上的规范都不追求，迟早出纰漏。保证能用，努力好看，是一体两面，没有必要相互对立。
2.对前端的“卷”应该客观看待，前端各种框架层出不穷，也推动了今天前端的各种眼花缭乱的惊人发展，百花齐放百家争鸣，可以说前端的发展是跑在了前面，甚至开始由前端卷向后端，卷向前后端一体，也希望 ROR 这种后端也更加卷一些，宁可卷着生，不能躺着死。
- 软件工程是软件从低维度向高维度进展的阶梯，是软件哲学的工具化展现，不懂软件工程，不重视软件工程都只能看到井底的一片天。会写代码是术，软件工程是通向“道”的更高阶段。
软件开发者在职业生涯中很容易吸收各种噪声。各种价值观、方法论，有用的、没用的（比如多读优秀的开源代码）、有害的（比如“代码能跑就不要改”）混在一起。有些理念彼此矛盾，也可以存在于同一个人的脑子里。很需要不断地自己否定自己，修正自己对软件开发的理解。
不同的声音混在一起的时候，自己不加整理和过滤，很多概念是分不清的，很容易搞出来很多模棱两可的词，比如“太重”、“优雅”，你要他讲清楚这词到底指什么他大概是讲不清的。
比如有些人坚持 hash 只能用冒号，不得已的时候再用箭头，坚持方法调用只要有参数必须加上括号，然后声称自己有代码洁癖；有些人坚持代码里不能有重复，变量、方法和类的命名必须深思熟虑，也对外宣称自己有代码洁癖。二者虽然都是对代码的要求，但前者只是无所谓的风格，后者是要坚守的原则。但有时候人们喜欢用自己习惯的风格去强迫别人，说不清楚理由就把“优雅”这类词拿出来用。
一些人写代码喜欢平铺直叙，觉得这样最简单。另一些人喜欢给代码分块，让不同的模块各司其职。但二者都宣称自己讨厌复杂性，都同意软件开发就是在管理复杂度，都宣称自己的代码最“简单”。
不仔细区分这些东西，结果往往会因为 A 的问题而去否定 B。有时候这些人在一起讨论问题，经常看起来好像在聊同一个话题，实际上你在说 A 他在说 B，结果在结论上居然能达成一致（很可能只是因为这种说法流传最广、某“大神”说过、某书上写过）。某一天真让两个人在一起做事的时候才发现其实互相不理解：“他说的原来不是我所理解的，我说的他也没理解”。
在写代码这件事上避免“踩坑”的话，我总结就是：完成功能、消除重复、命名。无它。基本上等价于 Kent Beck 的：通过测试，消除重复，表达清晰，减少元素，以上重要程度递减。
很多的观点，我以前也多多少少说出过，但事情就是这样，听别人说是一回事情，自己亲身经历过那就是另一番不同的风景。总之，“纸上得来终觉浅，绝知此事要躬行”，就是这个道理。
