高级软件工程复习
坐标国科大，下面是老师说的考试重点。
- 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<--------
