前几天对自身在软件开发10年来的经验进行了一些思维和方法论上的思考，亦可用于日常问题的分析，巧的是最近在读的 [[Thinking in Systems - eBook]] 提供了更多理论支撑和案例迁移，让我挺开心的。因此记录一下。
我们面对的问题，是错综复杂的、不断改变的。一个具体的问题往往和其他问题牵扯，并且伴随着历史包袱，想要一次形梳理清楚，又缺乏足够的信息。如果形成了一个解决方案，却在实施后发现主要问题已经发生变化，或者成本结构发生了变化，方案可能不再匹配。你要如何开辟向前的道路？
一、分而治之。大分小；分层。
这种方法之所以一定有效，本质原因是所有复杂问题一定对应一个复杂系统，而系统本身在演化过程中，一定会产生层次性。即可以看作由若干子系统/层级组成，各子系统/层级内部的联系要多于子系统/层级之间的联系。只要建模和抽象的角度合适，就能如庖丁解牛一般，将复杂问题分解为一些正交的、解耦的、比原问题更简单的若干子问题。
分解问题的好处，第一是节省心智“内存”，即注意力可以聚焦在一处。第二是可以多人并行，互不干扰或阻断。第三是便于迭代，即有了新思路，可以逐步在子问题上修改和试错，不必推倒重来。
二、小步迭代。
如果说分而治之是对一个已成型的问题的有效分解，小步迭代则强调了持续演化中如何达成目标并兼顾系统的相对稳定。
在着手解决问题的过程中，逐步修正原来的设想、甚至重新发现正确的问题……这比一次性得到完美答案，要靠谱的多。另一方面，如果你构建的系统不支持渐进式的迭代，稍作调整就面临着牵一发动全身的困难，在面对变化时就会非常脆弱。而你我唯一确定的是，唯一不变的是变化永远会发生。
这也是只靠许愿式编程至今没有产生任何复杂商业软件的原因——只靠AI自己会让代码结构设计迅速劣化，难以持续迭代。
三、反馈回路。
通常提到反馈回路常常与系统自身稳定性相关的理论有关，不过这里想具体强调的是：一个系统的可观测性，以及围绕此作出的反馈回路的搭建，也应当成为解决方案的一部分。例如收集用户反馈、收集设备错误日志、监控服务器基础指标，然后在发生新情况时，通过一条链路，能够指导系统下一步优化或迭代，才能避免闭起眼睛跑步带来的不安、犹豫和落后。