P1 攻城狮的江湖总结-项目篇

这是一篇对于前端项目工作与规范的总结，有助于快速启动项目，进入最佳开发状态。

单枪匹马在前端战场上厮杀两年多，创业公司没有独立的前端团队，也没有专门的前端项目规范，久而久之自己就成了前端的自我规范。

新项目的启动，需要考虑项目场景、开发环境、前端技术栈、UI 库、代码规范、API 接口格式规范等。没有总结，就没有规范，每个新项目都要重新定制一套模板，事倍功半。

一个人的规范，一群人的模板，模板策略，降低新成员的适应成本

1. 项目的使用场景

-产品经理：我们要做一个项目，用户群体来自公众号和浏览器
-攻城狮 1：移动端 web 项目（基于微信公众号开发）

-产品经理：给我们公司做个官网吧。
-攻城狮 2：响应式 web 项目（多屏幕尺寸 UI 兼容）

-产品经理：给我们的公众号项目和官网做个管理台，监控数据以及发布一些资讯和新产品
-攻城狮 3：GET，我最喜欢写纯 PC 网页项目了

-产品经理：这个月的任务可能有点多，不过我相信你可以做到的，也就是我们公司需要一个自己的电商平台，用户可以通过微信公众号、微信小程序、QQ 小程序、支付宝小程序、快应用等通道浏览我们的电商产品。
-攻城狮 4：再见 👋

前端技术栈广泛如浩瀚长江，各路攻城狮直呼学不动。
学不动是你们的，需求还是要做。
这个项目，选用什么技术去做，与项目的使用场景和应用类型息息相关。

ESlint 可组装的 JavaScript 和 JSX 检查工具。以我司为例，目前是围绕 VUE 做技术选择，Vue-Cli 脚手架自动整合了 ESlint，所以大部分项目使用 ESlint 做代码检查工具
Prettier An opinionated code formatter。ESlint 做到了代码语法检查和自动修复，结合 Prettier 在编码过程中代码格式化可以让我们编码更加舒适
Front-End Coding Guidelines 凹凸实验室前端代码规范。大厂的规范往往值得我们去翻阅和借鉴，凹凸实验室的这套前端代码规范，很大程度的帮助我改掉了一些代码编写陋习

8801631007166_.pic.jpg

Sass 官方自称是世界上最成熟、最稳定、最强大的专业级 CSS 扩展语言。显然，官方的话过于肯定，不过 Sass 确实是当下非常流行的 CSS 扩展语言，使用 Sass 可以提升编码幸福度

据我所知大部分公司都是由后端人员去定义和编写 API 接口文档。不过，我确实不建议后端攻城狮们完全按照自己的想法去定制接口格式。一个好的 API 接口规范可以提高前后端协作效率。

API RESTful Laravel 是优雅的 PHP Web 开发框架。我司后端使用 Laravel 开发接口，Laravel 接口开发本身也是一种规范，前后端按照这个 RESTful 可达成一致，方便沟通，提高效率。

接口设计注意事项

接口版本问题：当一个接口使用场景较多，修改的时候就需要慎重，做到向下兼容。某个场景需要添加多个参数，可使用 option 对象格式新增，免去修改其他多处场景。
数据类型：请求参数与响应主体都需要严格约束数据类型，例如：String 与 Number 类型不可混淆，如果响应 Data 返回 page='3'，那么 web 处理数据还需要手动转换数值，理应为page=3，避免多余的 js 处理

提交则日志，版本管理的好，定位问题时间少。大多数时候我们会选择 Git 版本管理工具。

基本要求：开发新功能必须新建分支；提交必须注释；
分支名称：master 为主干也为正式生产环境版本，开发主分支为 dev_2020，功能版本使用feature_name；
合并规则：功能分支合并到开发主分支 => 开发主分支进行 Code Review 后提交并测试 => 测试通过后合并入主干 => 冒烟并发布；
注释格式：type + 本次提交内容，type 类型简单分为五类：feature(提交新功能)、fix(修复某 Bug)、perf(性能优化)、Code Review(代码审查)、build(构建版本)；

文章属于自我江湖总结，有疑问欢迎提 Issues，如果也帮助了你，请为攻城狮点个赞 0-0

转载声明 请注明作者，注明原文链接，有疑问致邮 kingwyh1993@163.com