从软件思想抽象出几条做事原则

从紧耦合到松耦合

解耦的目的是为了灵活的组装和匹配。

我们希望通过解耦，实现各个模块的充分自治，受到外界环境的影响足够小。

所以我一般会把系统分成三层：

1. 最上层是流程层，是我们和产品沟通的主要层次；

2. 最下面是领域层，是研发需要专注建设的一层；

3. 中间是编排层，实现了不同场景、不同能力对于底层能力的组合与编排；

所以松耦合是灵活编排的基础。

现实生活中解决问题道理类似，我们首先需要储备足够多不同特殊场景下的专业解决能力，也就是知识库；还需要识别不同要求下的方案目的，然后灵活组装解决问题，也就是我们的最佳实践。

架构是个从静态到动态的过程

我认为架构是处理元素+关系。

如何针对不同场景灵活组合与编排这些元素和关系就是架构的过程。所以架构是个从“静态到动态”的过程。

很多人仅仅把架构看做是静态的事情，导致架构缺少演进能力。

在工作中，类似的问题同样存在。

比如在ppt汇报时，会发现有大量的静态内容，缺少动态内容，也就是说讲结果多，但缺少why和how的部分。

以ppt来说，需要同时呈现静态和动态两部分：

1.  动态部分：阶段、流程、活动、演进；

2. 静态部分：组成、架构、结构；

3. 
   

动态部分是让整个ppt叙事有了活力，便于更好的将倾听者拉入语境里。

了解一个新事物逻辑是一样的，看到事物的第一眼，我们获得的是外形或结构，是静态的。如果我们想深入了解一个事物，就需要去了解组成之间的组成过程，也就是事物是经过如何演进到今天这个结构的。

再好的结果也不具备可复制性，只有掌握了这种科学的思考过程和方法，才可以不断复制好的结果，也就是方法论的必要性为什么要积累方法论。

技术好，体现的是解决问题的能力

很多时候我们讨论什么是技术好，其实这个很难定义，算法好？架构好？中间件好？前端好？java基础好？技术好应该是个综合结果，也就是通过技术手段拿到结果、解决问题的能力。

而解决问题最重要的一点是，我们应该知道他是个什么问题？找到入手解决的点。

解决一个问题的手段有很多，我们需要做归纳、抽象，形成自己的概念模型，形成最小的知识集，并建立索引，在需要的时候可以快速调出来。

这里体现的就是软件工程里面的抽象与泛化。

其实我们做编程时候的接口声明就是解决这个问题的。声明一个接口，只有方法，没有实现。但他是个思维框架，究竟怎么实现，可能需要深入到具体场景下去探查了。

一个人最有价值的能力是模式和方法论，在他所实践的所有事情上做积累、抽象，形成知识库与匹配模式。