2021 November 16

我们需要建立“开放式架构”的思维模式

今天在听CHAOSS China的一档播客节目《Episode#01-聊一聊有机的开源运营》，突然连贯着想通了一个架构方面的问题。

1. 自建模式

早期的架构，早期的代码，我们几乎都是从头开始的。所以，所有的问题都由我们自己解决，当然所有的风险也都是我们自己造成的。

那20多个设计模式，每一行代码我们都看在眼里。要在自己的项目里使用，当然也是一个字母，一个字母的敲进电脑里。

即使后来的IDE工具非常先进，能够帮忙自动生成代码，或者帮忙重构代码。那些代码，依然是我们自己掌控的。

在自建一切的概念下，架构当然也是我们自己搞定。ER图是我们自己画的，数据库表结构是我们从头定义的。每一个模块，我们分工以后，也是一个一个的写出来的。

我们会阅读一些技术文章，了解一些最新技术。然后：还是会自己去写代码。在开源繁荣之前

当开源越来越多之后，我们的架构思维并没有发生变化，只是在开源社区里，发现了很多“好东西”，我们可以拿来就用。

所谓黑洞，就是一种心态的“切割性”。外面的开源项目，外面的代码，那是外面的。当我们下载代码回来以后，这就变成了我们自己的代码，我们想怎么用，就怎么用，想怎么改，就怎么改。

为了保持可控性，我们沿用了自建模式的传统思路，尽可能吃透所有外面的代码，把他变得像自己的代码一样熟悉。当然，接下里我们会持续使用这些代码，但是“回馈”？不存在！

事实上，我们后来才发现，软件不是写完一次就完成了的。他们会不断的出新的版本。

我们自己的代码，也会不断生长。我们会维护一个越来越庞大，臃肿，甚至无法理解的代码库，然后小心翼翼地修改代码，“定期”发布新的版本。

我们以前觉得，那些可以拿来就用的开源组件，其实也在不断的推出新版本。那些新版本的功能，我们也很喜欢。但是：我们的上一个版本，用了“上一个版本的”开源组件。

当我们想要同步升级的时候，真正的痛苦出现了：“我们没有为升级，做过准备”。当初就是拿来就用，甚至随便乱改，随便乱用。

所有这一切，都在不断变化/生长之中

要更加重视开源选型
- 用哪个开源框架作为项目的底座？还是用自己的框架作为底座？
- 哪些组件应该自己开发，哪些可以选用开源的组件
在使用开源软件、组件的阶段，也需要更多的思考
- 区分主动依赖的开源软件，以及由开源软件的依赖，引入的“被动依赖”
- 在架构设计时，应该考虑如何预防与隔离，由开源软件引入的各种风险
- 要关注开源软件的生命周期，及时替换掉已经过于老旧的开源软件版本
我们要关注开源软件的修改问题
- 最好不要修改（以便更好的升级新版本）
- 能不能只在外围修改，或者做一个适配层？
- 如果一定要修改，如何才能正确的修改？
  - 如何定义正确呢？我的建议是以社区是否会接纳为准
- 我们的修改，是否能够尽快回馈到上游社区？
  - 我们是否在做通用性的修改——对别人也有用
  - 我们是否隔离技术需要的修改与业务需要的修改？
  - 我们的这些修改，如果回馈到上游，是否会损害我们的竞争力？

也许，我们应该放弃将静态的，一段一段的代码，视作竞争力的思路。在一个不断生长的，开放式的架构模式下：生长能力、适应性、松耦合、架构可靠性这样的能力，才是一款软件的核心竞争力。

只有在架构观念转变的基础上，我们才能够真正理解：为何Upstream First并不是在做慈善，而是一种对于企业来说，更加富有竞争力的架构策略。

愿与大家共同探讨！