前端架构-工作流设计

3.1 代码之旅：基础规范

• 规范代码组织结构
• 统一代码风格，即源代码的书写风格
• 组件、函数等命名规范
• 开发工具规范

3.2 代码组织决定应用架构

确定应用架构时，应该按照与架构相似的方式来编写。并在架构未来发生变化时，相应的更改代码的组织方式。
比如vue-cli2架构升级至vue-cli3.0时的架构变化。

3.3 统一代码风格，避免架构腐烂

虽然每个人都有自己的口味，但是作为一名厨师，应该做出符合大众口味的菜。

3.4 使用Lint规范代码

比约定规则，靠自觉遵守更好的方式是，借助代码扫描工具检测、提示、修复代码风格。
诸如：TSLint、CSSLint、ESLint…

3.5 规范化命名，提升可读性

3.5.1 命名法

常用的命名规则有以下几个:

• 驼峰命名法。
• 下划线命名法。Python语言中特别流行。
• 匈牙利命名法：属性+类型+对象描述。如“strFristName”。

对于前端团队来说，我们需要统一项目的命名规则，以降低项目的成本。

3.5.2 CSS及其预处理器命名规则

技术栈统一的前端团队，同样需要一套统一的css命名规则。

3.5.3 组件命名规则

组件命名有如下几种方式：

• 按照功能命名，如：SideBar就是一个侧边栏功能的组件。
• 按页面来切分组件，如：NewsItem就是用于展示新闻的组件。
• 按照上下文来命名组件，如：NewsChildItem体现了与上个组件的关系。

3.6 规范开发工具，提升开发效率

以下适合在项目中使用的插件：

• EditorConfig，如：（EditorConfig for VS Code），可以读取项目中的.editorconfig配置，以遵循统一的编辑器规范。
• Lint插件,如：（ESLint、HTML Hint），显示Lint问题。
• 单词拼写检测，如：（Code Spell Checker），提示代码中拼错的单词。
• 路径补全，如：(Path Intellinsence)，提示可用资源路径。
• 代码自动补全。
• Emmet插件，如：（JavaScript (ES6) code snippets），想要快速编写代码（砍柴），有时需要投入学习成本（磨刀）。
• 代码格式化，如：（Prettier - Code formatter）。

*注：括号内是相应的VSCode插件名。

3.7 项目的文档化：README搭建指南

一份好的搭建指南具有如下特点：

• 支持运行的环境。
• 必要的依赖准备，以及如何搭建。
• 项目的安装指南。
• 线上的示例或最后的运行环境。
• 相关的文档链接。
• 相关人员的联系方式，讨论群。

README文档里包含这些必要的资源，能大大的提高开发人员的效率。

3.8 绘制架构图：减少沟通成本

对于复杂项目的架构图主要展示各子系统之间如何通信。
对于简单的系统，架构图则可以是由项目的技术栈组成的。

绘制架构图，既可以用代码生成，也可以使用专业工具绘制。

• 代码生成工具，如：Graphvis
• 专业工具，如：Dia
• 软件附带工具，如：Office、SmartArt
• 在线工具。

3.9 可编辑文档库：提升协作性

优先关注于其是否可以版本化、图形可视化，以及追踪历史修改。
它可以是：
——可以记录版本历史的维基(Wiki)软件。
——专业的协作工具,比如Atassian的Confluencea。
——基于Git+Markdown的代码管理工具。
它应该还能支持以下功能:实时多人编辑、内容索引、图形可视化、实时搜索、打标签、检查清单、导入导出等。

3.10 记录架构决策：轻量级架构决策记录

下面是一个由adr命令生成的adr0架构决策记录的示例，它由以下六部分组成：
◎ 标题。
◎ 日期
◎ 描述决策相关的状态,包含提议、通过、完成、已弃用、已取代等。
◎ 价值中立的、用于描述事实上下文的背景。
◎ 应对这种场景的相应的决策。
◎ 记录应用决策后产生的结果。

3.11 可视化文档：注重代码的可读性

穿插生动形象的展示，代替文本文档，web交互演示、图表等。

3.12 看板工具：统一管理业务知识

方便追溯业务变更带来的代码修改。

3.13 提交信息：每次代码提交文档化

• 项目方式，任务卡号与提交关联。
• 开源项目方式，采用标准化的提交信息，自动生成ChANGELOG文件。
  工具如：standard-version。

3.14 通过流程提高代码质量

3.14.1 代码预处理

代码提交前常见操作：

• 静态代码分析，如：TSLint、ESLint。
• 运行测试。

3.14.2 手动检视代码

这种方式带来一系列的好处：
(1)提高新成员的编程水平。
(2)保证代码规范得以实施。
(3)每个人对项目的代业务都会很熟悉。
(4)提供项目代码的质量
(5)帮助成员熟悉工具和快捷键的使用。

代码检视，常见有两种方式：

1. 常规代码检视。每天固定时间讲解自己当天写的代码。
2. 阻塞式代码检视。git提交审批，前提是，其他检视者能够带责任感地去审视代码。
3. 其他。经常检视团队人员写的代码。

3.15 使用工具提升代码质量

• 利用代码扫描工具，如Sonar，检测编程语言上的错误、代码的坏味道和安全漏洞。
• 利用IDE，通过快捷键重构代码。

3.16 测试策略

---

《前端架构：从入门到微前端》——知识点整理。