软件工程之美summary¶
架构&设计¶
作用¶
复杂的软件项目特点
技术复杂
需求让技术变复杂
人员会让技术变复杂
技术本身也是复杂的
软件稳定运行是复杂的
需求不确定
架构设计的目标¶
用最小的人力成本来满足需求的开发和响应需求的变化，用最小的运行成本来保障软件的运行
架构设计的方法示例¶
微服务
把复杂系统拆分成一系列小的服务，服务再拆成功能模块，让人员更好地分工协作
前后端分离
让程序员更专注于某个知识领域，降低开发难度
分层设计
隔离业务逻辑，减少需求变更带来的影响
步骤¶
第一步：分析需求
第二步：选择相似的成熟的架构设计方案
第三步：自顶向下层层细化
第四步：验证和优化架构设计方案
架构设计的道¶
组织人员和技术把系统和团队拆分，并安排好切分后的排列关系，让拆分后的部分能通过约定好的协议相互通信，共同实现最终的结果。
好的架构师¶
有架构师思维：具备良好的抽象思维、分治思维、复用思维和迭代思维；
懂业务需求：能很好地理解业务需求，能针对业务特点设计好的架构；
有丰富的编码经验：像抽象、分治、复用这些能力，都需要大量的编码练习才能掌握；另外保持一定量的编码经验也有助于验证架构设计；
良好的沟通能力：架构师需要沟通确认需求，需要让团队理解架构设计。
开发¶
开发语言¶
数据库¶
开发工具¶
Git
开发效率¶
积极主动，行动起来改变自己
减少关注圈，扩大影响圈
以终为始，想清楚再开工
经常停下来想想目标
制定原则
公开自己的计划
要事第一，把时间用在刀刃上
重要紧急的事情马上处理
重要不紧急的要事，要花最多的时间在上面
紧急不重要的事凑一起集中做
不重要不紧急的事情能不做就不做
软件工程师的核心竞争力¶
综合能力
学习能力
解决问题能力（软件工程师日常开发工作的核心）
发现问题
分析问题
解决问题
影响力
不是一朝一夕能形成的，但却是一个软件工程师最核心的价值体现
核心竞争力
软素质（做事态度）
自驱动意识
沟通协调，刨根问底
经常自省
敢于担责
5.ownership
方法论（做事方法）
二八原则
时间管理四象限
3.SOP
4.ARCI
敏捷迭代
运维¶
持续集成¶
如果一件事很痛苦，那么就更频繁的做（if it hurts, do it more often. ）
测试¶
自动化测试分类¶
小
单元测试
没有外部服务的依赖，都是要模拟的
中
集成测试
接口测试
契约测试
《聊一聊契约测试
》
所有的测试几乎都不需要依赖其他服务器的资源，如果有涉及其他机器的服务，则本地模拟，这样本机就可以完成测试
大
系统测试
端到端测试
几乎不模拟，直接访问相关的外部服务
管理¶
项目管理¶
软件项目管理金三角
时间
成本
范围
软件项目的可行性研究
经济可行性
技术可行性
社会可行性
更多
政治（Political）
经济（Economic）
社会（Sociological）
科技（Technological）
法律（Legal）
环境（Environmental）
风险管理
培养风险意识
管理风险
第一步：风险识别，识别可能的风险
第二步：风险量化，对风险进行评估量化
第三步：应对计划，对风险制定应对策略
第四步：风险监控，对风险进行监控预警
复盘
如何做好项目复盘？
回顾项目目标
评估项目结果
分析原因
总结规律，落实行动
文档管理
为什么要写文档？
帮助写文档的人理清楚思路
便于未来的维护和交接
便于团队更好的协作沟通
需要文档列表
项目立项
原始需求文档
可行性分析报告
立项说明书
需求相关
原型设计文档
产品设计文档
其他
产品需求分析文档（PRD）
产品需求规格说明书
系统设计
技术方案文档
详细设计文档
开发相关
代码规范文档
测试相关
测试用例
测试验收报告
运维相关
部署文档
故障报告
文档分类
设计类文档
说明类文档
报告类文档
工具
基于 Ticket 的任务跟踪系统
基于看板的可视化任务管理
团队管理¶
人
管理好客户的预期
管理好项目成员
流程和规范
一对一沟通
建立激励机制
事
开发模式
项目计划
计划制定
里程碑
跟踪和控制
做好风险管理
团队建设方面
招人
找一些有潜力的培养，也要注意梯队建设，中间有技术骨干补充
培养人
给新人安排师傅的方式培养新人
日常注意代码审查
内部技术分享是个不错的共同提高的方式
技术高手要注意不只是闷头干活，也要承担一定的带人的工作
管理人
核心在于营造好的氛围，鼓励成员自我驱动去做事
开人
不适合团队的人也不要手软，及时的淘汰
流程建设方面
选择合适的软件开发模型，建立项目开发流程
构建基于源代码管理工具的开发流程
建立外部提交需求和任务的流程
技术转管理¶
障碍
专注技术实现，沉浸于细节中，而忽视了其他事情
关键点
管理，最重要的一点就是大局观
团队的成功，才是你的成功
形成自己的管理风格
会议¶
说明
开会是有价值的
开会是有成本的
各类会议
瀑布模型评审会议
典型的
需求评审会议
架构设计评审会议
主要目的是用来收集意见
瀑布模型说明会议
需求设计说明会
架构设计说明会
进度报告会议
分类
瀑布模型通常是以周为单位的周例会
敏捷开发是以天为单位的每日站会
目的
了解项目的进展，了解当前的困难和瓶颈，及时调整计划，解决问题
每个人都要当众讲一下做过的事情和计划要做的事情，也是一种无形的监督和约束
项目计划会
敏捷开发
每个 Sprint 开始前的 Sprint 计划会（Sprint Planning）
瀑布模型
每个版本开始之前的项目计划会
产品演示验收会
项目总结会议
Sprint 回顾会议（Sprint Retrospective）
一对一会议
感悟¶
一切管理问题，都应思考能否通过工具或技术解决，如果当前工具或技术无法解决，暂时由流程规范代替，同时不停止寻找工具和技术。
梳理好简洁高效的流程规范，能自动化的自动化——技术 Leader的首要任务
思想¶
工程思维¶
大局观
模块化思维
抽象思维
关键的意识¶
质量意识
风险意识
交付意识
金三角理论¶
成本
时间
质量
产品意识¶
商业意识
用户意识
数据意识
架构师思维¶
抽象思维
在软件项目中，遇到类似的场景，就会考虑抽象出来，总结一个规则和方法
分治思维
对复杂系统要分而治之，分解成小的、简单的部分。但光分解还是不够的，同时还需要保证分解后的部分能够通过约定好的协议集成在一起。
复用思维
一种非常简单有效的提升开发效率的方法，通过对相同内容的抽象，让其能复用于不同的场景。
迭代思维
好的架构设计，通常不是一步到位，而是先满足好当前业务需求，然后随着业务的变化而逐步演进
软件工程¶
开发模型¶
瀑布模型
V 模型
原型设计
增量模型
螺旋模型
迭代模型
敏捷开发
Scrum
极限编程
用户故事
持续集成
拥抱变化
快速迭代
关键定义
Scrum Master
问题停车场
Backlog（任务清单）
Sprint（迭代）
Ticket（Issue，任务）
结对编程（英语：Pair programming）
极限编程（eXtreme Programming，XP）
MVP（minimum viable product，最小化的可行性产品）模式
扑克牌
需求分析¶
步骤
收集需求
分析需求
需求评估
需求设计
验证需求
需求变更问题
从源头着手
提升需求确定性
提高需求变更的成本
从解决方案着手
降低响应需求变更的成本
规范¶
流程规范
流程规范制定步骤
第一步：明确要解决的问题
第二步：提出解决方案
第三步：达成共识，推广执行
第四步： 持续优化，不断改进
将流程规范工具化
持续交付¶
如何管理技术债务？¶
识别技术债务
开发速度降低
单元测试代码覆盖率低
代码规范检查的错误率高
Bug 数量越来越多
选择处理技术债务策略
重写：推翻重来，一次还清
维持：修修补补，只还利息
重构：新旧交替，分期付款
实施策略
对于重写的策略，要当作一个正式的项目来立项，按照项目流程推进；
对于重构的策略，要把整个重构任务拆分成一个个小任务，放到项目计划中，创建成 Ticket，放到任务跟踪系统中跟踪起来；
对于维持的策略，也要把需要做的修补工作作为任务，放到计划中，放到任务跟踪系统中。
关键
实施策略的关键就在于要落实成开发任务，作为项目计划的一部分。
预防才是最好的方法
预先投资
不走捷径
及时还债