第一版规范编辑完成

指南/项目开发原则.md

+# 项目开发原则
+## 一、设计阶段
+* 刨根问底：在拿到需求之后，要对需求方刨根问底，在确实理解整个需求之后才能动手
+* 三思而后行：在着手开发之前，必须要花费时间把整个流程梳理一遍。明确每一步如何实现，以及中间会有什么问题之后，再动手
+* 胸有成竹：在实际动手之前，必须确保自己已经对整个项目了如指掌，然后才能动手
+## 二、编码阶段
+* 一眼能看懂：开发的时候，注意自己代码的易读性问题，随时以第三者的角度审视自己的代码
+* 一句能说清：每个函数的功能应当尽可能明确单一，做到一个函数的功能能用一句话说清楚
+* 不要重复造车轮：开发的时候要尽量避免代码高度耦合，尽力做到功能性的泛用。并且记得询问是否已有类似功能
+## 三、测试和调整阶段
+* 先自审：完成开发以后，应该对自己的代码进行一次自审，通过自审可以避免代码不规范的问题
+* 预防意外：开发者原则之一是“用户永远不会按你期望的方式去使用你的软件”，因此除了走正常操作流程意外，我们还应当考虑和测试一些不正常的操作流程
+* 主动寻找漏洞：在测试的时候，应当尝试作为攻击者主动寻找产品中的漏洞进行攻击
+## 四、发布及后续跟进
+* 三省吾身：在产品发布以后，还应当持续跟进一段时间，主动从项目中总结经验，并思考优化和解决策略
\ No newline at end of file

敏感信息管理办法.md

+# 敏感信息管理办法
+## 敏感信息定义
+本办法所提及的敏感信息主要是指涉及公司商业秘密的数据，包括但不限于以下内容
+* 个人工作QQ的账号和密码
+* 用于连接阿里云服务器的个人账号和密码
+* 用于连接代码仓库的个人账号和密码
+* 用于链接测试站点数据库的账号和密码
+* 用于连接正式站点数据库的账号和密码
+* 各个项目的项目代码
+* 正式和测试站点的数据库内容
+* 用户的个人信息，包括但不限于用户姓名，身份证号，手机号，住址等用户的私人信息
+
+## 刑法相关条款
+第二百一十九条 有下列侵犯商业秘密行为之一，给商业秘密的权利人造成重大损失的，处三年以下有期徒刑或者拘役，并处或者单处罚金；造成特别严重后果的，处三年以上七年以下有期徒刑，并处罚金：<br />
+（一）以盗窃、利诱、胁迫或者其他不正当手段获取权利人的商业秘密的；<br />
+（二）披露、使用或者允许他人使用以前项手段获取的权利人的商业秘密的；<br />
+（三）违反约定或者违反权利人有关保守商业秘密的要求，披露、 使用或者允许他人使用其所掌握的商业秘密的。明知或者应知前款所列行为，获取、使用或者披露他人的商业秘密的，以侵犯商业秘密论。<br />
+本条所称商业秘密，是指不为公众所知悉，能为权利人带来经济利益，具有实用性并经权利人采取保密措施的技术信息和经营信息。<br />
+本条所称权利人，是指商业秘密的所有人和经商业秘密所有人许可的商业秘密使用人。<br />
+
+## 个人账号和密码管理办法
+1. 所有项目成员应妥善保管自己的个人账号和密码
+2. 严禁擅自将自己的个人账号和密码透露给他人，使他人能访问其原本无法访问的敏感信息。确需权限的情况下可以由有权限的人代为操作，或是向上级申请权限
+3. 测试站的数据库和redis的账号密码目前是公用的，因此可以透露给相关项目的研发成员，但是禁止透露给无关人员
+4. 所有阿里云服务器的远程访问，都必须使用自己的私人账号进行
+5. 更换工作电脑前，必须清除原电脑上所有和个人账号密码有关的数据
+
+## 项目代码管理办法
+1. 项目成员将会根据自己负责的内容获得对应代码仓库的访问权限
+2. 严禁将项目代码以任何形式发送给无关人员，包括其他项目组的成员。确实需要的，应向上级申请授权
+3. 不得向无关人员透露项目相关信息和架构等内容。这些内容包括但不限于，某个项目实现的具体功能，项目提供的具体接口，特定业务的具体逻辑等
+4. 更换工作电脑前，必须清除原电脑上的项目代码，远程仓库访问密钥等内容
+
+## 数据库数据管理办法
+### 测试站数据库管理办法
+1. 在不会对项目造成重大影响的前提下，对测试站的数据内容进行修改不需要特别授权，但最好提前通知一下相关人员
+2. 在开发时，可以根据自己的判断在测试站数据库里新建数据表，但是必须让相关负责人知情
+3. 如果需要修改现有数据表的结构，必须提前告知详细修改计划，并获得相关负责人授权
+4. 严禁将测试站的数据结构和数据内容导出并透露给无关人员
+
+### 正式站数据库管理办法
+1. 助理工程师和项目工程师不允许在未经授权的情况下修改正式站数据库的任何数据
+2. 负责管理后台的高级工程师可以根据产品和客服的要求，无需领导授权就对不涉及用户消费的数据进行修改，但是所有涉及用户消费的数据必须要需求方给出纸质的操作需求并有经理级以上的领导签字方可操作
+3. 不允许在不经过测试的情况下直接在正式站数据库新建数据表，在正式站数据库新建数据表前必须经过测试，并提前获取相关负责人授权
+4. 不允许在不经过测试的情况下修改正式站数据库的数据表结构，在正式站数据库修改数据表结构前必须经过测试，并提前获取相关负责人授权
+5. 严禁将正式站的数据结构和数据内容导出并透露给无关人员
+
+# 文档修订记录
+* 2019/9/5：初版
\ No newline at end of file

