一、课程感想
这个学期选择了孟宁老师的高级软件工程课程,孟宁老师风趣独特的讲课方式和科学合理的传授知识的方法让我受益匪浅。如今,一学期的课程即将结束,来总结一下学习这门课程的一些感想和内容。
孟老师对于这门的讲授方式有非常独特的理解,在开学的第一节课就讲述了传统的高级软件工程是什么样的,以及他认为的高级软件工程该如何学习。
这是孟老师ppt中的内容:
并且,孟老师举了一个非常贴切的例子来向我们说明了为什么这门课程有非常多的动手练习和实验内容。这是一个陶艺课的故事,一群学习陶艺课程的学生分为两组,一组以制作陶艺的质量作为评分标准,二另一组以制作的数量作为评分标准。一个学期之后,真正好的陶艺作品在那一组?很多人都认为会出现在以质量作为评分标准那一组,但实际上其实出现在以数量作为标准的那一组,这个答案非常出乎我的意料。但是老师解释道,以质量为准的反而有可能会畏手畏脚不敢开始,而且优秀的质量往往是以巨大的数量作为基础的;而以量为准却可以鼓励学生开始制作,所谓千里之行始于足下,只有开始了并且不断地尝试才能不断地提升自己,哪怕刚开始不停的失败,但是在一次次失败中会逐渐停止恐惧、树立起自信,最终获得成功。
这个例子引起了我的思考,给我带来了一种新的思路。就这样,我们带着一丝新奇的心情开始了软件工程课程的学习。
课程一共由以下几个部分组成:
1、工欲善其事必先利其器——Typing、VSCode、Git、Vim、RegEx
2、代码中的软件工程——一个工程化C语言项目范例
3、需求分析与设计——从分析到设计的基本方法
4、软件系统设计——代码的结构、特性和描述方法
5、工程过程与项目管理——软件危机的前生后世
二、课程笔记
先做再学
用不到软件工程中所学的知识,因为做的项目太过于简单
构建之法
软件工程-理论与实践
梦断代码、人月神话
LSP(language server protocol)
DAP(debug adapter protocol)
git init 在一个新建目录下初始化一个本地版本库
git status 查看当前工作区
git add [FILES] 把文件添加到暂存区
git commit -m “message” 提交
git reset 回退版本
git log 查看日志(head之前)
git reflog 查看日志
git clone
git fetch
git push
git merge
git pull
git clone、git pull
git chechout -b mybranch 创建并切换分支
git branch 查看分支情况
git merge --no-ff mybranch 合并分支
merge后要快速pull到远端
git rebase
团队流程、使用熟悉一下vim
$git rebase -i HEAD^^^
git rebase --abort
git rebase --continue
/:vim中开启正则表达式
.、*、?、|
{3,5}
[a-z]、[abc]、[^]
/d /D /w
greedy贪婪匹配(默认):最长的
lazy懒惰匹配:最短的。加‘*?’
捕获组
耦合度:软件模块之间的依赖程度
内聚度:一个软件模块内部各元素互相依赖的紧密程度
使用本地化外部接口提高代码的适应能力:
内部代码(API)→外部代码 ==》 内部代码(API)→API→外部代码
设计→代码 ==》 设计→伪代码→代码
接口的规格(要素)
接口的目的
使用前需要满足的条件,前置条件
双方遵守的协议规范
使用后的效果,后置条件
接口所隐含的质量属性
RESTful API
Callback
底层定义数据类型及其对应的一些方法(例如search),上层可以给数据类型添加一些属性。上层调用底层方法时,由于新增了属性,对新增属性的操作无法进行。于是,底层方法添加一个形参,在上层自定义对新属性的操作方法,并作为参数传入底层方法。
// Serach a LinkTableNode from LinkTable // 用户在上层自定义方法,处理新增属性的操作。args传递数据,使紧密耦合变为松散耦合 int Condition(tLinkTableNode * pNode, void * args); // 顶层接口中的方法 tLinkTableNode * SearchLinkTableNode(tLinkTable * pLinkTable, int Condition(tLinkTableNode * pNode, void *args), void *args);
接口与耦合之间的关系
公共耦合(紧密)
软件之间共享数据区或变量名,两软件之间的接口定义不是通过显式的调用方式,而是隐式的共享了数据区或变量名
数据耦合(松散)
软件模块间仅通过显式的调用传递基本数据类型
标记耦合(松散)
软件模块间仅通过显式的调用传递复杂的数据结构。数据结构成为调用双方软件模块隐含的规格约定
通用化接口
参数化上下文
移除前置条件
简化后置条件
原型化方法
建模的方法
用例建模、业务领域建模、业务数据建模
抽象用例
高层用例
扩展用例
基本步骤
提取抽象用例
寻找业务领域的动名词,验证这些动名词是不是用例,是否满足条件
条件1:是不是一个业务过程
2:是不是由某个参与者出发开始
3:是不是显式或隐式地终止于某个参与者
4:是不是为某个参与者完成了有用的业务工作
定义范围,即高层用例
根据关系画出用例图
根据具体细节扩展用例
*取钱用例分析(写在感想中)
对象、属性
继承关系:概括化/具体化
聚合关系:一个对象是另一个对象的一部分
关联关系:两个概念之间的关系
收集业务领域信息
头脑风暴
识别业务领域相关的概念
名词和名词短语
“Y 的 X”(X of Y)表达方法,比如汽车的颜色
及物动词
形容词
数量词
所有关系的表达方法,如具有、拥有
构成关系的表达方法
包含关系的表达方法
”X 是一种/类 Y“表达方法
对象可以独立存在,属性不可以
给出分类
将分类结果用UML图画出
关系表
范式:在尽量减少冗余的情况下,追求数据的一致性
one-to-few
嵌入
one-to-many
间接/子引用
one-to-squillions
父级引用
反范式化
读写比高时适用,无法原子更新
如双向关联
概念原型=用例+数据模型
瀑布模型
统一过程
统一过程的核心要义是用例驱动、以架构为中心、增量且迭代的过程
售前计划
开工后计划
增量阶段
用例建模
业务领域建模
对象交互建模
形成设计类图
软件的编码实现和部署
深入到功能内部的具体实现
剧情描述、剧情描述表
在扩展用例中右侧一列中找出关键步骤
对于每一个关键步骤,完成剧情描述,描述一步一步的对象交互过程
将剧情描述进一步转换成剧情描述表
将剧情描述或剧情描述表转换成序列图