第一版规范完成

README.md

@@ -145,8 +145,131 @@ function zip(raw) {
     return json; //返回JSON（这种注释显然也没有意义）
   }
 ```
-3. 过于琐碎的注释。注释不能没有，也不宜太多，每隔个一两行就添加一个注释是完全不必要的。
+3. 过于琐碎的注释。注释不能没有，也不宜太多，连续琐碎的功能性注释不如整合到一起放到代码块之前。
 
 ## 代码规范
 
+### 1、严格模式
+除由其他脚本生成的脚本，配置脚本和项目中固定的，不会频繁修改的文件以外，所有js脚本都**必须**使用严格模式编写。
+不要轻易使用公共变量。
+
+### 2、代码的整合和分块
+1. 在代码中，应该适当的使用空行来对代码进行整合或者分块
+2. 对其他脚本的引用，应该一并放到文件头部统一声明
+3. 在多个函数内，或者在同一个函数内多处逻辑块内使用的变量，应该整合起来放在文件头部或者函数头部
+3. 在每一块连续的代码中，代码功能应当单一明确，不宜把不同的代码逻辑混在一起交替编写。具体来说，就是如果一段代码是负责完成某个功能的，那这段代码中就不应该出现任何和该功能无关的代码
+
+```js
+// 这是一个比较好的代码整合分块例子
+'use strict'
+
+const _ = require ('lodash')
+const fs = require('fs')
+const crypto = require('crypto')
+
+let var1 = '' //某个在脚本中反复使用的变量
+let var2 = '' //另一个在脚本中反复使用的变量
+
+//完成某个功能的函数
+function funcA(){
+  let local1 = 0; //一个在函数中多处用到的变量
+  let local2 = 1; //另一个在函数中多处用到的变量
+
+  //实现一个功能的代码
+  let tmp = local1; //改变量只在这个子逻辑中使用，因此不宜放到函数顶部
+  local1 = local2;
+  local2 = tmp;
+
+  //实现另一个功能的代码
+  let result = []; //该变量只用在这个子逻辑中，并且在逻辑完成后立即返回，因此可以选择放在逻辑块头部或者函数头部。若其在子逻辑完成后仍可能被使用，则应放在函数头部
+  result.push(local1);
+  result.push(local2);
+
+  return result;
+}
+
+//其他函数省略
+```
+```js
+// 这是一个不好的代码整合分块例子
+'use strict'
+
+const _ = require ('lodash')
+let var1 = '' //某个在脚本中反复使用的变量
+const fs = require('fs')
+const crypto = require('crypto')
+//完成某个功能的函数
+function funcA(){
+  let local1 = 0;
+  let local2 = 1;
+  let tmp = local1;
+  
+  local1 = local2;
+  let result = [];
+  result.push(local1);
+  local2 = tmp;
+  result.push(local2);
+  return result;
+}
+
+let var2 = '' //另一个在脚本中反复使用的变量
+//其他函数省略
+```
+### 3、变量的命名规范
+* 除了一些约定俗成的变量，和在极小范围（10行以内）内使用的局部变量以外，尽可能避免使用没有意义的变量名。*（约定俗称的变量如循环中的“i”，“j”，“k”。lodash用的“_”等）*
+* 如果实在想不出合适的变量名而必须用拼音或其他无法直接理解的字符串来代替的，要在变量声明时加上注释
+* 对于一些可能有歧义的变量名，最好加上注释。*（例如key这个变量，在某些脚本中就有可能是“关键字”或“键值”，具体根据代码逻辑是否可能产生歧义来决定是否加注释）*
+* 变量名不宜过长，尽可能控制在10个字符串以内为佳。过长的变量名可以在进行精简之后添加注释来进行说明。*（虽然bannedWordList的意思比banList要准确得多，但是变量名太长会影响代码阅读效率）*
+* 尽管由于历史原因，很多脚本的变量名命名规范没有得到完全统一。但是至少不要在同一个脚本中使用不同的变量命名规范。
+### 4、代码长度和流程控制规范
+* 单个脚本尽可能避免超过500行（含空行，不含注释），当单个脚本太长的时候，就需要考虑脚本是否可以根据子功能拆成多个子脚本
+* 单个函数尽可能避免超过50行（含空行，不含注释），当单个函数太长的时候，就需要考虑是否可以把函数内部的子逻辑拆成独立的函数进行调用
+* 代码尽量避免超过5级的缩进，但是JSON和数组之类的数据结构内分级不包括在内
+* 尽量避免使用3层以上的嵌套循环，若循环太深，建议把内部循环做成独立函数
+* 单行代码（含注释）尽可能不要超过100个字符长度（约2/3屏幕），若单行代码过长，建议拆成多行
+
+### 5、其他开发要求
+* **缩进必须规范**
+* 代码中要适当的使用空格
+* 函数功能尽可能单一明确，具体来说就是一个函数的功能最好一句话就能描述清楚
+* 复合功能函数应该以调用其他函数为主，尽量避免在其内部有长串可以分割为单一功能的逻辑代码块
+* 避免过高的耦合度，在进行脚本和函数开发的时候尽可能考虑到其他使用者
+* 数据配置和实现逻辑应当分离，尽可能避免在实现逻辑中使用写死的数据
+* 对于作废的大段代码，要直接删除，不要使用注释的方式来将其保留起来
+
 ## 版本管理规范
+除了部分老旧项目以外，目前的新项目已经全部统一使用git进行版本管理。使用git时要遵循以下要求
+
+### 1、在处理新需求之前，记得先拉取远程库的最新代码
+在每次开发之前拉取最新代码，可以尽可能的避免代码冲突。同时也可能会从别人的开发成果中获得一些现成的工具或者功能，以避免重复造车轮。
+### 2、仍在开发中的代码，可以本地提交，但是不要推送到远程库
+由于要尽可能的确保任意时候的远程库都能直接在线上运行，因此没有开发完整的功能要尽可能的避免推送到远程库。以降低线上故障的发生率。
+### 3、每次提交，必须要对本次的提交内容做出有意义的描述
+每一次提交，都必须要明确的说明这次提交了哪些修改，影响了什么功能。以下的提交说明是不可接受的
+* aaa *（如果确实什么都没有完成，可以这样写“XXX功能开发到途中，临时提交变更”）*
+* 提交 *（可以改成“提交了关于XXX功能的修改”）*
+* 改了几个bug *（可以改成“修改了XXX无法显示的bug和XXX数据错误的bug”，至少也是“修改了关于XX系统的三个bug”）*
+* 增加了一些功能 *（可以改成“增加了XX功能”或者是“增加了XX相关内容”）*
+### 4、提交不应太过频繁
+无论是本地提交还是远程推送，都不宜太过频繁。每个开发人员都应当在开发过程中明确自己工作的里程碑，然后在到达里程碑的时候再进行提交。如果过于以来提交和恢复功能，会影响到自身开发能力的提升。
+**但是ctrl+s需要经常按**
+### 3、在推送代码到远程库之前，必须要确保所有冲突已经解决，并且项目能够正确的运行，方可推送
+始终要记住**远程库的代码就是线上要运行的代码**，因此，在确保冲突解决并且项目能正确运行之前，绝对不能把代码推送到远程库。
+**由于代码推送时没有处理代码冲突导致线上服务无法启动或者出现bug，直接扣绩效**
+
+## 发布规范
+### 1、测试站的发布流程
+在测试库进行测试的时候，不需要使用git进行提交。在没有代码冲突的前提下，完全可以直接使用FTP软件直接把修改过的文件直接托上去覆盖原本的文件进行测试。
+为了避免git版本过于零碎，并不建议每次调试修改都提交一个版本然后用git拉去最新的到服务器上。
+
+### 2、正式站的发布流程
+正式站除了配置文件以外，不允许任何从本地拖取文件对服务器代码进行替换的行为。
+正式站按以下步骤进行发布：
+1. 发布数据库的修改
+2. 对远程服务器的配置进行修改
+3. 确保所有必要的修改已经推送到远程库
+4. 登陆服务器，使用git确认当前运行中的代码版本并记录
+5. 使用git从远程库拖取最新代码
+6. 对最新版服务器进行启动测试
+7. 确保启动测试没有异常之后，逐个重启服务
+8. 若线上服务有严重问题，立即使用git恢复到第4步记录的版本并重启
\ No newline at end of file