高级软件工程-复习

高级软件工程复习

坐标国科大，下面是老师说的考试重点。

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)

提倡痩视图和控制器、不要在视图中添加功能代码。

2,比如嵌入式系统

在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

RUD

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<--------