《学校没教的软件工程课》- 周忠信 笔记

本文深入探讨了软件开发中的关键环节,从需求理解、架构设计到用户体验,强调了文档的重要性、敏捷开发、质量保证和团队协作。通过实例揭示了需求变化、可扩展性和测试策略,突显了软件生命周期管理与用户导向的价值。
摘要由CSDN通过智能技术生成


前言

软件开发的难度随着需求的增加而呈现指数增长,但软件需求越来越多,程序往往会越来越难修改。同时随着软件越做越大,开发需要更多的人来参与,若没有一套工程化的程序与管理办法,软件最终会走向失败。这本书有三十个案例,我会一一总结(最后一点学好软件工程这个好像每个学习相关知识的同学都知道)。书籍购买某东链接(当然其他的平台也可以)


1、需求并不简单

  • 需求并不能只听客户描述,必须深谈
  • 客户并不可能完全表达清楚需求,需要持续沟通
  • 软件开发复杂度随需求以几何倍数增加

2、需求不仅仅是功能

  • 还要考虑:效率、网络、安全等
  • 以上考虑的方面可能会反过来影响到软件的开发
  • 应该量化指标eg:在20个并发用户下,平均响应时间为1s

3、领域知识

  • 常常会遇到“领域知识”(domain knowledge),要搜集资料了解
  • 实际工作所积累的经验也很重要

4、可读性

  • 文档的书写会影响编程者对于需求的理解与认知
  • 但需求转换为文字都会引起一定的误差,要通过后期不断沟通来解决
  • 编写文件使文档标准化

5、变是常态

  • 需求会随时间而改变
  • 整体而言,需求会越来越收敛
  • 在编写软件之前,要建立软件全貌,发展企业架构
  • 控制开发时间
  • 做好需求管理,尽量不要随意改变软件需求

6、文档不可少

  • 软件开发的无形性(intangible),看不见、摸不着的特性常是实现撰写文档的困难
  • 最好在软件开发之前编写设计文档

7、软件架构

  • 要遵守规范、配合程序的系统化思维
  • 不同的软件要有设不同的计原则和方法从而满足非功能需求或其他与质量维护相关的目标
  • 要学习软件架构知识、设计模式

8、应用知识

  • 当需求确认之后,不同的系统分析会产生不同的系统。分析越好的系统才可以满足目标
  • 要想分析的好,则要掌握相关“应用知识”(application knowledge)
  • 不仅要经过学习获得,而且要通过长期接触同领域类似软件,并积累应用经验才可

9、用户体验

  • 好的软件一定要考虑“用户体验”
  • 要考虑到用户的使用环境

10、既要做对又要做好

  • “做对软件”是指开发完成的软件功能完全符合需求,同时执行的结果也完全正确
  • “做好软件”是指开发完成的软件执行时不会不稳定,也不会因质量不好而经常闪退

11、开发软件的四大关键

  1. 定义出正确的需求
  2. 将需求分析成系统
  3. 发展用户界面设计
  4. 设计符合功能与非功能需求的软件架构

12、雏形不靠谱

  • 雏形是指在软件开发完成前,事先制作用来参考的软件·
  • 雏形可以让无形的分析设计,变成看得见又可以实验操作的有形的对象
  • 雏形最重要的目的是在面对特殊需求的挑战eg:特定非功能需求、界面、关键功能设计需求,由于存在疑惑,因此可以先做出来雏形以帮助探讨问题,进而解决挑战。
  • 用完就丢弃,不要吝啬

13、不只是写程序

  • 软件开发不只是写程序,还涉及多项不同开发工作与步骤,因此控制“软件流程”很重要
  • 产品的生产制程是有流程的,成为制造流程。由于步骤是一步步往前推进的所以可以称为“瀑布流程”
  • 最简单的软件流程是瀑布流程,缺点是不够敏捷,只有到最后才可以看到结果

14、敏捷不容易

  • 在快速短周期的多次反复程序下,敏捷的软件开发流程可以避免瀑布流程的缺点
  • 敏捷软件开发过程需要多次反复进行。在此过程中,因为新需求而需要多次反复进行重构之前的架构设计;叠加过程中,也需要不断持续集成测试,确保之前与本次开发的一致与正确
  • 当软件需求多且复杂,选用任何一种软件开发流程都是问题

15、预估跑不掉

  • 确定需求,用多少人用多久时间要基本明确;过程中会存在许多无形的问题和不确定性
  • 每次编写软件必须预估

16、牵一发、动全身(可扩展性)

  • 软件设计时,架构上要支持扩展性,特别在面对需求时常变动时
  • 软件架构上应该尽可能松耦合,不会波及太多其他的程序

17、昨天永远是对的(做好软件测试)

  • 软件交付到客户手上时,一定要经过测试把关,以确保软件符合需求,同时没有错误
  • 软件开发在不同阶段各有不同的对应测试。例如:个别程序开发时,应该进行个别程序单元功能测试;多个程序集成在一起要进行集成测试,甚至与非功能目标进行有关测试。eg:压力测试、效能测试。
  • 功能测试成功与否与非功能测试成功无关。

18、改a错b

  • 质量是软件成功与否的关键。没有好的质量就不会有好的软件
  • 要经过多种不同种类的测试
  • 当版本更新时候,要测试所有的部分

19、质量不是测出来的

  • 测试不能改善质量,只能帮助检验质量水平。真正质量的改善还是得回归软件设计
  • 若等到最终软件完成后才进行测试,万一质量无法过关,此时在改善很难
  • 要落实软件开发步骤,维持每个步骤该有的审核测试和检验。

20、软件的生命

  • 软件从开发、上线使用、退役换新。也需要版本更新,适应系统、数据库
  • 要做好“软件生命周期管理”

21、一部历史

  • 要记录之前所有的需求、设计、程序本身等
  • 做好软件版本控制

22、换人

  • 在软件的生命周期中,开发团队人员变更不可避免,这时就要做好架构笔记
  • 每个版本都要检查客户需求是否正确

23、加人

  • 软件生命周期维护是一件涉及许多内容的开发工作,新进力量往往需要投入时间理解前述知识才可以逐步投入工作
  • 新旧成员间的沟通成本增加,初期生产力会大幅升高,所以要加强各方面的沟通

24、宁错勿慢

  • 程序开发大部分一般用户无法理解,我们不能宁错勿慢,之后修改错误产生的成本往往会很高

25、到底了没(做好功能追踪)

  • 软件的生命周期中,较大型或较复杂的软件,用户可能会遇到各种各样的不可预期的异常。造成这种现象的原因有很多:需求变更,系统环境改变
  • 软件生命周期中遇到的多种异常不可避免,要追踪管理异常可能影响的范围

26、生产力

  • 生产力较难计算,难以评估工作人员的贡献程度
  • 程序的质量无法当下呈现,有时只有等到用户使用的时候才可以被发现

27、就是要管理

  • 软件开发是抽象的,但并不是无法落实的
  • 管理一定要落到实处
  • 一定要关注成本进度质量
  • 建立量化程序,发展软件项目管理

28、集成躲不掉

  • 大部分的商业软件都要面临这集成
  • 软件集成涉及多个层次,包含数据、流量、应用、界面层面等等
  • 要掌握相关集成知识并清楚原理

29、没有好不好,只有用不用

  • 一定要以用户为中心,用户愿意使用的软件才是好软件
  • 复杂软件不要想着满足所有用户的需求
  • 可以设计教程来促使使用者学会使用软件
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值