许式伟的架构课
许式伟
七牛云CEO
立即订阅
21081 人已学习
课程目录
已完结 87 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师？
免费
基础平台篇 (19讲)
01 | 架构设计的宏观视角
02 | 大厦基石：无生有，有生万物
03 | 汇编：编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读：如何实现可自我迭代的计算机？
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备：交互的演进
11 | 多任务：进程、线程与协程
12 | 进程内协同：同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络：连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理：数字世界的守护
17 | 架构：需求分析 (上)
18 | 架构：需求分析 (下) · 实战案例
19 | 基础平台篇：回顾与总结
桌面开发篇 (14讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发：浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战（一）：怎么设计一个“画图”程序？
27 | 实战（二）：怎么设计一个“画图”程序？
28 | 实战（三）：怎么设计一个“画图”程序？
29 | 实战（四）：怎么设计一个“画图”程序？
30 | 实战（五）：怎么设计一个“画图”程序？
31 | 辅助界面元素的架构设计
32 | 架构：系统的概要设计
33 | 桌面开发篇：回顾与总结
服务端开发篇 (13讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战（一）：“画图”程序后端实战
42 | 实战（二）：“画图”程序后端实战
43 | 实战（三）：“画图”程序后端实战
44 | 实战（四）：“画图”程序后端实战
45 | 架构：怎么做详细设计？
46 | 服务端开发篇：回顾与总结
服务治理篇 (10讲)
47 | 服务治理的宏观视角
48 | 事务与工程：什么是工程师思维？
49 | 发布、升级与版本管理
50 | 日志、监控与报警
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇：回顾与总结
架构思维篇 (11讲)
57 | 心性：架构师的修炼之道
58 | 如何判断架构设计的优劣？
59 | 少谈点框架，多谈点业务
60 | 架构分解：边界，不断重新审视边界
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
64 | 不断完善的架构范式
65 | 架构范式：文本处理
66 | 架构老化与重构
67 | 架构思维篇：回顾与总结
软件工程篇 (10讲)
68 | 软件工程的宏观视角
69 | 团队的共识管理
70 | 怎么写设计文档？
71 | 如何阅读别人的代码？
72 | 发布单元与版本管理
73 | 软件质量管理：单元测试、持续构建与发布
74 | 开源、云服务与外包管理
75 | 软件版本迭代的规划
76 | 软件工程的未来
77 | 软件工程篇：回顾与总结
不定期加餐 (8讲)
加餐 | 我看Facebook发币（上）：区块链、比特币与Libra币
加餐 | 我看Facebook发币（下）：深入浅出理解 Libra 币
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师，我需要成为“全才”吗？
加餐 | 如何做HTTP服务的测试？
加餐 | 怎么保障发布的效率与质量？
用户故事 | 站在更高的视角看架构
加餐 | 实战：“画图程序” 的整体架构
结束语 (1讲)
结束语 | 放下技术人的身段，用极限思维提升架构能力
免费
许式伟的架构课
登录|注册
73 | 软件质量管理：单元测试、持续构建与发布
许式伟 2020-01-14
你好，我是七牛云许式伟。
软件质量管理
今天我们聊聊软件工程中，我们在质量管理上其他方面的一些思考。事实上，软件质量管理横跨了整个软件工程完整的生命周期。
软件工程与传统工程非常不同。它快速变化，充满不确定性。不仅如此，一个软件工程往往是生命周期以数年甚至数十年计的工程。对于传统工程，我们往往把一个工程同时也称之为项目，项目工程。但软件工程不同，虽然我们平常也有项目的概念，但软件工程并不是一个项目，而是无数个项目。每个项目只是软件工程中的一个里程碑（Milestone）。
这些都决定了软件工程质量管理的思想与传统工程截然不同。在传统工程中，设计的工作往往占比极少，重复性的工作占据其生命周期的绝大部分时间。所以传统工程有极大的确定性。检查清单（Check List）很可能就已经可以很好地实现其工程质量的管理。
但对于软件工程来说，设计工作在整个工程中持续发生。哪怕是非设计工作，比如编码实现，也仍然依赖个体的创造力，同样存在较强的不确定性。显然，检查清单（Check List）完全无法满足软件工程的质量管理需要。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(5)
Aaron Cheung我们不把推广单元测试看作是让大家去多做一件额外的事情，而是规范大家做单元测试的方法。 感觉知道的有单元测试的项目都没有四成……2020-01-14 3- Geek007相比单元测试，似乎code review在我司更难推动。code review需要人的投入，而且往往需要有经验的工程师，有经验的工程师有他们自己的开发任务，他们会把code review当成是额外的工作，动力不够，责任心也不够，code review的质量因而也不能控制。有时候迫于发布的压力，code review做的很粗糙。code review 必要么？许老师对这个问题有何看法？谢谢。
作者回复: code review 非常重要，我们不 code review 就没法合并 pull request。
2020-01-16 2 
leslie最近就碰到一个现状在“持续构建，持续发布“方面的问题：公司业务最近刚好进入了高速增长期，每次交付的功能很多且目前上传频率基本上已经是每天的业务的低谷-凌晨那一段时间；如何权衡这种现状？按照老师前面课程提及的方式只能是每次只上传核心/最重要的更新功能，不知道老师是否有更好的建议。谢谢老师的分享，期待老师后面章节的更新。，作者回复: 如果发布很频繁，需要在发布系统和架构上优化，保证发布出问题可以一键回滚，另外升级要做到不影响用户，这样发布随时都可以，而不是只能在业务低谷。
2020-01-14 1
Bachue Zhou大部分服务器项目或库项目一般都有单元测试，但涉及到图形化界面的项目可能就非常不乐观了，纯计算的代码太少也够简单不需要做测试，涉及到 UI 交互的代码量很大却不知道如何测试。最后还是要靠手测。作者回复: ui测试的确复杂很多，但也不是不可能
2020-01-21
我在你的视线里持续构建和持续发布还有一种小步快跑的感觉。但是不是会影响客户体验。作者回复: 是的
2020-01-14 2
收起评论