第一讲 介绍
工程这个词,对应的是科学
工程是可以重复的,而科学通常不强求重复
软件工程:其中遇到的模型,怎么做,方法
一、基本信息
1.模块化的设计 UML diagrams图
2.涵盖软件整个生命周期,和软件开发的整个阶段应该怎么去做。
3.以团队为主的(team-based),需要实际动手操作,需要一系列编程。
4.不会教任何一门特殊的编程语言
5.团队开发一个相对逻辑复杂(编程、业务)的系统,需要多方面(性能和资源的小号如并发量、存储量)的权衡。
二、参考书目
三、介绍
Software is complex=事情由很多部分组成,能够互相关联在一起。
(而complicated 模糊的,即便分析也分析不出来,不能解释。)
防止产生温水煮青蛙的问题:
1.小问题尽量考虑清楚,从而不至于导致大的缺陷
2.负面反馈是一种积累,刚开始看上去问题不大,到后面就会太严重以至于不能解决
3.Design smells,technical debt,software rot
四、软件工程的角色
第一法则:必须能够学习问题的领域(先要知道客户需求)
Customer:需要一个计算机系统去实现一些业务目标,通过用户交互(与环境,或与一个特殊方式)
软工的任务:理解system-to-be如何与环境或user交互,从而能够达成用户需求,并且设计software-to-be
解决问题的策略:分而治之:
1.识别系统上的逻辑组成部分(逻辑划分),其能解决问题的一块
2.掌握问题最快的方式:需要领域专家(谁懂怎么去用,目前是怎么做的)
3.产生:领域问题的模型(或问题域模型)
五、软件工程的蓝图
1.准确的理解软件的问题和解决方案
(1)不幸的是,很多人不是艺术家画不出来,所以我们用一些工具,UML symbols
六、第二法则
第二法则:以人为本
Nurture培养滋养
七、软件开发方法:工作策略
1.瀑布模型
单向的 不能回滚。开发好开,修复不好修复
2.迭代和增量模型
3.持续的用户反馈,反馈在不同级别上与项目本身有关
八、UML
九、有多少种绘制图形的方式?
1.在早期阶段和开发团队内部使用非正式的、临时的、手绘的、粗糙的图表。手绘会导致节约和低情绪投资,始终拍摄快照以保存记录以备将来回顾
2.使用标准化的、整洁的,计算机生成的图表,保证一致性,设计有“稳定性”。标准化的绘图方式如UML,在广泛的利益相关者(stakeholder)之间促进沟通。先画草图,仅仅在设计达到一致的时候,才需要用标准化的图表。
十、理解问题领域
Actors–能与系统交互的系统外部的角色
概念/对象–能起到一定作用的在系统内部使用的角色
用例–若干个使用系统的场景
十一、项目管理:
如何评估:
1 成本和周期(时间规划)的问题:
2 产出 质量评估
评估策略:
1 猜测工作的每一个小部分是什么(基本单元划分)
2 做一点工作,判断出来自己的工作效率
3 尽量让估计变得准确
4 不断迭代,直到需要不再需要纠正之
项目没有实施的时候不存在。初始化的估计依靠于经验和想象。
Backlog 有具象估计,工作量和优先级
评估需要领域知识,而不是开发者
概念图:概念➕关系图
Tenant租客
然后用use case图做场景设计
十二、状态和转换图:
第二讲 对象模型
一、对象和方法调用
二、接口
接口----指纹、签名
多态:子类对父类的同名方法做不同的实现机制
模块:子程序和数据的松散分组
三、UML表示法
四、对象关系
组成:使用实例引用其他对象的变量
继承:继承普通通过类扩展的属性
继承和组合都扩展了另一个对象提供的基本功能
继承:“基类”中的更改会传导到子类及客户机类。
但是任何代码更改都有无意引入bug的风险。
组合:更能适应变化,因为“基类”中的变化很容易被“包含”并对前端类的客户机隐藏。
五、面向对象/算法与面向对象方法
面向过程:更直观,以人为中心
思考下一步该做什么,该走哪条路
But:大规模的问题需要人的组织,而不是单独个 人工作
面向对象:由于分工,面向对象会更混乱
思考如何把问题分解成任务,分配责任,协调 工作。这是一个管理问题。
But:很难设计好的组织
六、如何设计好的面向对象的系统?
决定性方法因素:
1.可追溯性:可以一步步跟踪系统的发展,从单个需求到设计对象,再到代码块。
避免莫名其妙的跳跃
2.测试:测量 安全
测试驱动开发:开发过程中每一步必须从如何验证结果是否符合目标的计划开始
开发人员只有在知道如何测试的时候再创建软件工作。
3.测量
但是测试是不够的
4.安全
第三讲 软件配置管理
一、 概念
(一)SCM的作用
软件配置管理是控制软件系统演化的过程
- 简化分享代码和其他文档
- 能够回溯到旧版本undo
- coherently并发的整合团队成员的贡献merge
- 通知新模块的相关部分的改变reporting
- 追溯软件问题(如bugs)
- 创建一个可以审计的记录(archiving 归档)
(二)为什么做SCM? - 简化、增量产出
- 传统方式不合适so有新的便捷方式
(三)定义 - 软件配置:一系列在一个项目周期内完成的工作的整合
- 软件配置条目:被一个人/开发者/客户关心的内容
- 镜象snapshot:项目到一个节点的时候做的快照,包含条目,每个条目的版本和时间
- commit提交:提交一个项目配置到项目数据库repository
5.build构建工具:一个版本的项目代码,发布成可以运行的格式。计算机上单独的可执行的代码。
(四)
repository:项目数据库(多人共享的)project database
workspace:自己的电脑/机器中的数据库
(五)版本图 vs分支
master branch/trunk/mainline
Fork修订分支
merge提交合并到主干
每一次commit代表一个不同的版本
snapshot通常指的是最新的版本的
二、 工作环境
场景:
-
在新工作中撤销错误undo mistakes
-
支持多分支(多管齐下)产品演变
-
发展产品线
-
peers为工作单位工作
-
以受控管理的团队为工作单位
cicd开发部署一体化
revert保留当前版本,回溯到正确版本git revert(safe)
reset删除当前版本,回溯到正确版本git reset
第四讲理解问题和划分工作
分而治之的思想:降低耦合性,尽量独立完成工作
康威法则:设计系统的组织通常受限于组织内部的沟通的结构
最终交付的模型与组织结构相关
一、 任务切分的两种模式 partitioning && projection
二、 职责划分
三、 减少团队内的沟通
划分工作的两种方法:
一、由问题划分
二、由解决方案划分
不同团队成员负责系统的不同部分
反例:汽车生产中,不同公司负责不同子系统
经过大量试错后,每个子系统都能演化成独立解决子问题的不同的系统了
第四讲 设计模式