流程/测试流程.md

+# 运维规范
\ No newline at end of file

绩效考核规则.md

+# 绩效考核规则
+## 绩效计算规则
+* 每月绩效满分是100分，所有人初始分数都是100分，并且每月分数不会大于100分
+* 触发扣分项目时当月绩效会根据具体项目扣除相应分数
+* 达成加分条件的，将会获得对应的加分，当月加分之后绩效超过100的，超出的部分可以保留至次月，每次加分至多保留3个月（例：A某月全勤并且没有被扣分，则当月其总分101分，多出1分；若A次月没有全勤，则多出的1分可以抵消A次月没有全勤被扣的1分）
+## 扣分项目
+### 考勤和工作态度
+* 没有全勤，-1分
+* 事假超过24小时(不含24小时），N=请假天数, -5 + (N-3)*-1分
+* 上班睡觉，-2分/次
+* 因个人工作态度问题，被其它部门投诉的，-2分/次
+
+### 计划和进度
+* 开发超出计划时间，导致无法按时测试的，N=超出计划测试天数，N*-1分
+* 开发超出计划时间，并导致产品无法按时上线的，N=超出计划上线天数，N*-2分
+* 没有按时汇报每日工作大于等于3次的，N=次数，（N-2)*-1分（注：全天请假的情况不需要汇报）
+* 没有在限定时间内提交周计划的，-2分/次（限定时间为每周最后一个工作日和下周第一个工作日上午）
+
+### 工作质量
+* 负责的功能在上线之后出现严重影响用户使用的BUG的，N=修复BUG所用天数，N*-3分/次
+* 负责的功能在上线之后出现BUG，但是没有严重影响用户使用的，N=修复BUG所有天数，N*-1分/次
+* 不遵守Git管理规范，直接提交代码到禁止直接提交的分支的，-1分/次
+* 不遵守tag管理规范，擅自使用tag并提交到远程库的，-1分/次
+
+### 安全性
+* 提交代码前没有删除代码中的敏感信息的，-20分/次
+* 负责的代码存在可利用漏洞并且在修复之前被项目组研发成员以外的成员发现的。若是被公司内部其他部门发现，-2分/次，被公司外部发现，-5分/次
+
+## 加分项目
+* 全勤，+1分
+* 对系统基础架构提出有效的优化方案，被项目负责人认可并实施的。+3~+10分/次
+* 对不由自己负责的业务系统提出有效的优化方案，被项目负责人认可并实施的。+2~+5分/次
+* 对由自己负责的，已经上线运行的系统，在不影响原工作计划的前提下主动进行完全重构级优化，被项目负责人认可并实施的。+1~+3分/次
+* 对由自己负责的，已经上线运行的系统，在不影响原工作计划的前提下主动进行部分重构。被项目负责人认可并实施的。+1分/次
+* 主持完成项目成员能力提升课程的。+3分/次
+
+## 职位专属考核标准
+### 助理工程师
+助理工程师没有额外扣分项，但是助理工程师在试用期间绩效低于90（不含90）时将视为试用不合格。试用不合格时根据情况可选择延长试用一个月
+
+### 工程师
+* 负责的代码因没有达到[项目基本规范](./规范/README.md)的要求被项目负责人要求限期修改，并且没有按时完成的，超过限期天数=N，N*-1分/次（对不符合基本规范的代码进行修改不计入工作量，也不额外安排时间）
+* 已经上线的代码，在需求和系统架构没有变更的前提下，被项目负责人要求重写超过30行的。累计每3次-1分（累计次数跨月计算）
+
+### 高级工程师
+* 负责的代码因没有达到[项目基本规范](./规范/README.md)的要求被项目负责人要求限期修改，并且没有按时完成的，超过限期天数=N，N*-2分/次（对不符合基本规范的代码进行修改不计入工作量，也不额外安排时间）
+* 已经上线的代码，在需求和系统架构没有变更的前提下，被项目负责人要求重写超过30行的。-1分/次
+* 负责的助理工程师没有按时完成工作的，-1分/次
+
+## 规则修订时间
+2019/9/6
+
+## 规则生效时间
+2019/9/9
\ No newline at end of file

