（一）工具的应用
1. 接口文档管理平台：YApi 是一个可本地部署的、打通前后端及QA 的、可视化的接口管理平台，以接口文档为准进行开发。降低沟通成本。
1.1 Yapi 是什么？
YApi 是高效、易用、功能强大的api 管理平台，旨在为开发、产品、测试人员提供更优雅的接口管理服务。提供了 api 文档管理，api 数据模拟（Mock），调试和自动化测试api 等功能可以帮助开发者轻松创建、发布、维护API，YApi 还为用户提供了优秀的交互体验，开发人员只需利用平台提供的接口数据写入工具以及简单的点击操作就可以实现接口的管理。
1.2 为什么使用yapi
主要解决前后端分离带来的以下痛点：
1、接口文档不可靠。很多小伙伴管理接口文档，有使用wiki 的，有word 文档的，甚至还有用聊天软件口口相传的，后端接口对于前端就像一个黑盒子，经常遇到问题是接口因未知原因增加参数了，参数名变了，参数被删除了。
2、mock 数据生成方案没有统一出口。我们都有这样的经历，前端开发功能依赖后端，解决方案有自己在代码注入json 的，还有后端工程师临时搭建一套测试数据服务器，这种情况下势必会影响工作效率和代码质量，也不能及时进行更新。
3、资源分散，无法共享。接口调试每个开发者单独维护一套Postman 接口集，每个人无法共用其他人的接口集，存在大量重复填写请求参数工作，最重要的是postman 没法跟接口定义关联起来，导致后端没有动力去维护接口文档。
4、集成api 自动化测试困难。yapi 提供了可视化的api 自动化测试方案，只需要简单的填写参数，增加断言，就能实现api 自动化测试。
1.3 特性
· 基于Json5 和Mockjs 定义接口返回数据的结构和文档，效率提升多倍
· 扁平化权限设计，即保证了大型企业级项目的管理，又保证了易用性
· 类似postman 的接口调试
· 自动化测试, 支持对Response 断言
· MockServer 除支持普通的随机mock 外，还增加了Mock 期望功能，根据设置的请求过滤规则，返回期望数据
· 支持postman, har, swagger 数据导入
· 免费开源，内网部署，信息再也不怕泄露了
1.4 相关文档：
官网：http://yapi.demo.qunar.com/
使用文档: https://yapi.ymfe.org/documents/index.html
github：https://github.com/ymfe/yapi
部署参考：https://www.jianshu.com/p/361d796649c7
2. 前端接口mock：前端根据接口文档mock 数据进行开发，解决联调前前端无数据问题
2.1 mock 是什么？
2.2 如何在后端接口完成的时候,取消mock 数据?
根据webpack 环境,在需要mock 的时候,配置环境为mock, 在不需要mock 的时候,只需要修改node_env 环境就可以了
无需注释代码, 就可以完美解决后端接口还没完成的情况。
3. 图标一律使用Iconfont，图片一定要压缩并尽量使用PNG 格式；
3.1 什么是Iconfont ?
Iconfont 是国内功能很强大且图标内容很丰富的矢量图标库，提供矢量图标下载、在线存储、格式转换等功能。阿里巴巴体验团队倾力打造，设计和前端开发的便捷工具，已收录28 万+图标素材。
3.2 Iconfont 的优缺点：
优点：（1）文件加载体积小；（2）可以直接通过 CSS 的 font-size， color 修改它的大小和颜色，对于需要缩放多个尺寸的图标，是个很好的解决方案；（3）支持一些CSS3 对文字的效果，例如：阴影、旋转、透明度；（4）兼容低版本浏览器。
缺点：（1）矢量图只能是纯色的。（2）制作门槛高，耗时长，维护成本也很高。
3.3 如何使用Iconfont
（1）使用第三方阿里巴巴Iconfont 平台，然后直接上传你自己设计的图标矢量图生成字体文件。我们在CSS 中像设置自定义字体一样使用就可以。font-face 字体声明：
（2） 定义一下Iconfont 的样式：
（3）我们可以通过字体的大小font-size 和自体颜色color 改变图标的大小和颜色。挑选图标对应的字体编码，应用于页面中：
当然，我们也可以使用平台提供的Unicode 和Symbol 引用方式。
4. 使用TinyPNG 在线处理图片来优化网站图片
4.1 什么是TinyPNG ?
TinyPNG 使用智能有损压缩技术来减少您PNG、JPG 文件大小。通过有选择地减少图像中的颜色数量，需要更少的字节来存储数据。效果几乎看不见，但它在文件大小上有很大的差别！通俗点说就是就是尽可能不影响浏览体验的情况下帮助您压缩图片，降低页面大小，间接提高网站加载速度。
4.2 如何使用?
访问https://tinypng.com/官网上传本地图片，处理完成后点击“download”下载，随便上传了一张图片，压缩率达到70%，有效降低了图片体积。
5. 伪造登录接口等，方便缺陷、BUG 的复现，提高调试效率
基于前端的开发联调和缺陷复现的特点，移动端app 最好全部通过本地起服务联调，不然每次都发版在手机上看很影响开发及维护效率！现有的条件是每个需要登陆的接口都在后端写死客户号，希望可以在前端伪造一个 登陆页面，模拟app 的登陆，这样后面所有的接口都是登陆状态。
（二）公共管理
1. 公共组件管理：所有成员熟悉默认组件库(项目组使用的MintUI)，新需求优先从组件库中选择，默认组件库没有的情况下调研选择成熟的组件，没有找到开源组件的情况下再创建组件，组件维护人员尽量完善注释，如组件使用说明，和调用说明！
⚠ 注：为了方便样式和需求的修改，简单组件尽量使用HTML，CSS 原生开发例如Button, Nav, Input 等复杂组件再使用库或插件例如Swiper, Slide, Popover, MessageBox, Dailog, DatePicker 等
2. 公共CSS：根据实际需要建立公用的CSS 文件，从项目搭建就做好normalize，并做好注释，不要轻易改动，只能局部覆盖
3. 公用JS：公用的JS 或插件一律放在统一的目录plugin/vendor，不可以在页面里随便放置，也不能全局引用。
4. Code Review：建议每周抽出半小时到1 小时进行code review，增强代码质量，开发之间相互了解工作，降低人员切换难度，更能相互学习写出更好的可读性和可维护性代码。
（三）前端代码规范
1. 删掉无用代码。
不要留下大量注释代码，如果注释的代码还有用，请写好注释代码的注释 ，保持代码的简洁性。下图是错误示范：
2. 规范变量命名，命名语义话。
驼峰命名，组件大驼峰，其余小驼峰；禁止使用无意义的变量命名和拼音命名，使用准确的英文，好的命名就是注释，免去无聊的解释代码式的注释，严谨到单数/复数/过去时/进行时/将来时等等；禁止使用缩写，尽量把单词写全，避免让别人去猜：
ct --> content?container?, d-->day?, y ,-->year?yes?,ml-->maxLength?,add-->address?add?
如下图的命名加上默认数据类型，完全可以不写注释就能明白其含义：
3. 注释的种类
● 复述代码——无聊
● 解释代码——改进代码
● 标记——可能用的到
● 概述代码——有用
● 代码意图说明——指出要解决的问题
● 传达代码无法表述的信息——非常重要
4. 空格换行规范
空格不要一会tab 键式，一会n 个space 键式，换行一行/两行/三行/四行随机发生，这样会显得页面杂乱无章，可以使用IDE 的代码格式化之类的，总之要让页面代码看起来井然有序。
5. 掌握JS 真假值的隐形转换模式，不要写冗长无聊的条件判断。
JS 数据类型为假的有false/null/””/undefined/0/NaN，其余都是真值。例如下图两个条件判断是完全等价的：
6. 在JS 里禁止使用==，必须使用===全等，因为不像JAVA/PHP 等是强类型语言，JavaScript 是弱类型语言，它的类型隐形转换机制很容易引起潜在bug，除非你有能力记住下面这张图：
7. 根据经典书籍《代码大全》、《Unix 编程艺术》和工作中实际经验的总结，一个函数体内最好不要超过5 行代码，超过了说明你该优化你的函数，把逻辑抽象(抽离)出另一个函数：
8. 超过两次以上重复就要抽象出函数，提高代码复用性和可维护性。
9. 慢慢学会使用表驱动编程，逐步代替冗长的if else 嵌套地狱。
10. 尽量使用ES6，摒弃var 用let/const 代替, 少用function，学习优雅现代的代码风格。学会使用箭头函数、解构赋值、展开运算符、模板字符串等，跟上时代潮流。
11. 优化代码（重构）
人是有惰性的，写代码的人更是如此，所以每天写完代码必须花半小时重构今天写的代码，否则过了当天第二天不可能再优化，时间长了堆积在一起就是烂代码，除非重写。
（1）使用函数来改代码步骤：
1. 将一坨代码放到一个函数里;
2. 将代码依赖的外部变量作为参数;
3. 将代码的输出作为函数的返回值;
4. 给函数取一个合适的名字;
5. 调用这个函数并传入参数;
6. 这个函数里的代码如果超过5 行，则有优化空间，回到第1 步。
（2） 一些固定的套路
1. 表驱动编程（《代码大全》里说的），所有一一对应的关系都可以用表来做；
2. 自说明代码（以API 参数为例），把别人关心的东西放在显眼的位置。
（3）bad smell（坏味道）
有些代码可以用，但是很「臭」。哪些代码是有坏味道的?
1. 表里不一的代码；2.过时的注释；3.逻辑很简单，但是看起来很复杂的代码；4.重复的代码；5.相似的代码；6.总是一起出现的代码。
（四）人员管理
1. 相应模块开发人员的稳定性；
据科学研究和大量的实践经验证明，保持相应模块开发人员的稳定性是最科学的开发方式；相反，如果一个模块经过多人开发，特别是中途换人，谁都来改一下，那么每增加一个人所花费的开发和维护时间是成平方倍数增加的。
1.1程序规模对构建的影响
● 程序员的交流路径与程序员数量的关系；
● 采用文档交流。
1.2 软件构建中的设计
（1） 设计是一个险恶（wicked）的问题
险恶的问题就是那些只有通过解决或部分解决才能被明确的问题。你必须首先把这个问题「解决」一遍才能明确的定义这个问题。
----无法准确估算工期
（2） 软件的首要技术使命：管理复杂度
如果一个项目因为技术而失败，通常的原因就是技术太复杂导致失控。高代价、低效率的设计源于：
1. 用复杂的方法解决简单的问题；X
2. 用简单但错误的方法解决复杂的问题；X
3. 用不恰当的复杂方法解决复杂的问题；X
1.3 管理构建（leader 的角度）
（1） 鼓励良好的编码实践
● 设定标准（编码规范、文档规范、checklist 等）
● 每个项目/模块两个人（结对、师徒、支援）
● Code Review （很难）
● 提供最佳实践给人参考
● 强调代码是共有财产
（2） 需求变更和设计变更
● 不要马上变更，累积一些再变更
● 成立变更委员会，系统化地控制变更
● 警惕官僚主义
（3） 备份所有东西：源码、工具、需求、变更、设计、文档……
（4） 如果进度落后了怎么办：
● 期待后期赶上——不可能
● 增加人手——火上浇油
● 砍需求——最靠谱
（5） 把程序员当人看
● 程序员不是机器
● 要有舒适的环境、要休息
● 个体差异
● 团队差异
● 信仰问题
（6） 管理/教育你的管理者
2. 评需求的时候，开发人员必须（需求、UI 的充分沟通、评审）到场；
2.1 需求评审阶段
此阶段，相关负责人的开发必须到场，作为底层开发者，特别是前端这个和页面开发，手机兼容，用户交互最近的岗位，他们最清楚细节和后果，考虑得更细更深。不能以没时间为理由而让上级或者他人代替评审，造成的后果就是反复修改，工期延期，这是一定的！
2.2 静态页面开发阶段
此阶段，前端开发人员必须和UI 进行充分的沟通，因为首先页面要素和样式是由CSS 决定的，而不是PSD 相关图层，复杂问题需要简单化；其次，开发人员可能会在现有的项目中想起相似UI，而UI 可能不太了解，造成同一个页面的元素产生完全不同的UI，造成无用功！