高级软件工程-复习
高级软件工程复习
坐标国科大,下面是老师说的考试重点。
- Ruby编程语言的一些特征需要了解
- 要能读得懂Ruby程序
- Git的基本命令操作知道
- Rails的MVC工作机理需要清楚,Model, Controller, View各司什么职责明白
- BDD的User Story需要会写,SMART要求能理解
- TDD的Rspec读得懂,会补充
- 重点:最常用的几种设计模式知道、理解、会用;SOLID原则是什么?什么情况下是违背的。
SOA(Service Oriented Architecture)面向服务架构:所有组件都设计为服务、且服务可以组合的软件架构。
**特点:**一个服务直接访问另外一个服务的数据时可能出现不稳定。
软件质量(Quality Assurance)
软件质量保障(QA):确保软件开发的质量,改进优化过程,提高效率。
一般通过测试来保证软件质量
这个题的24,怎么选
提高开发者生产力:简洁性、合成、重用和工具
4种技术
- 通过表达的简洁化:语法更短更易读、抽象级别提高(高级程序设计语言、自动内存管理、动态脚本语言:计算反射和元编程)
- 程序合成(Program Synthesis):生成代码以适应情境和删除条件测试
- 重用 (Reuse):重用旧代码vs.编写新代码
- 重用技术(按历史顺序排列)
- 过程和函数-procedure, function
- 标准化库(重用单一任务)-standard library
- 面向对象编程-Object Oriented Porgramming: 重用和管理任务集合
- 设计模式-Design Pattern: 实现可以不同, 但重用的是通用策略
- 重用技术(按历史顺序排列)
- 自动化和工具 (Automation & Tools)
DRY-Don’t Repeat Yourself
在一个系统中,每一知识必须有一个单一的、明确的、权威的表示。
P&D软件过程模型
P&D: 计划与文档
- 编码前,项目经理制定计划
- 撰写计划各阶段的详细文档
- 根据计划来度量进展
- 项目的变更必须反映在文档中,并可能反映在计划中
瀑布模型 | 螺旋模型 | Rational统一软件开发过程,RUP |
---|---|---|
缺点:当客户看到开发出来的产品时,通常想要对软件产品进行改变,这时就会遇到麻烦。 | ||
— |
P&D需要大量的文件和计划,并依赖于经验丰富的经理。
Aglie敏捷开发
个体与交互 vs过程 & 工具
工作软件vs全面文档化
客户协作vs合同谈判
响应变更vs遵从计划
敏捷强调测试驱动开发(TDD)来减少错误,记录用户故事来验证客户需求,用速度来度量进展。
设计模式:捕捉/刻画重复出现问题的常见结构化解决方法。
Client/Server: 架构级设计模式,Web是C/S架构,面向请求/应答方式。
Ruby/Rails框架中,Rails复杂管理防止篡改cookie
三层架构:表示层-逻辑(应用)层-持久层
MVC(Model-View-Controller)
提倡痩视图和控制器、不要在视图中添加功能代码。
在MVC中,用户可以进行的每个交互都是由控制器中的动作来处理的
Ruby语言中的方法(method)处理这种交互。
Git
使用版本控制系统
命令 | 说明 |
---|---|
checkout | 从库中拷贝一个版本的代码 |
commit | 将代码写回仓库 |
Git基础
命令 | 说明 |
---|---|
git init | 创建仓库 |
git config | 配置仓库 |
git clone <url> | 获取一个仓库 |
将变更录入仓库 | |
git log | 查看变更历史 |
git push ,git pull | 与远程仓库同步 |
git branch <branch_name> ,git checkout <branch_name> | 创建分支 |
git merge ,git rebase (branch 1) 在branch2上执行 | 合并分支 |
git rest --hard <commit_id> | 回退 |
git revert <commit_id> | 撤销 |
Git配置
Cit配置 | 配置用户信息 | 配置文本编辑器 | 查看配置信息 |
---|---|---|---|
git config --global / -- local | git config --global user.name "John Doe" | git config --global core.editor emacs | git config --list |
— | git config --global user.email johndoe@example.com | — | — |
Rails
Rails是使用Ruby语言建立的流行编程框架。
Ruby:现代动态脚本编程语言。
面向对象
,函数式
,自动内存管理
,动态类型
,mix-in
,闭包用于重用、元编程、程序合成
Rails遵守:(依赖于Ruby的语言特性:自省和元编程
,闭包
,模块(混合)
)
- 约定优于配置:命名遵守某些约定、不需要配置文件
- DRY:提取公共功能的开发原则:“在一个系统中,每一知识必须有一个单一的、明确的、权威的表示。”
CRUD: create, read, update, delete
Ruby->Database
从ActiveRecord::Base
子类化。–将模型连接到数据库+CRUD
ActiveRecord
上create
方法是new
方法与save
方法的组合。
save!
操作失败会抛出异常。
Rails解决方案: 开发、测试和生产环境都有自己的数据库。
**迁移:**用脚本描述更改,可以跨数据库类型进行安全快速移植。
# 创建迁移
rails generate migration CreateMovies
# 将迁移应用于开发环境
rake db:migrate
# 完成代码测试后,将迁移应用于生产环境,应用迁移还包括在数据库中记录哪些迁移脚本已经用过了
heroku rake db:migrate
# 新模型,创建模型文件
app/models/model.rb
# 更新测试数据库schema
rake db:test:prepare
# 最终部署
heroku rake db:migrate
Ruby->Routes
Ruby->Views
创建表单—
BDD(行为驱动设计)
BDD:在开发之前和开发期间询问有关应用行为的问题,以减少误解。
需求以用户故事的方法记录。
创建用户故事
SMART故事
SMART | 说明 |
---|---|
Specific | 明确:每个场景可测试 |
Measurable | 可度量:已知合理输入,预期结果存在 |
Achievable | 可达成(理想情况:一个迭代下完成) |
Relevant | 相关性(5个为什么) |
Timeboxed | 时间框(知道何时放弃) |
Cucumber测试
通过Cucumber,用户故事成为验收测试和集成测试用例
# 运行一个功能特征测试
cucumber filename
# 运行所有测试
rake cucumber
绿:通过的步骤
黄:还未实现的
红:失败的–然后步骤是蓝色的
目标:使所有步骤通过
显式/隐式、命令式/声明式场景
显式需求:验收测试的一部分
隐式需求:显式需求的逻辑结果、集成测试
- 将电影列表
- 电影按时间顺序还是字母顺序排列?
**命令式场景:**初始用户故事,有许多步骤,指定逻辑顺序,直达所需结果。
如果很多用户故事是命令式,那就不DRY
**声明式场景:**描述状态而不是序列。(更少的步骤)
声明式步骤:描述应用程序应该处于的状态
命令式步骤:将当前状态改变表示为期望状态的步骤序列
TDD(测试驱动开发)
在代码本身之前,先为代码编写单元和功能测试
Rspec测试被称为specs或者例子
respec filename
# 运行测试
单元测试-FIRST原则
FIRST | 说明 |
---|---|
Fast(快) | 快速运行测试子集、因为将一直运行它们 |
Independent(独立) | 没有测试依赖于其他测试、远程可以以任何顺序运行任何子集 |
Repeatable(可重复) | 运行N次,得到相同的结果(以帮助隔离bug并启动自动化) |
Self-checking(自检查) | 测试可以自动检测是否通过 |
Timely(及时) | 与被测试的代码同时编写(使用TDD需要先编写测试) |
TDD周期:红-绿-重构
以“始终拥有工作代码”为目标。考虑代码应该完成的一件事(功能)
红:在失败的测试中记录/步骤这种想法
绿:编写尽可能简单的代码使测试通过
重构:与其他测试一起来提炼共性、改进代码。
继续完成代码应该做的下一件事。
接缝(Seam)
接缝:可以唉不改变源代码的情况下改变应用程序行为的位置。
对测试有用:将某些代码的行为与其所依赖的其他代码隔离开来。
每个seam仅为测试中地某些特定行为提供足够地支撑。
Seam概念 | 说明 |
---|---|
存根(stub) | 类似should_receive ,但没有期望;add_return 可选地控制返回值. |
模拟(mock) | “特技替身”对象,常用于行为验证(让某方法被调用)、字其上为单个方法创建存根. |
RSpec
装置/工厂
从何获取真实对象?
装置(Fixture) | 工厂(Factory) | |
---|---|---|
说明 | 静态地将一些已知数据预加载到数据库表中 | 只创建每次测试所需要的内容动态创建 |
需求 | 每次测试之前,db需要擦除和重新载入 | 根据测试需要,设置helper 来快速创建带有默认属性的对象 |
赞成的原因 | 真正的静态数据(e.g.永远不变的配置线性),恒容易在一个地方看到所有测试数据 | 保持测试的独立性:不受它们不关心对象的影响 |
反对的原因 | 可能会引入对装置数据的依赖 | 复杂的关系可能很难建立(但可能表明代码耦合过紧) |
测试覆盖、单元测试、集成测试
覆盖度量
覆盖度量 | 说明 |
---|---|
S0 | 方法覆盖 |
S1 | 调用覆盖 |
C0 | 语句覆盖 |
C1 | 分支覆盖 |
C1+ | 判定覆盖:条件中的美国个子表达式 |
C2 | 路径覆盖(苦难,价值如何有很大分歧) |
测试与调试
变异测试:在代码中引入故意的错误、是否会有一些测试失败?
模糊测试:1万只猴子向你的代码扔随机输入:1.发现了MS~20% bug,崩溃了~25%的Unix应用工具2.以应用程序不应该被使用的方式来测试它
DU-覆盖率:每一对<define x/use x>
执行了吗?
黑盒测试/集成测试:不依赖于对应用程序结构的理解
白盒测试
代码坏味-SOFA
通过捕获哪些白哦是代码坏味的症状。
- Short:短的
- One:只做一件事
- Few:不多的参数
- Abstraction:一致的抽象级别
定量:ABC复杂度
Assignment,Brach,Condition赋值+分支+条件,检查ABC复杂度
Agile敏捷开发
P&D
需求抽取:抽取非功能/功能需求
面谈、合作创建场景(快乐/悲伤路径流)、创建用例(UML描述)
需求文档(软件需求规范记录需求)
需求检查:有效性、一致性、完整性、可行性
PD维护
PD中设计模式
将软件需求规范(SRS)分解为问题(任务):
- 对每个任务寻找匹配的设计模式、然后是子问题的某事
- 设计评审将有所帮助
P&D中测试方法
将软件需求规范(SRS)划分为编程单元、开发人员编写单元代码+执行编程测试。
**独立的质量保证(QA)**团队进行更改级别的测试:模块、集成、系统、验收测试。
QA集成选项
自顶向下 | 自底向上 | 三明治集成 |
---|---|---|
从依赖关系图的顶部开始 | 从依赖关系图的底部开始 | 两全其美? |
高级功能(UI)很快就能开始工作 | 没有stub,吧所有的集成在一个模块中 | 通过自底向上集成一些单元来减少stub构造 |
构建许多存根Stub让应用程序“工作” | 不能看到应用程序工作,知道所有的代码和集成完成 | 通过自顶向下集成一些单元,让UI可操作 |
QA团队测试
QA团队进行系统测试:
- 完成的应用程序可以运行
- 测试非功能需求+功能需求
何时系统测试?–看机构的政策
- 测试覆盖级别(C0类似)
- 所有测试要输入好的/坏的数据
最后一步是:用户/客户验收测试(UAT)–确认&验证
性能
可以是验收测试的一部分。PD周期忽略了性能。
版本管理:
SaaS
SaaS:Software as a Service
SaaS通过运行在客户端设备上的瘦程序(浏览器、APP),访问Internet上以服务形式提供的软件(包括数据)。
优点:
- 无需安装、不用担心硬件与OS差异
- 无需担心数据丢失(数据远程存储)
- 便于团队共享和分享数据
- 如果数据很大/频繁更改,在中心站点保存一份副本更简单
- 软件单一拷贝、单一部署硬件/软件环境
SaaS对基础设施的需求:
- 通讯::允许客户与服务互动
- 可扩展性:需求波动满足新服务快速引入、增加用户
- 可靠性:服务和通信7*24h可用
SaaS类的设计模式
GoF:结构化、创建型、行为型
模式不是单独的类或者库,也不是完整的设计(更像是设计的蓝图)
**元模式:**把变与不变的东西分开。
- 针对接口百年城而不是针对实现编程。
- 比起继承,更倾向组合和委托:委托是接口共享、继承是关于实现代码共享。
SOILD面向对象编程原则
动机:将变更的代价最小化。
SOLID原则 | 说明 |
---|---|
单一职责(Single Responsibility, SRP) | 一个类应该有且只有一个改变的理由、每一项职责可能是变化的轴心、对一个轴的更改不应该影响其他轴。 |
开闭(Open/Close, OCP) | 类应该对功能扩展开发、对源代码修改关闭。–抽象工厂模式(提炼构造) |
里氏替换(Liskov substitution) | 子类型可以i替代基类型。 |
依赖注入(injection of dependencied, DIP) | 需求:a依赖于b,但b的接口和实现可以改变,即使功能稳定; 解决方案:“注入”a和b所依赖的抽象接口 |
迪米特(Demeter,DP) | 只和朋友交谈而不是陌生人。1.用委托替换直接方法调用,2.将遍历与计算分离(Visitor模式),3.在不了解实现细节的情况下只关注重要事件 (Observer模式) |
观察者模式Observer
实体Observer想hi到何时某些事情发生在实体Subject上。
非功能需求
服务水平目标(SLO,service level oeject)
考试回忆版
哈哈终于考完了,我为期1个多月的考试周终于宣告结束了。
考之前,一直在想,老师会不会根据给的题库然后做一些变动。但实际情况是:完全没有.
让我们说:谢谢老师!
此外,虽然老师给了部分的重点,但是还是和我自己复习的有一些出入,比如,我以为概念应该会考SOLID或者BDD/TDD,像单元测试的SMART,TDD周期的红-绿-重构这些。但其实都没考,反倒是后面出了一个SaaS的概念,但是考前就看了两眼,觉得不会考…
再一个有出入的就是,我以为会考点读Ruby程序给输出的题,毕竟简单,但也完全没有()
所以大家复习的时候,建议还是复习的全面一点,基本上给的题库要全部过一遍,然后根据老师给出重点,再过一遍重要的。因为如果万一没有命中的话,至少之前做过一遍,还是会有印象,至少不会是0分(?)
当然,要是有时间能够全面复习,那就太好辣!
很高兴你能看到这里~
获取考试试题,请到个人博客中找。就不放CSDN了~
Schwertlilien.blog<--------