前端项目须知
第一次做前端项目，有一些必须知道的事情。项目开发是一个团队协作的过程。就算项目是一个人开发，那也会遇到后期其他人维护项目的情况。所以代码是写给所有人看的，要有良好的可读性。并且代码要符合一定的规范，这样才能降低维护的成本，提升项目的质量。如果是多人协作开发，那就要对 Git 协作有一定的了解。
下面就来仔细讲讲做项目的一些常识：
命名规范
每个人的命名的习惯可能都不一样，但这样会导致每个人写出来的代码的风格迥异，最终导致代码可读性很差。所以我们要有一个合理的命名规范。
在前端，我们给出一个简单的规范：所有变量都使用驼峰命名（camelCase），除了常量使用全大写加下划线（THIS_IS_CONST），类的构造函数（包括所有 React 组件）使用首字母大写的驼峰命名，CSS 类名使用小写字母加中划线（header-container)，如果是使用 CSS Module 的话，使用驼峰命名。
这个规范不是唯一的，但在一个团队内需要遵守同一种规范。
代码格式和规范
这边的代码格式和规范主要指的是两个东西：Eslint 和 Prettier。Eslint 是一个 Linter，主要帮助检测前端代码中的问题，比如重复定义的变量，没有被执行的代码，等等，帮助我们优化代码，消除潜在的 bug。使用 Linter 可以规范我们的代码，并且这是自动化的，不用人工去 review，所以现在是前端项目必备的。
Prettier 是一个代码格式化工具。代码格式是什么风格其实无关紧要（比如几个缩进，语句末尾是不是要加分号），但一定要保证所有人的代码格式都是用的同一种规范。Prettier 就是一个格式化工具，它内置了一套规范，Prettier 配置好之后 Git commit hook 之后，会在每次提交的时候去格式化你的代码。所以不管你把代码的格式搞成了什么样子，我们都可以确保在项目仓库里的代码都是统一风格的。使用了这个工具之后，我们就再也不用关心代码格式化的问题了。
总结一下，对于每个前端项目，我们要确保这个项目配置了 Eslint 和 Prettier 的 Git commit hook。
Git 协作
Git 协作这块主要需要让大家搞清楚几个概念和问题：
- Git 分支是什么？有什么用？
- git fetch, git merge, git pull 这几个命令的作用是什么？
- 什么是 git 合并冲突？冲突了如何处理？
前端工程化
成熟的语言一般都有自己的构建系统，构建系统包括很多的相关工具，可以帮你把代码构建成可以最终执行的产物，并且可以在过程对代码做一些优化或者其他想做的转化。
前端也从 HTML + CSS + JS 的时代，走到了一个工程化的年代。Webpack 帮助我们把 JS 模块打包成几个最终的 JS 文件。Webpack 执行的过程中，会使用 Babel，TS 编译器 等工具对代码进行转译，这样我们就可以写 ES6 或者 TypeScript，然后产出一个 JS 文件给浏览器执行。CSS 方面也有 Less/Sass/PostCSS 等工具，可以使用高级的语法来写 CSS，让代码更精简。
这些工具的配置往往比较繁琐，所以现在写 React/Vue/Taro 等框架的项目，都会有对应的脚手架。脚手架已经集成了那些工具链，我们只要使用就可以了。
需要注意的是，脚手架初始化的时候会让我们选择要用什么类型的 JS，比如 ES6 或者 TS，又或者会让我们选择使用什么 CSS 预处理器。这个时候就要谨慎的选择，按项目的技术选型去做。
新手往往会忽略 CSS 预处理器，但直接用 CSS 是非常低效的。如果脚手架给你选择，我们一般会用 Less（Sass 的依赖安装很慢）
项目管理
这部分见团队内部文档 /project/17/doc/182。
前端设计
在比较规范的开发中，需要对待开发的需求做一个分析，这就是所谓的设计。
设计的过程可以帮助你理清需求以及页面的组件结构，识别难点，找出通用组件。如果有设计 review 那就更提高了设计的质量。如果没有，那也是一个自我梳理的过程，比起直接上手写要清晰很多。
最终产出的是一个文档。里面主要包括：
- 描述开发的需求，比如实现 xxx 效果，或者开发 xxx 页面，或者增强 xxx 功能。如果这个需求是由某个原因提出来的，可能还需要写一下需求的背景。
- 组件拆分，列一下页面上有哪几个组件，用一颗树的形式描述。组件是指业务组件，底层如果用了通用组件，那层不用写出。
- 通用组件，列一下页面上会用到哪些通用组件。如果是新项目或者这个组件目前没有，那就需要识别这个组件是否是一个通用组件。
- Model 设计（使用了 Redux 等状态管理方案的项目，需要写这块）
- 难点分析，根据具体的情况，列出难点并给出方案。（没有难点就不用写）