# 知识图谱


## 架构&设计

### 作用

- 复杂的软件项目特点

	- 技术复杂

		- 1. 需求让技术变复杂

		- 2. 人员会让技术变复杂

		- 3. 技术本身也是复杂的

		- 4. 软件稳定运行是复杂的

	- 需求不确定

### 架构设计的目标

- 用最小的人力成本来满足需求的开发和响应需求的变化

- 用最小的运行成本来保障软件的运行

### 架构设计的方法示例

- 微服务

	- 把复杂系统拆分成一系列小的服务，服务再拆成功能模块，让人员更好地分工协作

- 前后端分离

	- 让程序员更专注于某个知识领域，降低开发难度

- 分层设计

	- 隔离业务逻辑，减少需求变更带来的影响

### 步骤

- 第一步：分析需求

- 第二步：选择相似的成熟的架构设计方案

- 第三步：自顶向下层层细化

- 第四步：验证和优化架构设计方案

### 架构设计的道

- 组织人员和技术把系统和团队拆分，并安排好切分后的排列关系，让拆分后的部分能通过约定好的协议相互通信，共同实现最终的结果。

### 好的架构师

- 1. 有架构师思维：具备良好的抽象思维、分治思维、复用思维和迭代思维；

- 2. 懂业务需求：能很好地理解业务需求，能针对业务特点设计好的架构；

- 3. 有丰富的编码经验：像抽象、分治、复用这些能力，都需要大量的编码练习才能掌握；另外保持一定量的编码经验也有助于验证架构设计；

- 4. 良好的沟通能力：架构师需要沟通确认需求，需要让团队理解架构设计。

## 管理

### 项目管理

- 软件项目管理金三角

	- 时间

	- 成本

	- 范围

- 软件项目的可行性研究

	- 经济可行性

	- 技术可行性

	- 社会可行性

	- 更多

		- 政治（Political）

		- 经济（Economic）

		- 社会（Sociological）

		- 科技（Technological）

		- 法律（Legal）

		- 环境（Environmental）

- 风险管理

	- 1. 培养风险意识

	- 2. 管理风险

		- 第一步：风险识别，识别可能的风险

		- 第二步：风险量化，对风险进行评估量化

		- 第三步：应对计划，对风险制定应对策略

		- 第四步：风险监控，对风险进行监控预警

- 复盘

	- 如何做好项目复盘？

		- 1. 回顾项目目标

		- 2. 评估项目结果

		- 3. 分析原因

		- 4. 总结规律，落实行动

- 文档管理

	- 为什么要写文档？

		- 帮助写文档的人理清楚思路

		- 便于未来的维护和交接

		- 便于团队更好的协作沟通

	- 需要文档列表

		- 项目立项

			- 原始需求文档

			- 可行性分析报告

			- 立项说明书

		- 需求相关

			- 原型设计文档

			- 产品设计文档

			- 其他

				- 产品需求分析文档（PRD）

				- 产品需求规格说明书

		- 系统设计

			- 技术方案文档

			- 详细设计文档

		- 开发相关

			- 代码规范文档

		- 测试相关

			- 测试用例

			- 测试验收报告

		- 运维相关

			- 部署文档

			- 故障报告

	- 文档分类

		- 1. 设计类文档

		- 2. 说明类文档

		- 3. 报告类文档

- 工具

	- 基于 Ticket 的任务跟踪系统

	- 基于看板的可视化任务管理

### 团队管理

- 人

	- 1. 管理好客户的预期

	- 2. 管理好项目成员

		- 流程和规范

		- 一对一沟通

		- 建立激励机制

- 事

	- 1. 开发模式

	- 2. 项目计划

		- 计划制定

		- 里程碑

		- 跟踪和控制

	- 3. 做好风险管理

- 团队建设方面

	- 招人

		- 找一些有潜力的培养，也要注意梯队建设，中间有技术骨干补充

	- 培养人

		- 给新人安排师傅的方式培养新人

		- 日常注意代码审查

		- 内部技术分享是个不错的共同提高的方式

		- 技术高手要注意不只是闷头干活，也要承担一定的带人的工作

	- 管理人

		- 核心在于营造好的氛围，鼓励成员自我驱动去做事

	- 开人

		- 不适合团队的人也不要手软，及时的淘汰

