软件工程之美

璨sou
379 阅读11分钟

学习攻略

推荐书籍

《构建之法》

《人月神话》

《人件》

《知行合一：实现价值驱动的敏捷和精益开发》

《软件工程-实践者的研究方法》

《持续交付》

《走出软件作坊》

《项目管理修炼之道》

《项目管理-计划、进度和控制的系统方法》

《软件项目成功之道》

《做项目，就得这么干》

《用户故事与敏捷方法》

《敏捷武士：看敏捷高手交付卓越软件》

从软件工程的角度解读任正非的新年公开信

xinsheng.huawei.com/cn/index.ph…

  • 金三角：时间，范围，成本-》质量
  • 安全
  • 技术是工具，合理选择
  • 一致性
  • 习惯
  • 视高质量代码为尊严和个人声誉

怎样学好软件工程？

image.png

软件工程=工具+方法+过程

image-20220911171616012.png

四境界

  • 用器

    • 工具

  • 学术

    • 方法

  • 悟道

    • 核心思想和本质规律

  • 传道

基础理论

理解软件工程

软件工程：为了研究和克服软件危机而生

用工程化方案去规范软件开发，让项目可以按时完成、成本可控、质量有保证

瀑布模型

image.png

基于瀑布模型，又衍生出 V 模型、原型设计、增量模型、螺旋模型等模型，试图改善瀑布模型存在的一些缺陷。这些改进模型的发展趋势上就是缩短项目周期，快速迭代。

工程思维：把每件事都当做一个项目来做

image.png

瀑布模型

后来软件开发需求越来越多，功能越来越复杂，从事软件开发的人员水平也参差不齐，这种落后的软件生产方式已经无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题，这个现象也被称之为“软件危机”。

image-20220911173630975.png

image-20220911173727092.png

其他模型

  • 快速开发快速改：快速原型模型，为了解决客户需求不明确和需求多变的问题，客户可能没想好要盖什么房子，但是牺牲质量

    • 抛弃策略
    • 附加策略

  • 模型瀑布周期太长，所以产生增量模型和迭代模型

    • 增量模型-按模块分批次交付

      • 需求比较清楚，能模块化的软件系统，并且可以按模块批次交付
      • 按功能划分

    • 迭代模型-每次迭代都有一个可用版本

      • 茅草屋-小木屋-别墅
      • 按时间划分，看单位时间能完成多少功能
      • 难点在于每次迭代的内容和要达到的目标

  • 怎么选择模型？

    • 外包，需要阶段验收

image-20220911174939403.png V模型，本质是瀑布模型

  • 项目风险高，随时可能中断
    • 强调风险，以风险驱动的方式完善开发模型就是螺旋模型

image.png

  • 山寨一款软件，希望快速上线

    • 增量模型，因为需求明确，没什么变化

  • 客户没想清楚要什么，但是个大单子

    • 那么这样的项目，你可以考虑拆分成四个阶段：

      1. 初始阶段：主要是确定需求边界和主要风险，几乎没有什么开发工作。
      2. 细化阶段：这个阶段主要是确定需求，可以采用快速原型模型开发，和客户对需求反复确认，需要辅助一定量的开发和测试工作。对代码质量可以要求比较低，重点是确认需求。可能需要一个或多个版本迭代。
      3. 构造阶段：在需求确认清楚后，现在可以使用迭代模型来开发，逐步交付产品。这个阶段的重点是开发和测试。如果迭代中，有新的需求加入或者需求变更，也可以在新的迭代中加入。
      4. 交付阶段：在开发和测试完成后，产品可以交付客户，根据线上运行情况还需要修复一些 Bug。这个阶段重点是测试和部署。也会有多个迭代。

      整个过程看起来就像下图这样。

image.png

    统一软件开发过程，适用于复杂合需求不明确的软件系统

  • 产品已上线，需要持续更新维护

    • 迭代模型
    • 敏捷开发：基于迭代模型，快速交付，每次交付部分功能保证客户满意度，系统交付周期叫冲刺，严格说敏捷开发不是开发模型，更像框架或指南，有各种开发模型实现敏捷开发，比如极限编程，看板，Scrum

敏捷开发

一套价值观和原则，指导：客户合作高于合同谈判

敏捷开发，在每个迭代后，都应该向客户收集反馈，然后在后面的迭代中，酌情加入客户反馈修改的内容

Scrum 主要用来管理项目过程，极限编程重点在工程实践，而看板将工作流可视化

  • 敏捷开发如何做需求分析？

    • 用户故事，减少大量需求文档撰写

  • 敏捷开发如何做架构设计？

    • 每个Spring制作一部分需求，是一种渐进式架构设计
    • 技术债务，需要定期对系统架构进行重构

  • 敏捷开发如何保证项目质量？

    • 编写单元测试，继承测试代码，用自动化方式完成测试

  • 敏捷开发如何发布部署？

    • 持续集成：每次完成一个任务，提交代码后都可以触发一次构建部署操作，脚本会拿最新的代码做一次全新的构建，然后运行所有的单元测试和集成测试代码，测试通过后部署到测试环境。

  • 敏捷开发的Spirnt和迭代模型的迭代有什么区别？

    • 迭代模型->小瀑布模型
    • Sprint没有严格阶段划分，Sprint节奏恒定
    • 敏捷开发更注重人的作用

大厂常用敏捷方法

  • 围绕Ticket开展

    • 直接从To Do栏选一条Ticket做就ok

  • 基于Git和CI开发

    • 如果用瀑布模型：代码不稳定，部署太麻烦
    • CI：可以想象为一个机器人，每次提交一个PR，这个机器人马上就知道了

