许式伟的架构课
许式伟
七牛云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讲)
结束语 | 放下技术人的身段,用极限思维提升架构能力
免费
许式伟的架构课
登录|注册

75 | 软件版本迭代的规划

许式伟 2020-01-21
你好,我是七牛云许式伟。
到今天为止,我们专栏的话题主要集中在软件工程的质量与效率上。我们在专栏的开篇中就已经明确:
从根本目标来说,软件架构师要对软件工程的执行结果负责,这包括:按时按质进行软件的迭代和发布、敏捷地响应需求变更、防范软件质量风险(避免发生软件质量事故)、降低迭代维护成本。
但是今天,我们将探讨一个更高维的话题:软件版本迭代的规划。后续我们简称为 “版本规划”。简单说,就是下一步的重点应该放在哪里,到底哪些东西应该先做,哪些东西应该放到后面做。
这是一个极其关键的话题。它可以影响到一个业务的成败,一个企业的生死存亡。方向正确,并不代表能够走到最后,执行路径和方向同等重要。
那么,版本规划的套路是什么?
探讨这个问题前,我想先看一个实际的案例。这个案例大家很熟悉:Go 语言的版本迭代。
我们从 Go 语言的演进,一起来看看 Go 团队是如何做软件版本迭代规划的。这有点长,但是细致地琢磨对我们理解版本规划背后的逻辑是极其有益的。

Go 版本的演进历史

Go 语言的版本迭代有明确的周期,大体是每半年发布一个版本。
Go 1.0 发布于 2012 年 3 月,详细 ReleaseNote 见 https://tip.golang.org/doc/go1。它是 Go 语言发展的一个里程碑。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • Charles
    许老师,Go的这些版本迭代历史,是在1.0发布之初就定了路线图,跟着路线图在迭代,所以可以做到战略定力?

    是不是可以理解为架构设计上的成功,就会顺其自然有比较好的迭代节奏?

    作者回复: 大部分我们理解的架构设计,是术,是怎么把事情做正确。版本规划其实也是架构设计,是道,是做正确的事情。

    2020-01-21
    1
  • leslie
    其实文章中提到了一个很关键的问题:"满足需求的同时如何简化或不增加用户操作的复杂度“。这些年见过太多的为了满足客户需求而明显增加了复杂度的案例,做技术的同时如何去思考产品;稳定性且渐进的满足需求是自己在考虑的问题。
           经常会碰到产品或营销团队说我看到XXX公司或者说我想到了XXX主意非常好,可是是否真的那么急着要上,用户体验度如何呢?不能在成熟的产品中去不断的试错,而应当是一种借鉴的过程。Go语言的版本迭代,对我们而言其实是一个很好的学习与反思的过程。
    2020-02-01
  • xiaobang
    用户使用姿势具体只什么?

    作者回复: 就是用户如何使用我们的产品,更加专业一点的说法是 “产品设计的规格”。

    2020-01-26
  • Jxin
    放到业务开发。

    (打基础)
    1. 0.x-1.0重心应该放在核心域的开发,保证其健全,简洁,灵活。

    (产出业务价值)
    2.待核心域基本稳定后,再发布1.0-100.0的版本,做支撑域和通用域的开发。
    3.各业务域间应该是可组合可插拔,没有强依赖的平级独立的立场。(也应具备旁路分支独立开发的灵活性)
    4.在1.0-100.0的支撑业务开发时,每次只聚焦当下最重要的业务域开发(排好优先级)。
    2020-01-21
  • Jeff.Smile
    对go不是很了解,但许老师的视角很高!从一门编程语言的版本迭代去反映正确的迭代思路。赞!
    2020-01-21
  • #^_^#
    “承诺版本一直向后兼容”是怎么做到的,“只读”思想吗?

    作者回复: 也需要时间打磨,go开源后两年多才发布Go 1.0,也是出于这方面的原因

    2020-01-21
  • Aaron Cheung
    这个版本最重要的新功能是 Go modules。前面我们说 Go 1.5 版本引入 vendor 机制以解决模块的版本管理问题,但是不太成功。这是 Go 团队决定推翻重来引入 module 机制的原因。 我个人比较好奇golang团队规模,从0到1到100的过程的确比较漫长

    作者回复: 还真没了解过,不过社区贡献者的力量也是不可小觑的

    2020-01-21
收起评论
7
返回
顶部