在强制家长培训中，一位小学数学的教学专家谈了一个案例 -

一道应用题，所有的同学都得到了它的解答算式 -

25*(5+7)

但是接下来，不同的同学就有不同的步骤 -

有些同学直接按照运算准则，计算 25 * 12，这是两位数乘法，小朋友无法口算，需要通过笔算竖式乘法。

爱思考的同学通过乘法分配律，计算 25 *5 + 25 * 7，避免了两位数乘两位数，可以口算完成，不用使用竖式。

更爱思考的同学计算 25 * 10 + 25*2，难度进一步降低了。

最爱思考的同学计算 25 * 4 *3 ，非常容易计算。

这个案例谈的是，通过变换计算的路径，避免复杂计算。（当然如果有可以秒算两位数乘法的小朋友，他可能会觉得“爱思考”的同学们不太好理解。）

软件开发者和架构师的日常工作中，常常也会遇到这个场景。设计方案可能容易发现，但可能不容易直接执行。

这时候我们的办法是变换我们的设计，改善它的可执行性，包括缓解在执行环节的风险。

在我看来利用设计变换需要注意一些原则 -

1. 设计变换是解空间的事，尽量不要涉及问题空间，也尽量不要干扰到设计本身。¹
2. 设计的变换需要有明确的目的。没事不要变换。这个目的要随时验证。
3. 设计的变换必须是等效的，不论怎么变，需要始终保证能解决最初的问题。
4. 设计的变换在这里实质是一种折中，跟所有折中一样，需要持续管理其影响。

上面几点，比较理想化。实际中，情况要复杂一些，但不影响谈原则。