Merge branch 'master' of https://github.com/cntehang/dev-docs

danranVm · danranVm · commit 55dfcf7cd2a8 · 2019-02-28T20:38:27.000+08:00
diff --git a/backend/数据库事务与隔离级别.md b/backend/数据库事务与隔离级别.md
@@ -0,0 +1,85 @@
+# 数据库事务与隔离级别
+
+## 事务ACID特性
+
+### 原子性（Atomicity）
+
+原子性是指事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生。
+
+### 一致性（Consistency）
+
+一致性是指在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。这是说数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。
+
+如A给B转账，不论转账的事务操作是否成功，其两者的存款总额不变。
+
+### 隔离性（Isolation）
+
+多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。
+
+在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。
+
+事务最复杂问题都是由事务隔离性引起的。完全的隔离性是不现实的，完全的隔离性要求数据库同一时间只执行一条事务，这样会严重影响性能。
+
+关于隔离性中的事务隔离等级，下面会说明。
+
+### 持久性（Durability）
+
+持久性，意味着在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
+
+## 读现象
+
+事务不隔离会带来的问题：
+
+* 更新丢失(Lost updates): 针对并发写数据
+
+    两事务同时更新，A失败回滚覆盖B事务的更新，或事务A执行更新操作，在事务A结束前事务B也更新，则事务A的更新结果被事务B的覆盖。
+
+* 脏读(Dirty reads): 针对未提交数据
+
+    事务A对数据进行了更新，但还没有提交，事务B可以读取到事务A没有提交的更新结果，这样造成的问题就是，如果事务A回滚，那么，事务B在此之前所读取的数据就是一笔脏数据。
+
+* 不可重复读(Non-repeatable reads): 针对其他提交前后，读取数据本身的对比
+
+    不可重复读取是指同一个事务在整个事务过程中对同一笔数据进行读取，每次读取结果都不同。如果事务A在事务B的更新操作之前读取一次数据，在事务B的更新操作之后再读取同一笔数据一次，两次结果是不同的。
+
+* 幻读(Phantom reads): 针对其他提交前后，读取数据条数的对比
+
+    幻读是指同样一笔查询在整个事务过程中多次执行后，查询所得的结果集是不一样的。幻读针对的是多笔记录。
+
+### 不可重复读与幻读的区别
+
+不可重复读的重点是修改，指的是同样条件读取过的数据，再次读取出来发现值不一样。
+幻读的重点是数据条数的变化（新增或删除），指的是同样的条件，两次读出来的记录数不一样
+
+## 事务隔离级别
+
+数据库事务有四种隔离级别，由低到高分别为：
+
+* 读未提交（Read uncommitted，RU）
+
+   最低的隔离级别，指的是一个事务可以读其他事务未提交的数据。
+
+* 读提交（Read committed，RC）
+
+    一个事务要等另一个事务提交后才能读取数据。
+
+* 可重复读（Repeatable Read，RR）
+
+    在开始读取数据（事务开启）时，不再允许修改操作。
+
+* 串行化（Serializable，S）
+
+    最高的事务隔离级别，事务串行化顺序执行。
+
+### 隔离级别与读现象
+
+|              | 更新丢失 | 脏读 | 不可重复读 | 幻读 |
+|--------------|----------|------|------------|------|
+| 读未提交(RU) | 避免     |      |            |      |
+| 读提交(RC)   | 避免     | 避免 |            |      |
+| 可重复读(RR) | 避免     | 避免 | 避免       |      |
+| 串行化(S)    | 避免     | 避免 | 避免       | 避免 |
+
+#### 参考文档
+
+* [Isolation (database systems)](https://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Read_phenomena)
diff --git a/dev-process/how-to/how-to-publish.md b/dev-process/how-to/how-to-publish.md
@@ -1,52 +1,64 @@
 # 如何发布我们的软件
-目前在我们的系统中，我们的软件产品总共有3中类型：App，Web，后台服务，三种类型各不相同，发布的方式和流程也会有一定的区别，每种类型，按照具体的流程去发布。 
+
+目前在我们的系统中，我们的软件产品总共有 3 中类型：App，Web，后台服务，三种类型各不相同，发布的方式和流程也会有一定的区别，每种类型，按照具体的流程去发布。
 
 有几个都需要注意的点：
-- 所有发布，必须由测试人员完成测试，产品完成验收方可发布
+
+- 所有发布，必须由测试人员完成测试，产品完成验收方可发布。所有验收，只在预发布环境验收，预发布环境需在逻辑上保持和线上环境一致。
 - 所有发布，必须提供回滚的操作流程
-- 所有发布，在发布后的短时间内，需盯紧系统的Dashboard, 如有异常及时排查、回滚
+- 所有发布，在发布后的短时间内，需盯紧系统的 Dashboard, 如有异常及时排查、回滚
 - 所有发布，需知会刘权；重大更改，需知会陈良均、刘颖，并提供简介
 - 如果涉及到了客户、市场、财务、一线的操作，需提前知会他们并提供相关文档，如果有问题，可延迟发布
+- 所有发布，必须只发布当前版本需要的服务，不需要的服务不发布。且发布的服务，必须经过测试、验收
+
+## App 的发布
 
-# App的发布
-App的发布有以下一些特点:
-- 发布渠道多样：Android只能通过各种安卓渠道进行发布，iOS则只能通过官方渠道进行发布
-- 渠道要求不通：不通的发布渠道，对App的要求、发布素材的要求，以及相关文件的要求各不相同
+App 的发布有以下一些特点:
+
+- 发布渠道多样：Android 只能通过各种安卓渠道进行发布，iOS 则只能通过官方渠道进行发布
+- 渠道要求不通：不通的发布渠道，对 App 的要求、发布素材的要求，以及相关文件的要求各不相同
 - 不可逆：版本一旦发布出去，旧版本就被替换掉了，不能够同时存在多个版本，也不能够回退到某个版本。
 - 响应慢：如果版本发布出去，发现问题很多，那么只能够通过再次发布新版本来解决，而这整个的发布、审核的过程比较慢
 - 客户直接体验
 
-基于以上特点，约定App的发布流程如下：
+基于以上特点，约定 App 的发布流程如下：
+
 1. 测试必须完成测试，产品必须完成验收
 2. 产品准备发布文档、素材、以及版本介绍（尤其是比较重要的新功能）
 3. 重大改动时：写钉钉审批，发送刘权、陈良均，抄送刘颖。钉钉内容需包含：版本号，主要改动，测试方法和结果，发布渠道，预定发布日期，测试体验帐号，安装测试说明文档。
 4. 如果涉及到了市场部、财务、一线等部门的业务改动，需提前告知，并提供操作文档（如果需要），并组织会议进行培训（如果需要），需要让他们明确知道我们发行的版本对其工作造成的影响。由他们再跟进具体的客户进行培训。
 5. 审批通过、相关人员知会完成，可提交到渠道审核
 6. 渠道审核完毕（通过、不通过），需提供审核结果到研发群，研发部的同时，尽量自测一下
-7. App上线后，观察2天，及时手机客户反馈、一线问题反馈等，如果有重大bug，及时用旧版本提交回退
+7. App 上线后，观察 2 天，及时手机客户反馈、一线问题反馈等，如果有重大 bug，及时用旧版本提交回退
+
+## Web 网站的发布
+
+Web 网站的所有更改控制权都在自己手上，所以发布的时候可控度比较高，但其和 App 有个共同点，就是客户会直接体验到更改的内容。总体说 Web 的特点如下：
 
-# Web网站的发布
-Web网站的所有更改控制权都在自己手上，所以发布的时候可控度比较高，但其和App有个共同点，就是客户会直接体验到更改的内容。总体说Web的特点如下：
 - 发布渠道唯一，且可控
 - 用户直接体验、如果是后台系统的前端发布，那么则会直接影响到一线操作人员的使用
 
-基于以上特点，约定Web端的发布流程如下：
+基于以上特点，约定 Web 端的发布流程如下：
+
 1. 测试必须完成测试，产品必须完成验收
-2. 如果是涉及到比较大的改动（新功能、严重bugfix、功能改动），需要提供版本介绍
+2. 如果是涉及到比较大的改动（新功能、严重 bugfix、功能改动），需要提供版本介绍
 3. 重大改动时：写钉钉审批，发送刘权、陈良均，抄送刘颖。钉钉内容需包含：版本号，主要改动，测试方法和结果，预定发布日期，测试体验帐号
 4. 如果涉及到了市场部、财务、一线等部门的业务改动，需提前告知，并提供操作文档（如果需要），并组织会议进行培训（如果需要），需要让他们明确知道我们发行的版本对其工作造成的影响。由他们再跟进具体的客户进行培训
 5. 审批通过、相关人员知会完成，可通过灰度发布的方式进行发布
 6. 逐步发布完之后，产品经理需实时跟进项目报表和问题反馈，如有异常，及时回滚
 
-# 后台服务的发布
+## 后台服务的发布
+
 后台服务的特点：
+
 - 可控性高：所有控制权全部在开发者手上
 - 影响大：影响所有渠道的客户
 - 无界面：用户几乎不会直接体验到后台的改动
 
 基于以上特点，约定服务的发布流程如下：
+
 1. 测试必须完成测试，产品必须完成验收
-2. 开发人员完成`update.md`的编写，格式与内容参照ops文档
-3. 如果需要进行数据库、数据格式等的改动，开发人员需提供改动的SQL，并在测试环境中测试
+2. 开发人员完成`update.md`的编写，格式与内容参照 ops 文档
+3. 如果需要进行数据库、数据格式等的改动，开发人员需提供改动的 SQL，并在测试环境中测试
 4. 如果涉及到了市场部、财务、一线等部门的业务改动，需提前告知，并提供操作文档（如果需要），并组织会议进行培训（如果需要），需要让他们明确知道我们发行的版本对其工作造成的影响。由他们再跟进具体的客户进行培训
-5. 灰度发布，逐步完成系统的发布，发布过程中以及发布后，需及时更近系统报表，如有异常，及时回滚
+5. 灰度发布，逐步完成系统的发布，发布过程中以及发布后，需及时更近系统报表，如有异常，及时回滚
diff --git a/frontend/angular-best-practices.md b/frontend/angular-best-practices.md
@@ -247,3 +247,16 @@ this.service
     }
     // #endregion
   ```
+
+## Templates 风格指南
+
+- **Template**保持足够简单，尽量避免计算以及表达式，如若需要，可将其移到**Component**里面使用计算属性表示：
+  ```ts
+  export class DemoComponent {
+    /// 此处略去其他代码
+    
+    get isVisible() {
+      return this.list.length > 0 && balabala……
+    }
+  }
+  ```
diff --git a/frontend/ide-setup.md b/frontend/ide-setup.md
@@ -29,6 +29,9 @@ The following are some commons user settings for VS Code IDE.
 "html.format.wrapLineLength": 60,
 ```
 
+### Core Extensions
+- [Angular language service](https://marketplace.visualstudio.com/items?itemName=Angular.ng-template): Provide a rich editing experience for Angular templates.
+
 ### 常用的 Extensions
 
 - [Angular 6 Snippets](https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular2): TypeScript and HTML 的 snippets.
