Content
26 Lessons • 0 Quizzes • 0 Challenges
序言
- 1
课程简介
入门
- 1
可持续发展导论
- 2
假设
- 3
机会成本与持有成本
业务逻辑代码是一个缝合点
- 1
业务逻辑代码必须清晰地展现其行为
- 2
显式命名的类与显式命名的方法
- 3
返回丰富的结果对象,而不是布尔值或 Active Record
- 4
我们可能想要避免的实现模式
- 5
测验:业务逻辑代码是一个可插拔点
Rails 应用程序架构
- 1
我们的 Rails 应用架构及其边界
- 2
视图与模型
- 3
Rails 应用架构的优缺点
- 4
排版约定
- 5
测验:Rails 应用程序架构
模型 II
- 1
验证无法保证数据完整性
- 2
验证对用户体验非常有益
- 3
如何使用回调函数
- 4
模型测试策略
- 5
使用 Factory Bot 创建模型的有效实例
- 6
测验:模型 II
正确启动我们的应用程序
- 1
创建一个 Rails 应用
- 2
使用环境进行运行时配置
- 3
使用 dotenv 配置本地开发环境
- 4
使用 bin/setup 命令自动化应用配置
- 5
使用 bin/run 命令运行应用程序
- 6
将测试和其他质量检查放入 bin/ci 命令中
- 7
通过 lograge 提升生产环境日志记录
- 8
测验:正确启动我们的应用
端到端测试
- 1
示例需求
- 2
先构建用户界面
- 3
为开发创建有用的种子数据
- 4
使用语义化标签绘制用户界面
- 5
提供基础润色
- 6
美化表单
- 7
样式错误状态
- 8
编写系统测试
- 9
绘制业务逻辑并定义衔接点
- 10
完整实现并测试业务逻辑
- 11
已完成实现
- 12
回顾我们所构建的内容
- 13
测验:端到端测试
业务逻辑
- 1
业务逻辑让我们的应用程序变得独特且复杂
- 2
业务逻辑是复杂性的磁石
- 3
常用类中的漏洞影响广泛
- 4
关键类中的业务逻辑与复杂性
- 5
功能设计示例
- 6
测验:业务逻辑
控制器
- 1
控制器代码即配置
- 2
不要过度使用回调函数
- 3
控制器应将参数转换为更丰富的类型
- 4
不要过度测试
- 5
实现一个基本的可信度检查系统
- 6
测验:控制器
路由和URL
- 1
使用规范路由以符合 Rails 的默认设置
- 2
不要配置未使用的路由
- 3
自定义网址应重定向到规范路由
- 4
不要创建自定义操作,而是创建更多资源
- 5
合理运用嵌套路由
- 6
命名空间可能是一种架构设计
- 7
嵌套路由可以组织内容页面
- 8
测验:路由与URL
后台任务
- 1
工作概述
- 2
Web Workers、内存与网络请求
- 3
后台任务
- 4
Sidekiq 是大多数团队的最佳作业后台
- 5
直接排队任务
- 6
作业代码与测试策略(concept)
- 7
任务必须具有幂等性
- 8
测验:工作
HTML 模板
- 1
语义化 HTML 与使用有意义的标签
- 2
样式标签
- 3
变量的暴露
- 4
参考数据、全局上下文和用户界面状态是例外情况
- 5
可重用组件
- 6
直接使用 ERB
- 7
测验:HTML 模板
其他边界类
- 1
邮件发送器
- 2
Rake 任务
- 3
一个文件只包含一个任务,命名空间与目录结构一致
- 4
Rake 任务不应包含业务逻辑
- 5
Action Mailbox、Action Cable 与 Active Storage
- 6
测验:其他边界类
辅助工具
- 1
不要将辅助函数与领域模型混淆
- 2
助手最适合暴露全局用户界面状态。
- 3
尽可能减少辅助函数的定义位置
- 4
展示者、装饰器和视图模型
- 5
展示器面临的问题(concept)
- 6
使用 Rails 的 API 生成标记
- 7
助手应该可测试且应被测试
- 8
测验:辅助函数
Rails 之外的认证与授权
- 1
不确定时,使用 Devise 或 OmniAuth
- 2
使用 OmniAuth 进行第三方认证
- 3
授权与基于角色的访问控制
- 4
使用 CanCanCan 实现基于角色的访问控制
- 5
在系统测试中测试访问控制
- 6
测验:超越 Rails 的身份验证与授权
CSS
- 1
采用设计系统
- 2
采用一种 CSS 策略
- 3
一个 CSS 框架
- 4
面向对象的 CSS
- 5
函数式 CSS
- 6
创建一个活的风格指南来记录我们的设计系统
- 7
测验:CSS
API 接口
- 1
我们的 API 适用于谁?
- 2
以编写其他代码的方式编写 API
- 3
使用最简单的认证系统
- 4
使用我们所能使用的最简单的内容类型
- 5
只需将版本号放入URL中
- 6
使用 .to_json 创建 JSON
- 7
自定义 JSON 序列化
- 8
在模型内部自定义 JSON
- 9
始终使用顶级键
- 10
测试 API 端点
- 11
测验:API 端点
最小化 JavaScript
- 1
JavaScript 是一种严重的风险
- 2
拥抱服务端渲染的 Rails 视图
- 3
Jamstack 的架构
- 4
调整 Turbo 以提供稍佳的体验
- 5
测验:最小化 JavaScript
可持续的流程与工作流
- 1
使用持续集成进行部署
- 2
持续集成(CI)(concept)
- 3
CI 应该基于 bin/setup 和 bin/ci
- 4
频繁的依赖项更新
- 5
版本管理策略(concept)
- 6
自动化依赖项更新
- 7
利用生成器和模板替代文档
- 8
RubyGems 和 Railties 可以分发配置
- 9
测验:可持续流程与工作流
谨慎管理所需的 JavaScript
- 1
对于基本交互,拥抱原生 JavaScript
- 2
谨慎选择一个框架
- 3
确保当 JavaScript 出现问题时系统测试失败
操作
- 1
为什么可观测性至关重要
- 2
监控业务成果
- 3
日志记录功能强大
- 4
在所有日志中包含请求 ID
- 5
记录某事物是什么以及它来自哪里
- 6
处理未捕获的异常
- 7
性能度量
- 8
管理密钥、密码和凭证
- 9
测验:操作
视图测试
- 1
理解测试的价值与成本
- 2
使用 :rack_test 来处理非 JavaScript 用户流程
- 3
最初针对默认的标记和内容进行测试
- 4
培养明确的诊断工具以调试测试失败
- 5
伪造后端以让系统测试通过
- 6
使用 data-testid 属性来增强测试的稳定性
- 7
使用真实浏览器测试 JavaScript 交互
- 8
编写一个基于浏览器的系统测试用例
- 9
测验:测试视图
结论
- 1
最后的总结
模型 I
- 1
Active Record 用于数据库访问
- 2
创建一些示例 Active Record 模型(concept)
- 3
使用 Active Record 的 DSL 建模数据库
- 4
使用类方法进行数据库操作
- 5
实例方法应实现数据库中的领域概念
- 6
Active Model 用于资源建模
- 7
测验:模型 I
附录
- 1
软件版本与示例代码
- 2
本地开发环境中的 Docker 配置
- 3
单体架构、微服务与共享数据库
数据库
- 1
逻辑数据模型和物理数据模型
- 2
创建一个逻辑模型以达成共识
- 3
规划物理模型以确保正确性
- 4
使用 SQL 模式
- 5
规划物理模型
- 6
创建正确的迁移
- 7
创建迁移文件和辅助脚本
- 8
迭代编写迁移代码以创建正确的数据库结构
- 9
编写数据库约束的测试
- 10
测验:数据库
Certificate of Completion
Showcase your accomplishment by sharing your certificate of completion.
Course Author:Anonymous User