软件工程之美summary

架构&设计

作用

  • 复杂的软件项目特点

    • 技术复杂

        1. 需求让技术变复杂

        1. 人员会让技术变复杂

        1. 技术本身也是复杂的

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

    • 需求不确定

架构设计的目标

  • 用最小的人力成本来满足需求的开发和响应需求的变化,用最小的运行成本来保障软件的运行

架构设计的方法示例

  • 微服务

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

  • 前后端分离

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

  • 分层设计

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

步骤

  • 第一步:分析需求

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

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

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

架构设计的道

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

好的架构师

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

    1. 懂业务需求:能很好地理解业务需求,能针对业务特点设计好的架构;

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

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

开发

开发语言

数据库

开发工具

  • Git

开发效率

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

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

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

    • 经常停下来想想目标

    • 制定原则

    • 公开自己的计划

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

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

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

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

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

软件工程师的核心竞争力

  • 综合能力

    • 学习能力

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

      • 发现问题

      • 分析问题

      • 解决问题

    • 影响力

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

  • 核心竞争力

    • 软素质(做事态度)

        1. 自驱动意识

        1. 沟通协调,刨根问底

        1. 经常自省

        1. 敢于担责

      • 5.ownership

    • 方法论(做事方法)

        1. 二八原则

        1. 时间管理四象限

      • 3.SOP

      • 4.ARCI

        1. 敏捷迭代

运维

持续集成

  • 如果一件事很痛苦,那么就更频繁的做(if it hurts, do it more often. )

测试

自动化测试分类

    • 单元测试

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

    • 集成测试

      • 接口测试

    • 契约测试

      • 《聊一聊契约测试

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

    • 系统测试

      • 端到端测试

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

管理

项目管理

  • 软件项目管理金三角

    • 时间

    • 成本

    • 范围

  • 软件项目的可行性研究

    • 经济可行性

    • 技术可行性

    • 社会可行性

    • 更多

      • 政治(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的首要任务

思想

工程思维

  • 大局观

  • 模块化思维

  • 抽象思维

关键的意识

  • 质量意识

  • 风险意识

  • 交付意识

金三角理论

  • 成本

  • 时间

  • 质量

产品意识

  • 商业意识

  • 用户意识

  • 数据意识

架构师思维

  • 抽象思维

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

  • 分治思维

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

  • 复用思维

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

  • 迭代思维

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

软件工程

开发模型

  • 瀑布模型

    • V 模型

    • 原型设计

    • 增量模型

    • 螺旋模型

    • 迭代模型

  • 敏捷开发

    • Scrum

    • 极限编程

    • 用户故事

    • 持续集成

    • 拥抱变化

    • 快速迭代

    • 关键定义

      • Scrum Master

      • 问题停车场

      • Backlog(任务清单)

      • Sprint(迭代)

      • Ticket(Issue,任务)

    • 结对编程(英语:Pair programming)

    • 极限编程(eXtreme Programming,XP)

    • MVP(minimum viable product,最小化的可行性产品)模式

    • 扑克牌

需求分析

  • 步骤

      1. 收集需求

      1. 分析需求

      1. 需求评估

      1. 需求设计

      1. 验证需求

  • 需求变更问题

    • 从源头着手

      • 提升需求确定性

      • 提高需求变更的成本

    • 从解决方案着手

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

规范

  • 流程规范

    • 流程规范制定步骤

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

      • 第二步:提出解决方案

      • 第三步:达成共识,推广执行

      • 第四步: 持续优化,不断改进

    • 将流程规范工具化

持续交付

如何管理技术债务?

  • 识别技术债务

    • 开发速度降低

    • 单元测试代码覆盖率低

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

    • Bug 数量越来越多

  • 选择处理技术债务策略

    • 重写:推翻重来,一次还清

    • 维持:修修补补,只还利息

    • 重构:新旧交替,分期付款

  • 实施策略

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

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

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

    • 关键

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

  • 预防才是最好的方法

    • 预先投资

    • 不走捷径

    • 及时还债