规范/README.md

+# 项目基本规范
+
+本规范指定了所有项目通用的基本要求，**所有人必须严格遵守本规范进行开发**。根据项目，开发者除了本规范以外，还需要遵守相应类型的项目规范。<br />
+
+## 1、注释和说明
+1. 所有注释必须和实际代码内容匹配，要严格避免复制文件对代码进行修改之后不修改注释的情况
+2. 每个项目必须在根目录下有readme.md对项目整体进行说明
+3. 当前目录下有超过7个子目录或文件的情况下，必须添加readme.md对各目录和文件进行整体说明，但是有额外文档或者目录下的文件是自动生成的除外
+4. 每个代码文件都要有整个文件的注释，并且尽可能放在文件顶部。在readme.md里面有说明的可以除外
+5. 每个函数都应该有至少一行注释和函数声明放在一起。但是函数总行数小于等于5行的可以除外
+6. 禁止使用注释来代替删除，并将其应用于大块的废弃代码
+
+## 2、编码规范
+1. 必须显式声明变量，而无论使用的语言是否支持隐式变量声明
+2. 单个函数不能超过100行，并应尽量避免超过50行（含空行，不含注释），当单个函数太长的时候，则将其拆分为多个功能不同的子函数
+3. 代码缩进必须对齐，并且统一使用半角空格实现缩进
+4. 代码缩进不允许超过7层，并应尽量避免超过5层（按对齐线的数量计算），当缩进过多时，则将其拆分为子函数或是修改代码结构。但是JSON数据结构的缩进层级不受本要求限制
+5. 在同一个代码文件里面，不允许有2个或2个以上相似度超过75%的函数存在，除非函数本身行数小于等于5行
+6. 单行代码不允许超过300个字符，若超过的，应当在合适的部位加入换行。但是单行内容本身就是一个超长字符串的例外
+7. 单行代码不超过50个字符的单个语句必须写在同一行里面，单行代码不超过100个字符的单个语句应当尽量写在同一行里面，应当尽可能的写在同一行里面。例如：let obj = { key, item }这种代码，就不能写成4行，而应该写在1行里面
+8. 不能连续使用超过5级的子对象，并尽量不大于3级。在层级过高时，使用一个中间变量来让代码更加清晰友好。例如obj.sub1.sub2.sub3.sub4.sub5.sub6，可增加中间变量let subObj = obj.sub1.sub2.sub3，然后再使用subObj.sub4.sub5.sub6
+9. 循环嵌套最多3层，超过3层的必须改用其他方法实现业务逻辑
+
+## 3、命名规范
+1. 变量名的长度不允许超过20个字符，并应尽量控制在10个字符以内；函数名的长度不允许超过40个字符，并应尽量控制在20个字符以内
+2. 函数和变量命名时应当尽可能使用含义准确的英文或英文缩写，实在不方便的也可以使用拼音或者拼音首字母。但是拼音和英文混用时，必须是拼音缩写在前，英文单词在后。例如协议文档，可以命名为xyDoc，但是不允许命名为xieYiDoc
+3. 除了[常用变量名及缩写](./常用变量名及缩写.md)里规定的变量名以外。禁止使用单个字母作为变量名，除非该变量仅出现于声明之后的最多10行代码以内
+4. [常用变量名及缩写](./常用变量名及缩写.md)里规定的变量名不得用于表达其他含义
+5. 除了局部变量和内部函数以外，所有函数和变量的命名应当清晰明确而不能过于宽泛。比如item和data这类命名，可以出现在单个文件内部，或者作为一个父对象的属性名，但不能单独跨文件使用
+6. 每个文件的文件名必须清晰明确，不允许使用过于宽泛的文件名，比如item和page
+7. 变量和函数的命名应当精简，不允许有过多冗余信息。比如父对象是userData，然后里面的函数又命名为getUserData，这种情况就需要把函数名称精简
+8. 目录和代码文件命名应当精简，不允许有过多冗余信息。比如目录本身是users，然后下面的文件名字又叫做usersXXXX，这种情况就应该把文件名精简
+
+## 4、Git库管理规范
+1. 每次提交代码必须附带注释，并且注释必须有清晰的指向性含义。比如不能使用“修正一个BUG”这样的注释，而必须写清楚“修正了XX系统的一个BUG”
+2. 所有人禁止在本地直接修改master分支，master分支仅允许项目维护者在远程库操作合并
+3. 所有人禁止在本地直接修改test分支，test分支必须在远程库操作合并
+4. 项目维护者以外的开发者禁止在本地直接修改develop分支，项目维护者仅在进行少量修改时允许在本地直接修改develop分支并推送。develop分支可以在远程库操作合并
+5. 在给项目追加新功能时，应以master为源分支新建以feature-开头的分支，如feature-xxxSystem。在完成开发后，首先应将其提交到远程库，然后合并到develop分支进行开发者测试，开发者测试通过后再将其合并到test分支进行全面测试。测试没问题之后申请合并到master分支等待发布
+6. 在修复项目线上的bug时，应以master为源分支新建以fix-开头的分支，如fix-ch190903。在完成修改后，将其提交到远程库，然后在远程库合并到develop或者test分支进行测试，测试完成以后申请合并到master分支并通知项目维护者进行合并发布
+7. 项目维护者必须严格按照[项目tag管理规范](./项目tag管理规范.md)来管理tag
+
+## 5、测试规范
+1. 新功能必须先放到develop分支上进行测试，经过完整功能性测试之后确定没有问题才能合并到test分支
+2. 新功能在放上test分支之后，必须经过简单的功能性测试，确认功能可以运行之后才能通知对接人进行测试
+3. bug修复分支直接在test分支上进行测试，测试完没有问题之后再合并到develop分支和master分支
+
+# 扩展内容
+* [常用变量名及缩写](./常用变量名及缩写.md)(2019/9/5)
+* [node.js后端项目规范](./项目规范_node.js后端.md)(待编辑)
+* [vue项目规范](./项目规范_vue项目.md)(待编辑)
+* [小程序项目规范](./项目规范_小程序.md)(待编辑)
+* [安卓原生项目规范](./项目规范_安卓原生.md)(待编辑)
+* [苹果原生项目规范](./项目规范_苹果原生.md)(待编辑)
+* [项目tag管理规范](./项目tag管理规范.md)(待编辑)
+
+# 文档修订记录
+* 2019/9/5：初版
\ No newline at end of file

