其他经验

一个文件的修改会影响哪些范围

• 每个组件都要在头部说对这个组件进行说明
• vscode可以通过查看引用查看
  • 但是引用不包括import()引入的地方
  • 别名需要jsconfig.json或tsconfig.json支持
  • tsconfig.json的优先级高于jsconfig.json，当同时存在且tsconfig.json中没有别名配置时，以tsconfig.json的配置为准

树摇

• 一个export只要没被别人引入就可以树摇掉

README应该包含的内容

1. 打包的特殊设置和变量 (如果有的话)
2. 项目简介（项目的业务个绍及目标人群，有利于推断代码的逻辑）
3. 项目的目标环境，比如企微h5，微信小程序，浏览器等
4. 项目的访问地址、访问入口或者小程序名称
5. node版本，依赖管理工具
6. git的管理方式，从哪里建分支，什么分支对应什么环境
7. vscode使用说明（推荐插件说明、代码片段等）
8. css 选型
9. 外部库使用说明
10. 文件目录结构说明（公共组件、方法说明）

组件的整合与拆分

1. 遵循业务相似性，80%的业务共同处就应该整合为同一个组件，随着业务变化再进行拆分
2. 遵循视图相似性，不同业务的相同视图应整合为同一个组件，但记住这是视图组件不应当包含任何业务相关代码，避免视图组件在扩展中变为业务组件

组件的注释

• 能够帮助你快速了解这个组件被引用的范围及涉及到的页面，对于避免修改造成的次生bug有帮助
• 能够帮助快速的了解项目的功能结构

冗余代码

• 不需要的代码直接删除，八成以上不会恢复使用，即使要恢复也可以通过git恢复
• 大量没使用但却存在引用关系的代码会降低打包速度并增加后期维护的成本，排查相关性的范围被扩大了。

gitLab特点

• 分支对比，需要使用较多提交的分支作为Source才能显示差异。例如dev和master比较，需要把dev作为比较的Source
• 对比时会显示Target分支不包含的提交，但是可能没有文件差异。例如Source中存在提交和这个提交的Revert。
• 对比时认为遴选的提交不是两个相同的提交

gitflow分支管理规范细则

• 只能从master拉取release发布分支
  • release命名规范：release/{{日期}}，例如：release/20240220
  • release发布成功，由创建人合并到master中并为master打上标签，从master拉下个发布分支能够确保这步被执行
  • release放弃发布，以master作为生产分支恢复生产环境，从master拉下一个发布分支能确保发布失败的release中的内容不会被误带上生产
  • 过期的release即告废弃，不可再作为ver和生产的发布分支
  • 不确定什么时候上生产，但需要在ver测试的内容应当建立release/{{当天日期}}的分支，在确定发版日后重新建立当前的发布分支，并通知测试重新测试，以确保ver环境和生产环境代码一致
• 开发分支
  • 从dev建立开发分支，可以作为个人长期开发分支，定时同步dev分支到自己的开发分支
  • 个人长期开发分支和dev分支之间采用合并而不是遴选提交
  • 当确定需求废弃或长期搁置，应当在开发分支中回滚相关提交，并合并到dev中，以尽量保持dev和master的代码同步。两边代码尽量同步可以减少从开发分支遴选代码到release时的冲突。

npm

• node-pre-gyp 在安装依赖过程中会通过这个工具直接下载二进制文件
  • 二进制文件的地址在依赖的package.json的binary中定义
  • 可以通过 .npmrc 中设置 canvas_binary_host_mirror=https://registry.npmmirror.com/-/binary/canvas 来设置 canvas 的二进制来源