在日常 JavaScript 中养成不可变的习惯

前言

先演示数组和对象是如何被意外修改的，再把这些写法换成团队本周就能采纳的习惯。

常见的翻车姿势

跳过这一步的团队，通常会踩中三种坑：

• 优化了一个没人同意要动的数字。
• 照抄了约束完全不同的项目的方案。
• 一直推迟决策，直到反悔的代价高得吓人。

建议的切入方式

1. 用用户的语言，一句话讲清楚问题。
2. 选择一个每周都能度量的信号，而不是只在上线当天看一眼。
3. 给小实验设定时间盒；两天的 spike 胜过两周的辩论。

小结

如果 Functional Programming 教会了我们什么，那就是「无聊的一致性」打赢「聪明的一次性方案」。把学到的东西带回团队，别让它变成口口相传的都市传说。