重构:首先要让改变变得容易?


First make the change easy, then make the easy change
首先使改变变得容易,然后再做改变

这句话来自肯特-贝克,他是一位软件开发者,也是极限编程方法的创造者。

当面临艰难的改变时,首先让它变得容易被改变。

重构代码可能是一个挑战。软件项目往往会随着时间而增长。如果不加控制,它们会变得毫无章法,难以推理。意大利面条代码是一个离这种混乱永远不会太远的术语。

在某种程度上,这句话是说 "先做你应该一直做的事情;有条不紊",然后做你再开始做要做的事情(如增加一个功能,修复一个错误)"。

虽然这里的背景是软件开发,但这句话的精神也可以适用于其他地方。当我发现自己被困在不同的选择之间,我就会参考这句话。我会问自己:"为什么这个决定难以做出?" 不可避免的是,这是因为我的思想没有条理,我没有充分的信息,所以对任何决定都感到很舒服。

banq:
关键是:如何实现”首先使改变变得容易?“,软件代码是一个特殊事物,是人类思想的载体,除非你完全理解编写一段代码时当初的意图和想法,否则真的很难去改变修改它。

那么当你试图去理解另外一个人的思想和想法时,这就变成世界上最难的事情。

打个比喻:你觉得哲学好学吗?当你只了解马克思哲学时,觉得很简单,但是历史上有那么多哲学家,从柏拉图 亚里斯多德 康德等等,每个人思想相似又不同,学习哲学就是需要了解他们不同的想法,学习哲学就是掌握不同哲学家的思路,有些哲学家思路很不同寻常,切入点很难,甚至类似精神病人思路。(天才与疯子是一纸之隔)

"认知负荷/认知负担"是限制一个人修改另外一个人代码的主要原因,也是使用模板、框架等工具的阻力所在。

这里不是想否定软件上的重构,但是重构真的如同敏捷一样,又一次变成一个纸上馅饼,只是一种投机大众认知心理学的一种营销手段而已,因为人们不敢一下子打破旧系统,不愿意冒太大风险,喜欢小修小改,这对于社会大型复杂系统可能是正确的。

微服务当初的一个目的是:使得一个服务能够立即被重写,而不是被重构。这样当一个微服务出现问题,不是花时间去重构,而是找一个人重写它,这是实践中最有效的办法。

banq的观点:不要去修改重构它,而是直接替换它!在替换之前让替换成本变得更小。

如同CRUD增删改查中,只有CRD;如同只追加的事件溯源;如同区块链;如同记账模式;如同流水账管理钱财一样,把代码当作你的财务系统,代码代表的是你的商业价值,类似记账本记录你的金钱价值一样。

下面这篇文章从弹性角度谈了微服务与Actor模型区别,但是同样没有从程序员认知负担角度看清这个问题,任何解决方案都必须将”认知负担“作为落地措施的重要考量因素:
弹性工程设计:Actor模型与微服务架构比较