知识图谱

架构&设计

作用

• 复杂的软件项目特点

  • 技术复杂

    • 1. 需求让技术变复杂

    • 1. 人员会让技术变复杂

    • 1. 技术本身也是复杂的

    • 1. 软件稳定运行是复杂的

  • 需求不确定

架构设计的目标

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

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

架构设计的方法示例

• 微服务

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

• 前后端分离

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

• 分层设计

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

步骤

• 第一步：分析需求

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

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

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

架构设计的道

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

好的架构师

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

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

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

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

管理

项目管理

• 软件项目管理金三角

  • 时间

  • 成本

  • 范围

• 软件项目的可行性研究

  • 经济可行性

  • 技术可行性

  • 社会可行性

  • 更多

    • 政治（Political）

    • 经济（Economic）

    • 社会（Sociological）

    • 科技（Technological）

    • 法律（Legal）

    • 环境（Environmental）

• 风险管理

  • 1. 培养风险意识

  • 1. 管理风险

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

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

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

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

• 复盘

  • 如何做好项目复盘？

    • 1. 回顾项目目标

    • 1. 评估项目结果

    • 1. 分析原因

    • 1. 总结规律，落实行动

• 文档管理

  • 为什么要写文档？

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

    • 便于未来的维护和交接

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

  • 需要文档列表

    • 项目立项

      • 原始需求文档

      • 可行性分析报告

      • 立项说明书

    • 需求相关

      • 原型设计文档

      • 产品设计文档

      • 其他

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

        • 产品需求规格说明书

    • 系统设计

      • 技术方案文档

      • 详细设计文档

    • 开发相关

      • 代码规范文档

    • 测试相关

      • 测试用例

      • 测试验收报告

    • 运维相关

      • 部署文档

      • 故障报告

  • 文档分类

    • 1. 设计类文档

    • 1. 说明类文档

    • 1. 报告类文档

• 工具

  • 基于 Ticket 的任务跟踪系统

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

团队管理

• 人

  • 1. 管理好客户的预期

  • 1. 管理好项目成员

    • 流程和规范

    • 一对一沟通

    • 建立激励机制

• 事

  • 1. 开发模式

  • 1. 项目计划

    • 计划制定

    • 里程碑

    • 跟踪和控制

  • 1. 做好风险管理

• 团队建设方面

  • 招人

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

  • 培养人

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

    • 日常注意代码审查

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

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

  • 管理人

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

  • 开人

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

• 流程建设方面

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

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

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

技术转管理

• 障碍

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

• 关键点

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

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

  • 形成自己的管理风格

会议

• 说明

  • 开会是有价值的

  • 开会是有成本的

• 各类会议

  • 瀑布模型评审会议

    • 典型的

      • 需求评审会议

      • 架构设计评审会议

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

  • 瀑布模型说明会议

    • 需求设计说明会

    • 架构设计说明会

  • 进度报告会议

    • 分类

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

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

    • 目的

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

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

  • 项目计划会

    • 敏捷开发

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

    • 瀑布模型

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

  • 产品演示验收会

  • 项目总结会议

    • Sprint 回顾会议（Sprint Retrospective）

  • 一对一会议

感悟

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

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

安全，防火墙

开发

开发效率

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

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

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

  • 经常停下来想想目标

  • 制定原则

  • 公开自己的计划

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

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

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

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

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

软件工程师的核心竞争力

• 核心竞争力

  • 软素质（做事态度）

    • 1. 自驱动意识

    • 1. 沟通协调，刨根问底

    • 1. 经常自省

    • 1. 敢于担责

    • 5.ownership

  • 方法论（做事方法）

    • 1. 二八原则

    • 1. 时间管理四象限

    • 3.SOP

    • 4.ARCI

    • 1. 敏捷迭代

• 软素质

  • 基本能力

    • 沟通能力

    • 学习能力

    • 英语能力

  • 管理能力

    • 项目管理能力

    • 团队管理能力

  • 综合能力

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

      • 发现问题

      • 分析问题

      • 解决问题

    • 影响力

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

  • 其他能力

    • 创新能力

    • 文档阅读能力

    • 总结归纳能力

测试

分类

• 小

  • 单元测试

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

• 中

  • 集成测试

    • 接口测试

  • 契约测试

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

• 大

  • 系统测试

    • 端到端测试

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

• 其他

  • 性能测试

  • 自动化测试

模型

• 金字塔模型

• 冰淇淋蛋卷模型

• 菱形模型

实践

• 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. 收集需求

  • 1. 分析需求

  • 1. 需求评估

  • 1. 需求设计

  • 1. 验证需求

• 需求变更问题

  • 从源头着手

    • 提升需求确定性

    • 提高需求变更的成本

  • 从解决方案着手

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

规范

• 流程规范

  • 流程规范制定步骤

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

    • 第二步：提出解决方案

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

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

  • 将流程规范工具化

持续交付

如何管理技术债务？

• 识别技术债务

  • 开发速度降低

  • 单元测试代码覆盖率低

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

  • Bug 数量越来越多

• 选择处理技术债务策略

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

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

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

• 实施策略

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

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

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

  • 关键

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

• 预防才是最好的方法

  • 预先投资

  • 不走捷径

  • 及时还债

工具

• 代码静态分析工具

• 测试覆盖率工具

  • java

    • JaCoCo

  • c/c++

    • GCC Coverage

  • javascript

    • JSCoverage

    • Istanbul

• 流量工具

  • tcpdump

  • Wireshark

  • Fiddler