IdeaWorlds 前端开发笔记（二）

本篇目标：介绍本项目的前端工程结构规范。

1. 为什么要有结构规范？

  • 合理的结构能让开发人员快速定位到与特性有关的所有文件
  • 良好的结构有助于拓展，当代码库随着功能丰富而增长时不会导致混乱
  • 对应用程序应该如何构建有一个共同的理解会让团队协作更容易

2. 遵循的原则

LIFT | Angular 风格指南

  • 快速定位代码

    坚持直观、简单和快速地定位代码，把相关的文件放在一起。

  • 一眼识别代码

    坚持命名文件到这个程度：看到名字立刻知道它包含了什么，代表了什么。

  • 保持扁平结构

    坚持尽可能保持扁平的目录结构。考虑当同一目录下有很多个文件时创建子目录。

  • T-DRY (Try to be DRY) 尽量不重复自己

    坚持 DRY（Don’t Repeat Yourself，不重复自己）。避免过度 DRY，以致牺牲了阅读性。

3. 工程目录

在上一篇 初始化前端工程 中，我们创建了一个空的多应用 Angular 工程，目录结构如下

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

idea-worlds
│ angular.json
│ ...
└─projects
    ├─console
    │  └─src
    │      ├─app           # 应用逻辑代码
    │      ├─assets        # 静态资源
    │      └─environments  # 环境配置
    ├─libs
    │  └─src
    └─www
        └─src
            ├─app
            ├─assets
            └─environments

在项目的根文件夹中可以看到应用和库都放在projects，并都有一个src文件夹用来存放代码。

4. 应用规范

现在我们要制定的是src/app内的规范。

先简单描述下常见的用户界面：

  • 页头：公共的头部，比如网站 logo、导航
  • 页尾：公共的尾部，比如网站信息、备案信息
  • 侧边栏：公共的侧边，比如导航、广告位
  • 内容区：显示当前页面的内容
  • 主导航：或者称为菜单，可放在页头或者侧边栏，用来切换内容区

当然，除了内容区其他部件都不是必要的，但大部分应用都是它们的组合，可以点此查看一些典型的布局 。 我们将这些控制应用布局的组件统称为应用外壳，将应用的功能组件统称为特性组件。显然，它们的代码应该存放在不同的文件夹下。而随着代码的日益复杂，一定会出现公共的东西（比如工具类），也应该有一个文件夹来存放这些公共代码。

现在，我们就可以确立第一个规范：

将代码文件分为三大类

1
2
3
4

app
├─features     # 特性组件代码
├─framework    # 应用外壳代码
└─shared       # 公共代码

随着应用功能的增加，代码文件会相对应的增长。如果都直接放在同一文件夹下，会使该文件夹非常杂乱且不易快速定位，这样违反了上面遵循的原则 。而要了解应用的功能特性，看菜单导航是个很好的方式，所以将features内的代码文件根据菜单划分就非常合理。

这样，我们就可以确立第二个规范：

根据菜单导航划分特性代码文件

1
2
3
4
5
6
7

app
├─features
│  ├─home
│  ├─idea
│  └─people
├─framework
└─shared

features文件夹内被划分成一个个特性区，为进一步隔离不同特性区内代码，我们将为这些特性区创建它自己的模块，这样可以对其它模块隐藏自己的实现，从逻辑上避免不同特性区的耦合。

我们在开发的时候，通常都要遵循单一职责原则，这在 Angular 代码文件中的体现就是：每个文件只定义一样东西（例如服务或组件）。这样特性模块内的代码就自然地形成多种类型文件，为避免太多文件弄乱文件夹，我们可以进一步划分它们。

根据类型划分特性模块内的代码文件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

app
├─features
│  ├─home
│  │  ├─components
│  │  ├─models
│  │  └─services
│  ├─idea
│  │  ├─components
│  │  ├─models
│  │  └─services
│  └─people
│      ├─components
│      ├─models
│      └─services
├─framework
└─shared

5. 公共库规范

以前还没这样做过，暂未想好，随着后续开发再补充吧。