- 流程建设方面

	- 选择合适的软件开发模型，建立项目开发流程

	- 构建基于源代码管理工具的开发流程

	- 建立外部提交需求和任务的流程

### 技术转管理

- 障碍

	- 专注技术实现，沉浸于细节中，而忽视了其他事情

- 关键点

	- 管理，最重要的一点就是大局观

	- 团队的成功，才是你的成功

	- 形成自己的管理风格

### 会议

- 说明

	- 开会是有价值的

	- 开会是有成本的

- 各类会议

	- 瀑布模型评审会议

		- 典型的

			- 需求评审会议

			- 架构设计评审会议

		- 主要目的是用来收集意见

	- 瀑布模型说明会议

		- 需求设计说明会

		- 架构设计说明会

	- 进度报告会议

		- 分类

			- 瀑布模型通常是以周为单位的周例会

			- 敏捷开发是以天为单位的每日站会

		- 目的

			- 了解项目的进展，了解当前的困难和瓶颈，及时调整计划，解决问题

			- 每个人都要当众讲一下做过的事情和计划要做的事情，也是一种无形的监督和约束

	- 项目计划会

		- 敏捷开发

			- 每个 Sprint 开始前的 Sprint 计划会（Sprint Planning）

		- 瀑布模型

			- 每个版本开始之前的项目计划会

	- 产品演示验收会

	- 项目总结会议

		- Sprint 回顾会议（Sprint Retrospective）

	- 一对一会议

### 感悟

- 一切管理问题，都应思考能否通过工具或技术解决，如果当前工具或技术无法解决，暂时由流程规范代替，同时不停止寻找工具和技术。

- 梳理好简洁高效的流程规范，能自动化的自动化——技术 Leader的首要任务

## 安全，防火墙

## 开发

### 开发效率

- 积极主动，行动起来改变自己

	- 减少关注圈，扩大影响圈

- 以终为始，想清楚再开工

	- 经常停下来想想目标

	- 制定原则

	- 公开自己的计划

- 要事第一，把时间用在刀刃上

	- 重要紧急的事情马上处理

	- 重要不紧急的要事，要花最多的时间在上面

	- 紧急不重要的事凑一起集中做

	- 不重要不紧急的事情能不做就不做

### 软件工程师的核心竞争力

- 核心竞争力

	- 软素质（做事态度）

		- 1. 自驱动意识

		- 2. 沟通协调，刨根问底

		- 3. 经常自省

		- 4. 敢于担责

		- 5.ownership

	- 方法论（做事方法）

		- 1. 二八原则

		- 2. 时间管理四象限

		- 3.SOP

		- 4.ARCI

		- 5. 敏捷迭代

- 软素质

	- 基本能力

		- 沟通能力

		- 学习能力

		- 英语能力

	- 管理能力

		- 项目管理能力

		- 团队管理能力

	- 综合能力

		- 解决问题能力（软件工程师日常开发工作的核心）

			- 发现问题

			- 分析问题

			- 解决问题

		- 影响力

			- 不是一朝一夕能形成的，但却是一个软件工程师最核心的价值体现

	- 其他能力

		- 创新能力

		- 文档阅读能力

		- 总结归纳能力

## 测试

### 分类

- 小

	- 单元测试

	- 没有外部服务的依赖，都是要模拟的

- 中

	- 集成测试

		- 接口测试

	- 契约测试

	- 所有的测试几乎都不需要依赖其他服务器的资源，如果有涉及其他机器的服务，则本地模拟，这样本机就可以完成测试

- 大

	- 系统测试

		- 端到端测试

	- 几乎不模拟，直接访问相关的外部服务

- 其他

	- 性能测试

	- 自动化测试

### 模型

- 金字塔模型

- 冰淇淋蛋卷模型

- 菱形模型

### 实践

- TDD

- BDD

### 性能测试

- 性能基准测试

- 稳定性测试

- 并发测试

- 容量规划测试

## 工具

### 开发工具

- IDE

- 抓包

