前端开发规范文档v3.0.0

一、工作流程

1.1 参与设计

在项目的初始阶段，前端工程师需要与设计师一同进行设计，对设计师的设计稿进行可行性验证，补充完善设计。避免有疑问或考虑不周全的设计进入开发阶段。

1.2 规划施工方案

设计稿完成之后，前端工程师需要就设计稿进行规划：

1. 提取其中的可重用组件
2. 拆分模块
3. 确定实现设计稿所需要的框架和库
4. 规划路由及命名
5. 规划文件目录及命名
6. 制定、分配任务

1.3 接口检测

在后端接口开发完毕后，需要对后端所提供的接口进行检测以保障后续开发的流畅性，提升工作效率，检测分为以下步骤：

1. 接口文档检测，使用碳素云接口文档查看器检查接口的文档是否完整，描述清晰，符合业务逻辑
2. 接口数据测试，使用webstrom或其他请求测试工具进行测试，检查传入参数以及返回参数是否符合业务逻辑，前端开发是是否可用。
3. 检测结果反馈，负责检测的工程师需要就检测结果及时反馈给提供接口的后端工程师，需要清晰描述检测的问题，表现，需求。
4. 复查，就后端重新编写的接口进行重新检测，流程如上，直至通过。

1.4 表现层编码

对UI界面进行编写，调整样式，添加动效，为后面的逻辑层编写添加路标（必要注释），重要的路标可用TODO注释高亮：

<!--todo 这是一个todo注释，这里在IDE中会高亮，并且可以点击todo列表跳转到这里-->

或者在js中：

//todo 这是一个todo注释，这里在IDE中会高亮，并且可以点击todo列表跳转到这里

或者在CSS中：

/*
 * todo 这是一个todo注释，这里在IDE中会高亮，并且可以点击todo列表跳转到这里
 */

在编写表现层之前需要对设计稿进行归纳，与其他开发者一同整理出统一的样式，在编写CSS时尽可能使用已有的类。

在编写需要循环渲染的模版，例如根据数组循环一个列表或一个菜单，需要在模版代码的第一行的上一行添加注释<!--repeat start-->，然后在模版代码最后一行的下面添加注释<!--repeat end--> 示例如下：

    <!--repeat-start -->
    <div ms-repeat="List">
        <a ms-href='"#!/article/"+el.ArticleID' class="a-quit">
            <div class="ctl-s-block" >
                {{el.Title}}
                <!--三角形图标-->
                <div class="ctl-san icon-angle-right icon-large">
                </div>
            </div>
        </a>
    </div>
    <!--repeat-end -->

并且需要在整个模版的上下两端空出一行，方便编写逻辑层时快速查找。

在编写DOM结构时尽可能减少结构嵌套，提升代码运行效率以及可维护性。正确使用语义化的标签，并注意兼容性问题。

在编写过程中有疑问需要及时与设计师沟通，确定施工方案。

表现层的编码可在接口未准备好的情况下进行，但建议在接口准备完毕之后进行。

1.5 逻辑层编码

根据检测通过的接口进行逻辑层的编写。在编写时，不仅要对正常使用的情况进行编写，更需要对异常情况进行判断处理。

在编写过程中有疑问需要及时与后端工程师进行沟通，协商完成需求。

编写完成每一个单元后，需要自行对该单元进行测试，通过后才算完成。

1.6 成品测试

每一个模块完成之后，需要进行成品测试，测试模块的各项功能是否与功能需求、界面设计保持一致，通过测试的产品才能交付并部署到生产环境。

1.7 文档编写

在完成一个可重用的模块后，需要编写详细的使用文档，以方便日后研发工作。

二、协作与交流

2.1 接口交流

在项目的设计阶段，前端工程师需要与后端工程师一同制定程序流程，并设计规范好接口。在开发中如果遇到问题需要及时反馈给后端工程师进行调整。反馈时，需要在任务版上创建对应的任务并且描述清楚现状、需求、问题并指派任务给相应的后端工程师。

2.2 设计稿交流

在项目的设计阶段，前端工程师需要对设计师所提出的设计稿进行建议和补全，与设计师协同完成设计稿。若在开发过程中有需要调整设计的地方，需要及时反馈。反馈时需要在任务版创建对应的任务并且指派给相应的设计师。

2.3 编码协作

与其他的前端工程师进行协同开发时，需要事先分配好各自所负责的模块，不得随意修改他人的代码。

每完成一个单元的编码及测试，需要提交代码并解决冲突，不得在完成大量代码后才进行提交，降低冲突解决的难度。

对于模块之间需要紧密配合的部分，可以实行结对编程协同开发。

2.4 BUG反馈

在任何阶段，任何人发现任何bug可以在任务版对应的项目下面发表bug任务，清晰描述出现bug的步骤，必要的环境，以及bug的影响。

对于反馈给前端的bug，需要每周定时清理，但不能打断干扰当前模块的编写。

2.5 文档交流

工作中必要的文档交流统一使用markdown格式进行书写，整理并保管好的文档文件以.md作为后缀存储，编写工具可以是MDEditor

文档更新的同时，需要更新编写日期以及版本号，版本号的使用v0.0.0的格式进行迭代管理。

三、工具

3.1 浏览器

使用chrome以及firefox作为主要调试工具，部分兼容性问题需要使用IE11以上浏览器进行调试，日常使用就随便你啦

3.2 avalon

若开发项目为BS模式，则需要使用avalon.js作为前端框架，并同时需要使用mmRouter.js mmRequest.js 及其依赖的组件。

是否使用jquery根据不同的项目而定，默认为不使用。

3.3 webstrom

团队前端工程师统一使用webstrom作为IDE进行项目的研发，当然，你也可以使用记事本开发，但是要求代码风格必须与大家保持一致。

3.4 GIT

团队使用GIT作为协同开发工具，以git.oschina.net作为代码仓库。

新成员需要注册git.oschina.net的帐号并且向前端主管申请加入项目组。

具体的git使用见文档：http://www.bootcss.com/p/git-guide/

简单的方式，可以使用webstrom的版本管理工具进行代码的管理。

3.5 less

必要时可以使用less来编写样式表，并且使用webstrom的less自动编译功能进行更加流畅的编写。

四、目录结构规范

前端使用统一的目录结构进行开发，目录结构如下：

index.html为整个前端的入口文件，通过访问index.html打开整个站点，相当于舞台。

config.html为统一的配置文件存放位置，一些全局的变量和全局方法都放在这里，相当于舞台的道具库。

layout.js为布局的VM文件，控制了各个模块的引入，相当于主持人。

router.js为路由表，决定了如何切换页面等路由操作，相当于导演。

body目录中专门用户放置结构层模版，也就是html文件，相当于演员的身体。

soul目录中专门放置不同页面的视图模型，相当于演员的灵魂。

src目录用于存放静态资源，例如css、图片、js、字体等