当前位置：首页 > article >正文

框架与代码的形状

article 2025/2/4 23:41:32

作为一个代码的设计者，我之前讨论过代码的形状，从“名字”出发，进行讨论。代码的形状：重构的方向-CSDN博客

从比喻的角度来看，名字似代码的血和肉，而框架则似代码的骨架。

猎豹和大象

在大自然中，每一种动物都有自己的骨架，因而有了自己的特性。

猎豹的骨架结构使其能够快速奔跑——它的脊柱高度灵活，四肢修长且肌肉集中，这种极致的优化让它成为陆地上速度最快的动物。然而，这种特化也带来了代价：猎豹的骨架无法支撑过重的身体，也无法适应复杂的地形。相比之下，大象的骨架结构则显得厚重而稳健——它的四肢粗壮如柱，脊柱坚固且略微拱起，这种设计让它能够承载数吨的重量，并适应各种复杂环境（如沼泽、丛林）。然而，大象的骨架也限制了它的灵活性，使其无法像猎豹一样快速奔跑或急转弯。

之所以用猎豹和大象来做比喻，也是因为它们也对应了两种典型的框架思路，“显式框架”和“隐式框架”。

典型的显式框架，如React、Vue，就像猎豹的骨架一样，高度特化，专为速度而设计。借助这些框架，我们能够迅速搭建起项目，项目的完成周期甚至可以缩短至以周计。至于隐式框架，我认为将其称为非显示框架或许更为贴切，它更适用于处理那些具有不确定性的，酷似丛林探险特征的任务。

我也很幸运，最近同时在处理一个Vue3的项目和一个为vue3服务的cli。前者使用了上面讨论的显式框架，后者则使用了隐式框架。

显式框架-Vue3

这个Vue3项目是基于Geek-Admin来二次开发的。Vue 3 项目中典型的文件夹结构（如 hooks、views、components、routes）正是其显式框架特征的直接体现。这种结构不仅反映了 Vue 3 的设计哲学，还展示了显式框架如何通过约定与约束塑造代码的形状。

一、文件夹结构的显式特征

components：组件化约束
- Vue 3 强制开发者将 UI 拆分为可复用的组件，每个组件是一个独立的单元（.vue 文件）。
- 显式体现：组件必须放在 components 文件夹中，遵循单文件组件（SFC）规范。
- 示例：
```
/components
  /ECharts
      /index.vue
      /config
          /index.ts
  /ProTable
      /index.vue
```
views：页面级抽象
- views 文件夹通常用于存放页面级组件，每个页面对应一个路由。
- 显式体现：页面与路由的对应关系通过文件夹结构清晰表达。
- 示例：
```
/views
  /about.vue
  /assembly
      /batchImport
          /index.vue
          /index.scss
```
routes：路由集中管理
- Vue Router 的配置通常集中在 routes 文件夹中，显式定义路由与组件的映射关系。
- 显式体现：路由配置与页面逻辑分离，便于维护和扩展。
- 示例：
```
// /routes/index.js
const routes = [
  { path: '/', component: Home },
  { path: '/about', component: About },
];
```

hooks：逻辑复用抽象

Vue 3 的 Composition API 鼓励将可复用逻辑抽象为自定义 Hook（类似于 React 的 Hooks）。
显式体现：逻辑复用代码集中在 hooks 文件夹中，与 UI 组件分离。

示例：

// /hooks/usePagination.ts

import { ref } from "vue";
import type { Pageable, DataLoader } from "@/components/interface";

   export function usePagination(
     initialPageSize: number | null, // 初始化每一页的数量，如果为null，则表示不处理翻页
     loadCallback: DataLoader | null // 翻页回调，如果设置为null，那么将不处理翻页回调
   ) {
     ...
   
     return {
       pageable: _pageable,
       ...
     };
   }

上面是基于vue框架呈现出来的代码形状，我们一般都用这样的文件结构去一步一步地搭建基于vue的项目。

为什么呢？因为它符合vue显式框架的特征。

约定优于配置
显式框架通过文件夹命名和文件位置显式定义代码的职责（如 components 存放组件，views 存放页面，hooks 存放可复用的逻辑，stores 管理全局状态）。这种“约定优于配置”的设计，不仅降低了项目的维护门槛，还让开发者能够快速理解代码结构，从而提升团队协作效率和开发速度。
职责分离
显式框架通过文件夹结构实现职责分离（如 components 负责 UI，stores 管理状态，hooks 封装逻辑），使得不同开发者在维护同一项目时，能够自然地遵循高内聚、低耦合的设计原则。这种一致性不仅降低了沟通成本，还让代码更易维护和扩展，从而有效抵御代码腐烂，延长项目的生命周期。

显式框架的特征还体现了高度的可预测性，基于显式框架的约定，可以快速估算出需要开发的页面数量及组件数量，因而使得项目的开发周期更容易量化和评估——无论是新功能的添加，还是问题的排查，开发者都能快速定位相关代码，从而提升整体交付效率。

与显式框架不同，隐式框架则是另外一番景象。

隐式框架

首先隐式框架并没有约定的文件目录结构，也就是说它没有事先的约定来指导代码的功能与代码形状之间的关系。例如，在上面讨论的显式框架Vue中，公共的UI组件，放在components文件夹下，页面放在views文件夹下等。同样，在隐式框架中，对于即将增加的新功能，应该将其安放在何处，也没有像显式框架那么显而易见。

安放在何处也许就是隐式框架本身的答案。

之前写了一篇文章代码设计的几个关注点，这也算是我在隐式框架主题上的一次探索。在那篇文章中，我讨论了通过重构变量名和文件名来解决安放何处的问题，同时也提到了“王阳明”先生的“心即理”。如果非要用一句话来概括，“逻辑上的合理性”吧。

在但后面的思考中，我发现很难用一句话，或者不应该用一句话来阐述隐式框架，原因很简单，如果可以，那它就不是隐式框架了。

像vue3-project-cli这样的项目，本身就是探索性的，没有明确的目标，就像在丛林中探险，猎奇，甚至还有一些碰运气的成分。

对于这个项目，开发语言使用的是Rust，命令行参数使用的是clap，typescript代码的处理使用的是swc，数据的反序列化处理使用的是serde。这3个库在Rust生态中的使用频率极高，具备了显性的特征。也就是说，在Rust的生态中，涉及读取命令行参数的相关功能，都会选择clap，涉及到typescript或者javascript的相关ast的处理，都会选择swc，涉及到序列化与反序列化，动态数据的读取，都会想到serde。

但如何组织这些功能的代码，却没有一个显式的约定。但没有显示的约定并不意味着没有章法，接下来进入命令式和函数式的话题。