左耳听风专栏笔记

技术变现

• 程序员用手艺、技术养活自己，不依靠公司；
• 提高工作效率，去研究那些难的，公司内外的核心技术；
• 注重输出，输出技术、价值观，帮助更多的人，提高影响力。
• 去高速发展的公司，而不是初创业务未稳定或项目维护期的。
• 提升业务代码编写效率，争取时间学习。
• 关注技术的本质，新技术的出现解决了什么问题和不可替代性
• 技术付费点，挣钱和省钱。
• 找到有价值的信息源。（西方美国）
• 朋友圈

技术领导力

• 扎实的基础技术

• 非同一般的学习能力

• 坚持做正确的事

• 不断得高对自己的要求标准；

新技术

能否发展要素

• 有没有一个比较好的社区。

• 有没有一个或多个杀手级应用。

• 学习难度是否低，上手是否快。

• 没有一个不错的提高开发效率的开发框架。

• 是否有一个或多个巨型的技术公司作为后盾。

时间管理大师

投资自己的时间

• 花时间学习基础知识，花时间读文档。系统地学习一门知识

• 花时间在解放自己生产力的事上（可以牺牲现在时间解放为了更多的时间 - 代码规范 设计模式）

• 花时间在让自己成长的事上

• 花时间在建立高效的环境上

规划自己的时间

• 定义好优先级 (to do List)

• 最短作业优先 (先完成快速简单的 更有动力完成接下来的)

• 关注长期利益规划

用好自己的时间

• 形成正反馈。
• 反思和举一反三

应对故障

发生时

• 重启和限流

• 回滚操作

• 降级操作

• 紧急更新。

出现故障时，最重要的不是 debug 故障，而是尽可能地减少故障的影响范围，并尽可能快地修复问题。

Git协同工作流

中心式协同工作流

1. 从服务器上做git pull origin master把代码同步下来。
2. 改完后，git commit到本地仓库中。
3. 然后git push origin master到远程仓库中，这样其他同学就可以得到你的代码了。

• 功能分支协同工作流

1. 首先使用 git checkout -b new-feature 创建 “new-feature”分支。
2. 然后共同开发这个功能的程序员就在这个分支上工作，进行 add、commit 等操作。
3. 然后通过 git push -u origin new-feature 把分支代码 push 到服务器上。
4. 其他程序员可以通过git pull --rebase来拿到最新的这个分支的代码。
5. 最后通过 Pull Request 的方式做完 Code Review 后合并到 Master 分支上。

GitFlow 协同工作流

整个代码库中一共有五种分支。

• Master 分支。也就是主干分支，用作发布环境，上面的每一次提交都是可以发布的。
• Feature 分支。也就是功能分支，用于开发功能，其对应的是开发环境。
• Developer 分支。是开发分支，一旦功能开发完成，就向 Developer 分支合并，合并完成后，删除功能分支。这个分支对应的是集成测试环境。
• Release 分支。当 Developer 分支测试达到可以发布状态时，开出一个 Release 分支来，然后做发布前的准备工作。这个分支对应的是预发环境。之所以需要这个 Release 分支，是我们的开发可以继续向前，不会因为要发布而被 block 住而不能提交。

一旦 Release 分支上的代码达到可以上线的状态，那么需要把 Release 分支向 Master 分支和 Developer 分支同时合并，以保证代码的一致性。然后再把 Release 分支删除掉。

• Hotfix 分支。是用于处理生产线上代码的 Bug-fix，每个线上代码的 Bug-fix 都需要开一个 Hotfix 分支，完成后，向 Developer 分支和 Master 分支上合并。合并完成后，删除 Hotfix 分支。

GitHub Flow

所谓 GitHub Flow，其实也叫 Forking flow，也就是 GitHub 上的那个开发方式。

1. 每个开发人员都把“官方库”的代码 fork 到自己的代码仓库中。
2. 然后，开发人员在自己的代码仓库中做开发，想干啥干啥。
3. 因此，开发人员的代码库中，需要配两个远程仓库，一个是自己的库，一个是官方库（用户的库用于提交代码改动，官方库用于同步代码）。
4. 然后在本地建“功能分支”，在这个分支上做代码开发。
5. 这个功能分支被 push 到开发人员自己的代码仓库中。
6. 然后，向“官方库”发起 pull request，并做 Code Review。
7. 一旦通过，就向官方库进行合并。

GitLab Flow

引入环境分支，如下图所示，其包含了预发布（Pre-Production）和生产（Production）分支。

Master 分支是一个 roadmap 分支，然后，一旦稳定了就建稳定版的分支，如 2.3.stable 分支和 2.4.stable 分支，其中可以 cherry-pick master 分支上的一些改动过去。

这样也就解决了两个问题：

• 环境和代码分支对应的问题；
• 版本和代码分支对应的问题。

我们将软件开发升级并简化到 SOA 服务化以及 DevOps 上来，那么协同工作流就会变得非常简单。所以，协同工作流的本质，并不是怎么玩好代码仓库的分支策略，而是玩好我们的软件架构和软件开发流程。

与其花时间在 Git 协同工作流上，还不如把时间花在调整软件架构和自动化软件生产和运维流程上来，这才是真正简化协同工作流程的根本。

分布式系统架构

冰与火

使用分布式系统原因

• 增大系统容量。(单体应用局限于系统的性能)

• 加强系统可用。（通过分布式架构来冗余系统以消除单点故障）

优缺点

需要注意的问题

异构系统的不标准问题

• 软件和应用不标准。
• 通讯协议不标准。
• 数据格式不标准。
• 开发和运维的过程和方法不标准。

系统架构中的服务依赖性问题

故障发生的概率更大