工程中的构架

构架

在代码编写和工程设计中，构架的好坏往往决定着模块代码编写和系统构建的不变性和灵活性。构架的好坏往往在根本层面上导致了实际开发中的效率和反碎片化问题。好的构架思维经常是会丢失的，被反复重新发现的。因此我们有必要不断收集好的构架设计，从中归纳不变的部分。

构架的图示

图片来自：https://iamsafts.com/posts/homelab-intro/

图片由本人根据网图制作

常见构架

1. 多进程模式
2. 插件模式
3. 多git仓库模式。

目录结构的设计就是构架

https://www.gobolinux.org/at_a_glance.html

一个模块化文件夹的Linux发行版，每个程序在/Programs下有一个完整的独立目录，包含了程序的所有依赖。这不是学习windows么。

沙箱技术

https://testcontainers.com/getting-started/

看上去不错的一个技术，解决云上程序运行的测试环境依赖问题，相当于开箱即用的container测试环境。

Common Mistakes in Modularisation

https://two-wrongs.com/software-design-tree-and-program-families.html

程序员很容易陷入自底向上的决策思路。而管理者/构架者更倾向于自顶向下思考/决策。如何平衡这两者之间的gap？模块化是一个有用的工具，模块设计抽象层和接口，隐藏下层的决策树细节。面向接口编程。面向接口构架/决策。

怎样才是在构架层面解决问题？

A software architecture describes how major components in a system interact, relate, and are organized. Good architecture design can lead to systems that scale, perform well, and are maintainable.

-- https://blog.logrocket.com/node-js-vs-python-how-to-choose-the-best-technology-develop-backend/

理解程序怎样运行是重要的

Since I believe the only way to use a platform efficiently is to have a clear understanding of how it works, I decided to dig deeper.

-- https://sahandsaba.com/understanding-asyncio-node-js-python-3-4.html

模块间圈复杂度

模块化重构：https://antennapod.org/blog/2024/05/modernizing-the-code-structure
Git 仓库：https://github.com/AntennaPod/AntennaPod
大规模模块化重构。重构后项目的模块之间的圈复杂度更低，整个项目在开发、测试和维护上获得好处。不过没有看到具体的指标数据，例如前后测试覆盖率的变化。