规范/常用变量名及缩写.md

+# 常用变量名及缩写
+## 约定俗成的极简变量
+
+| 变量名 | 含义 |
+|:-------|:-----|
+| a  | 在纯粹的数学计算函数中用作第一个参数 |
+| b  | 在纯粹的数学计算函数中用作第二个参数 |
+| i  | 通常用于for循环的索引 |
+| j  | 在多层循环中用于第二层for循环 |
+| k  | 在多层循环中用于第三层for循环，或作为key的缩写使用 |
+| n  | 在小型函数和局部变量中临时使用的整型数 |
+| m  | 在小型函数和局部变量中临时使用的整型数，通常与n同时使用 |
+| s  | 在小型函数和局部变量中临时使用的字符串 |
+| t  | 数据库事务Transaction的首字母，表示一个事务实例 |
+| _  | 无 | 在多层循环中用于第三层for循环 |
+
+## 常用变量名缩写
+若有疏漏欢迎补充
+| 缩写 | 原单词 | 别名 | 含义 |
+|:-----|:-----|:-----|:-----|
+| add  | addition | 无 | 加 |
+| addr | address | 无 | 地址 |
+| adm  | admin | 无 | 管理/管理员 | 
+| app  | application | 无 | 应用/科目 |
+| arg  | argment | 无 | 参数 |
+| arr  | array | 无 | 数组 |
+| attr | attribute | 无 | 属性/特性 |
+| auth | authority / authorize | 无 | 权限 |
+| avg  | average | 无 | 平均值 |
+| btn  | button | 无 | 按钮 |
+| buff | buffer | buf | 缓存 |
+| calc | calculate | 无 | 计算 |
+| cfg  | configuration | config | 配置 |
+| char | character | 无 | 字符 |
+| cmd  | command | 无 | 命令 |
+| cmp  | compare | 无 | 比较 |
+| col  | color/column | 无 | 列 |
+| cur  | current | 无 | 当前的 |
+| db   | database | 无 | 数据库 |
+| dec  | decrease / decode | 无 | 减少/解码 |
+| dep  | dependency / dependent / depends | 无 | 依赖 |
+| dev  | develop / device | 无 | 开发版/设备 |
+| dict | dictionary | 无 | 字典 |
+| diff | diffrent / difficult | 无 | 差异/难度 |
+| dir  | directory | 无 | 目录 |
+| div  | division | 无 | 除 |
+| dst  | destination | dest | 目的 | 
+| doc  | document | 无 | 文档 |
+| dup  | duplicate / duplication | 无 | 副本 |
+| env  | environment | 无 | 环境 |
+| enc  | encode | 无 | 编码 |
+| eq   | equal | 无 | 等于 |
+| err  | error | 无 | 错误 |
+| evt  | event | 无 | 事件/活动 |
+| flg  | flag | 无 | 标记 | 
+| func | function | 无 | 函数 |
+| idx  | index  | i  | 索引 |
+| inc  | increment | 无 | 增加 |
+| info | information | 无 | 信息/详情 |
+| init | initial | 无 | 初始化 |
+| img  | image  | 无 | 图片 |
+| it   | iterator | itr,iter | 迭代器 |
+| len  | length | 无 | 长度 |
+| lib  | library | 无 | 库 |
+| lnk  | link | 无 | 链接 |
+| lst  | list | 无 | 列表 |
+| msg  | message | 无 | 消息 |
+| mid  | middle | 无 | 中间的 |
+| mul  | multiplication | 无 | 乘法 |
+| num  | number | n | 整数 |
+| nxt  | next | 无 | 下一个 |
+| obj  | object | 无 | 对象 |
+| op   | operate | 无 | 操作 |
+| opt  | option | 无 | 选项 |
+| pkg  | package | 无 | 包 |
+| pos  | position | 无 | 位置 |
+| pre  | previous | prev | 前一个 |
+| prm  | parameter | param | 参数 |
+| prop | property | 无 | 属性/特性 |
+| pt   | point | 无 | 点 |
+| ptr  | pointer | 无 | 指针 |
+| pwd  | password | 无 | 密码 |
+| prod | production | 无 | 正式版 |
+| ref  | reference | 无 | 引用 |
+| res  | result / resource | 无 | 结果/资源 |
+| ret  | return | 无 | 返回 |
+| sig  | sign | 无 | 标记 |
+| src  | source | 无 | 源 |
+| stat | status | 无 | 状态 |
+| std  | standard | 无 | 标准 |
+| str  | string | s | 字符串 |
+| sys  | system | 无 | 系统 |
+| tbl  | table  | 无 | 表格 |
+| tar  | target | 无 | 目标 |
+| tmp  | temporary | temp | 临时的 |
+| trans | translate | 无 | 转换 |
+| txt  | text   | 无 | 文本 |
+| usr  | user   | 无 | 用户 |
+| util | utilities | 无 | 工具 |
+| val  | value | 无 | 值 |
+
+#修订时间
+2019/9/5
\ No newline at end of file