怎样平衡软件质量与时间成本范围的关系？

  • 老板压缩时间怎么办？

    • 调整范围
    • 调整成本

  • 产品经理临时加需求怎么办？

    • 延时
    • 增加成本

  • 极限编程怎么做到极限的？

    • 如果某个实践好就做到极限

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

    • 一开始制推出最核心的功能，满足用户最核心的要求，然后在用户反馈中迭代

解惑

  • 开发价值体现在哪里？

    • 需求分析和理解
    • 架构和抽象能力
    • 高效率编码，完成需求

  • 运维前景

    • DevOps在兴起，DevOps不仅有运维能力，还有开发能力

  • 怎样培养团队成员？

    • 招人和开人
    • 设置合理流程，配合一定奖惩制度
    • 团队要有梯度
    • 实战中锻炼

项目规划篇

可行性研究

  • 经济

    • 短期，长期
    • 人力成本
    • 软硬件成本
    • 其他成本
    • 收益

  • 技术

    • 经验
    • 稳定性

  • 社会

    • 道德
    • 社会影响
    • 法律

如果你想技术转管理，先来试试管好一个项目

管理需要大局观，整个项目角度，整个团队角度其思考，确定方向，发现问题，解决问题，及时调整

关注细节的是工程师

关注过程的是项目经理

关注结果的是老板

  • 管好人

    • 管理好客户预期
    • 用流程和规范让项目成员一起紧密协作
    • 项目成员应该遵循流程规范

  • 管好事

    • 选择适合项目的开发模式
    • 制定好项目计划
    • 对计划跟踪和控制，做好风险管理

  • 经验教训

    • 不要写代码
    • 团队成功才是你的成功
    • 形成自己的管理风格
    • 坚持

项目计划：代码未动，计划先行

  • 如何制定计划

    • 任务分解
    • 估算时间
    • 排任务路径
    • 设置里程碑

流程和规范：红绿灯不是约束，而是用来提高效率

白天开会，加班写代码的节奏怎么破？

  • 砍掉一些没价值的会议
  • 减少参与会议的人
  • 缩短开会时间
  • 提升会议价值

项目管理工具：一切管理问题，都应思考能否通过工具解决

一个任务，只有 0% 和 100% 两种状态是准确的，中间状态都是不靠谱的

  • 项目管理软件

    • MS Project
    • OmniPlan
    • Merlin Project
    • Jira
    • Azure DevOps
    • 禅道
    • Worktile
    • TAPD
    • 云效
    • DevCloud

风险管理：不能盲目乐观，凡事都应该有B计划

风险=损失*发生概率

为什么你不爱写项目文档？

需求分析篇

需求分析到底分析什么？怎么分析？

  • 需求分析到底分析什么？

    • 挖掘真实需求
    • 提出解决方案
    • 筛选和验证方法

  • 怎么分析？

    • 收集需求
    • 分析需求
    • 需求评估
    • 需求设计
    • 验证需求

原型设计：如何用最小的代价完成产品特性？

产品意识

技术思维会关注用什么技术，关注技术细节，关注功能“如何”实现；产品思维会关注用户体验，关注一个功能所创造的价值，会去思考为什么要或者不要一个功能。

如何应对需求变更？

  • 在需求变更这个事情上，没有赢家，每个人都是受害者。

    程序员自己辛苦的工作白费了，得不到成就感，因为频繁变更的需求，不得不在设计的时候

    考虑很多可能的变更，导致代码臃肿，代码质量降低，加班加点成了常态。甚至有人

    说：“杀一个程序员不需要用枪，改三次需求就可以了！”

    产品经理也觉得很委屈：“客户要改，我有什么办法？”程序员和产品经理似乎变成了两个

    对立的岗位，程序员怪产品经理乱改需求，产品经理觉得是客户造成的，人人都觉得自己委

    屈。客户同样不满意，觉得做出来的软件不是他想要的，进度总是在延后，还想加钱？

  • 怎么办？

    • 变更流程，让需求变更更规范
    • 快速迭代，缩短版本周期

系统设计篇

架构设计

  • 需求让技术变复杂

  • 人员让技术变复杂

  • 技术本身也复杂

  • 让软件稳定运行时复杂的

  • 架构设计的目标

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

开发编码篇

以终为始，想清楚再开工

程序员核心竞争力

  • 学习能力
  • 解决问题能力
  • 影响力

软件测试篇

运行维护篇

DevOps 可以理解为一种开发（Development）和运维（Operations）一起紧密协作的工作方式，从而可以更快更可靠的构建、测试和发布软件

  • 日志管理
  • 项目总结，把经验变成能力

经典案例讲解篇

小团队

  • 成本
  • 人少活多
  • 缺少流程规范

怎么办？

  • 团队建设

  • 流程建设

    • 源代码管理工具
    • 外部提交需求和任务

为什么程序员的业余项目大多都死了？

  • 想法大，时间少
  • 过于追求技术，缺少约束
  • 缺少产品能力和运营能力

怎样提升业余项目成功的概率？

  • 金三角的理论，去缩小范围，在做项目时，可以采用 MVP 的开发模式，先实现核心需求，再逐步增加功能。
  • 针对过于追求技术、缺少约束的问题，应该要对你的项目制定计划，设定里程碑
  • 针对缺少产品能力和运营能力的问题，需要有针对性地去学习相关知识，也可以去组建小团队，弥补这些方面能力的不足。

结束语

学习软件工程最大的收获，就是在看问题的时候，不再局限于从技术层面或者是一个局部去思考问题，而是站在整体，用软件工程的方法去指导自己的思考和决策。

  • 项目未动，计划先行
  • 复盘

\

avatar
文章
阅读
粉丝