- 编辑器

### 设计工具

- 原型设计工具

### 代码静态检测工具

- Sonar

- Coverity

- Infer

### 性能工具

- 后端

	- loadrunner

	- jmeter

	- NeoLoad

- 前端

	- webpagetest

	- Yslow

- 云平台

	- CloudTest

	- Loadstorm

	- 阿里的 PTS

### 渗透测试工具

- Nmap

- Aircrack-ng

- sqlmap

- Wifiphisher

- AppScan

## 敏捷开发

### 敏捷开发

- Scrum

	- Scrum Master

	- 问题停车场

	- Backlog（任务清单）

	- Sprint（迭代）

	- Ticket（Issue，任务）

	- 扑克牌

- 用户故事

- 拥抱变化

- 快速迭代

- 极限编程（eXtreme Programming，XP）

	- 测试驱动开发

	- 持续集成

	- 现场客户

	- 结对编程（英语：Pair programming）

- MVP（minimum viable product，最小化的可行性产品）模式

## 运维

### 运维

- 持续集成

	- 如果一件事很痛苦，那么就更频繁的做（if it hurts, do it more often. ）

### 监控

- 系统监控

- 流量监控

- 数据库监控

### 告警

### 日志

## 思想

### 工程思维

- 大局观

- 模块化思维

- 抽象思维

### 关键的意识

- 质量意识

- 风险意识

- 交付意识

### 金三角理论

- 成本

- 时间

- 质量

### 产品意识

- 商业意识

- 用户意识

- 数据意识

### 架构师思维

- 抽象思维

	- 在软件项目中，遇到类似的场景，就会考虑抽象出来，总结一个规则和方法

- 分治思维

	- 对复杂系统要分而治之，分解成小的、简单的部分。但光分解还是不够的，同时还需要保证分解后的部分能够通过约定好的协议集成在一起。

- 复用思维

	- 一种非常简单有效的提升开发效率的方法，通过对相同内容的抽象，让其能复用于不同的场景。

- 迭代思维

	- 好的架构设计，通常不是一步到位，而是先满足好当前业务需求，然后随着业务的变化而逐步演进

## 软件工程

### 开发模型

- 瀑布模型

	- V 模型

	- 原型设计

	- 增量模型

	- 螺旋模型

	- 迭代模型

- 敏捷开发

### 需求分析

- 步骤

	- 1. 收集需求

	- 2. 分析需求

	- 3. 需求评估

	- 4. 需求设计

	- 5. 验证需求

- 需求变更问题

	- 从源头着手

		- 提升需求确定性

		- 提高需求变更的成本

	- 从解决方案着手

		- 降低响应需求变更的成本

### 规范

- 流程规范

	- 流程规范制定步骤

		- 第一步：明确要解决的问题

		- 第二步：提出解决方案

		- 第三步：达成共识，推广执行

		- 第四步： 持续优化，不断改进

	- 将流程规范工具化

### 持续交付

### 如何管理技术债务？

- 识别技术债务

	- 开发速度降低

	- 单元测试代码覆盖率低

	- 代码规范检查的错误率高

	- Bug 数量越来越多

- 选择处理技术债务策略

	- 重写：推翻重来，一次还清

	- 维持：修修补补，只还利息

	- 重构：新旧交替，分期付款

- 实施策略

	- 对于重写的策略，要当作一个正式的项目来立项，按照项目流程推进；

	- 对于重构的策略，要把整个重构任务拆分成一个个小任务，放到项目计划中，创建成 Ticket，放到任务跟踪系统中跟踪起来；

	- 对于维持的策略，也要把需要做的修补工作作为任务，放到计划中，放到任务跟踪系统中。

	- 关键

		- 实施策略的关键就在于要落实成开发任务，作为项目计划的一部分。

- 预防才是最好的方法

	- 预先投资

	- 不走捷径

	- 及时还债

### 工具

- 代码静态分析工具

- 测试覆盖率工具

	- java

		- JaCoCo

	- c/c++

		- GCC Coverage

	- javascript

		- JSCoverage

		- Istanbul

- 流量工具

	- tcpdump

	- Wireshark

	- Fiddler