规范/项目tag管理规范.md

+# 项目tag管理规范
\ No newline at end of file

规范/项目进阶规范.md

+# 项目进阶规范
+本规范指定了一些判断和实施难度较高的规范要求，项目成员应当根据自己的能力尽力达成本规范所要求的内容。在阅读本规范前，应先阅读并牢记[项目基本规范](./README.md)
+
+## 一、注释规范
+规范注释是规范代码的第一步，写不好注释的人，就算技术能力再怎么高，也难以适应团队化开发
+
+### 1、注释的基本使用
+1. 多行注释：多行注释通常用于对整个代码文件进行说明，或是在重要的函数和数据结构前对其进行详细说明。多行注释有规定格式的，应当按照规定格式来编写
+2. 单行注释：单行注释应用于绝大部分场合，包括对函数的进行说明，对接下来的代码进行说明，或者用于做特定的标记等
+3. 代码后注释：指和代码在同一行，并在代码后的单行注释。代码后注释通常用于对变量进行说明，或者对本行内容进行补充性说明
+在项目中，只允许使用以下几种注释格式之一
+4. 代码中注释：指和代码在同一行，并且不在代码后的注释。除了用于占位以外，应尽量避免使用代码中注释
+5. TODO标记：可以应用在任何代码注释中，并且标记在注释的最前方。TODO标记用于占位，提示开发者应当在该位置做的事情。在由于某些原因无法直接完成全部代码，或者为了赶时间暂时提交了临时使用的代码的时候。就可以用TODO标记来占位，一个典型的带有TODO标记的注释：// TODO:这里有漏洞，需要修改
+
+### 2、应当使用注释的地方
+1. [项目基本规范](./README.md)里规定了必须要使用注释的地方
+2. 对全局变量和其他使用范围较大，并且变量名不能做到一目了然的变量，应当使用代码后注释
+3. 函数内部分为多个代码块的时候，对无法一眼看懂的代码块应当添加对应注释
+4. 代码中需要提醒开发者和维护者注意的地方，应当添加注释
+5. 对比较复杂的表达式或者逻辑判断，建议添加注释
+
+### 3、不应该使用注释的地方
+1. 注释内容过多，规模过大的，应当单独建立文档进行说明，而不是作为注释放在代码文件中
+2. 添加了注释之后对于阅读代码没有任何帮助的注释，不建议添加
+3. 连续而琐碎的注释会影响阅读代码时的流畅性，如果连续而琐碎的注释太多，建议整理好之后放在一个语句块的前面
+
+### 4、注意事项
+1. 注释内容应当尽可能的清晰明确，避免使用函数不清的字句
+2. 注释必须和代码保持同步，修改代码之后应当重新确认一下注释，并根据具体情况修改注释
+
+## 二、代码规范
+
+### 1、基本要求
+1. 除非没有更好的替代方案，否则禁止使用全局变量
+2. 对其他文件的引用，以及变量声明。尽可能的统一放在对应代码块和代码文件的头部统一管理
+3. 在同一个项目内应当使用严格统一的语法来编写代码
+
+### 2、代码分块
+1. 在代码中，应该适当的使用空行来对代码进行分块
+2. 在代码块中，代码的功能应当清晰明确，不能把不同的代码逻辑混在一起交替执行
+3. 代码块不宜过长，通常一个代码块应当限制在10个语句之内
+4. 业务复杂并且需要大量调用其他函数的来完成业务的单个函数内，应尽量将对外调用整合起来，以尽可能的避免一行一个代码块的情况出现
+
+### 3、代码通用性
+1. 数据和代码逻辑应当分离，尽可能避免在代码逻辑中使用写死的数据
+2. 适当的使用中间数据，可以极大的提升模块的独立性，并减少对其他模块的依赖
+3. 当进行单个模块开发的时候，尽量避免将依赖关系混入到模块逻辑中
+
+# 文档修订记录
+* 2019/9/5：初版
\ No newline at end of file