程序员应该重视版本控制
作者: dkvirus 发表于: 2018-06-25 15:41:00 最近更新: 2018-08-02 19:52:23

起初,我不太理解 版本 在程序开发中起到怎样的作用。直到上周末与一个朋友聊天时,他的开发工具 Webstorm 突然罢工,需要激活,我将之前我的激活方式告诉了他,但他回应激活失败,询问之下才知,他的 Webstorm 使用的是 2016.1 版本,而我给他的激活方式适用 2017.2 版本,我问他为什么不升级工具,他回答只要能用不就成了,干嘛要升级?我一时语塞,不知该如何回答他。回过头我细想了一下,觉得还是有必要升级的,本文主要介绍一下几点。

  • 为什么要升级?
  • 版本升级规范?
  • 那么多程序,那么多版本,如何记忆?

一、为什么要升级?

1.1 开源社区与 Issue

之前做过一个项目,当时使用 bootstrap-fileupload 组件处理文件上传,发现中文显示总是乱码。当时脑子里有个思维定式:官方的东西怎么可能会出错呢,肯定是我自己哪里写的有问题?去官方文档将所有属性都检查了一遍,网上也搜了下问题都没能找到答案。最后在源码里 debugger 一步步找问题,发现是由于 windows 上记事本的编码为 ‘ANSI’,而 bootstrap-fileupload 设置中文编码 ‘gbk’ 二者并不匹配导致,修改之后就恢复正常了。我想将这个 Bug 提给官方人员,但不知道怎么联系他们,我甚至在搜索引擎里搜索 bootstrap-fileupload 的官方邮箱。(现在想想有点傻乎乎的)

今年 6 月份接触 github,第一次感受到 开源社区 的含义:dva 是一个基于 React 的前端框架,公司项目选型时决定用它,技术总监便给了我它的 github 地址 让我去读一读它的文档。

在这里,我才晓得原来 dva 的源码竟然是触手可及的,而不再是生硬的 dva.min.js 文件。如果发现 Bug,可以去 Issue 库里提问,官方人员会验证之后并解决的。在 Issue 库里你不仅可以提出 Bug,还可以帮忙解决 Bug 然后将修改的内容 Pull Request 给官方人员。Issue 库还有个巨大的好处就是遇到问题去里面找,基本上你遇到的问题其它人都有遇到并解决过,这效率比在百度搜索问题准确性不知高了多少倍。

Dva github 页面

现在,比如在 Bootstrap-fileupload@1.0.0 里发现了一个 Bug,在开源社区里给官方提了一个 Issue,官方修复后并发布了新版本 Bootstrap-fileupload@1.0.1,只需要下载最新的版本即可愉快的使用,而不是去修改源码。

注: 并不是所有项目都是开源的,开源的项目也并不一定就把代码放在 Github 上,我找了下 jquery 社区是在 Github 上的,Bootstrao-fileupload 好像并没找到。

1.2 软件需要持续升级

软件的每一次升级,或修复之前功能 Bug,或新增新的功能,或在优化了性能,让程序跑的更快。啥?你还不想更新?当别人的微信升级后可以同时发送多张照片,你没升级的版本只能一张张地发送照片。当别人家的 Webstorm 更新之后启动只花了 5 s,你使用老的版本启动却花了 10 s。你还有什么理由不更新。

程序或软件并不是一次性的东西,开发完成就放那不管不顾了。这是个持续改进,持续完善的过程。版本就是软件更新的历史节点。一个好的程序会指定良好的版本规则,定期发布新版本,做一些功能上的改进,并将做了哪些修改告诉明确的告知客户。

手机软件更新

二、版本升级规范?

对于客户来说,不需要关心软件是怎么升级的,他们只关心软件更新了哪些内容,好不好用。

对于开发人员来说,我们制定版本号,有条不紊的定期升级。如果制作版本号的规则混乱,在管理版本的时候将会及其痛苦。所以,我们遵循着相关规范。

2.1 版本号

在上图中,可以看到 6.4.7 -> 6.4.8,这是将头条@6.4.7 版本升级到 @6.4.8 版本。规定版本号由三部分组成,按照顺序分别为主版本号.次级版本号.修订号

  • 修订号何时变化? 当修复一两个 Bug,改动很小时,将修订号 +1;

  • 次级版本号何时变化? 当新增一些功能,如头条新增一个栏目时,将次级版本号 +1,修订号置 0,就变成了 6.5.0,此时的改动不容忽视,但也不是很大;

  • 主版本号何时改变? 当做了很大的改变,如:变动了头条栏目的布局,用户再登录进去时操作体验完全改变时修改主版本号+1,此时次级版本号和修订号置0,变成了 7.0.0。

在开发人员开发一个新的程序时,建议命名第一个版本号为 0.1.0 ,以后按照规则依次递增,第一个 可用的发行版本 将主版本号升级为 1.0.0

2.2 版本阶段

头条新闻对于用户来说叫做软件,对于开发人员来说叫做程序,以下统称程序。

光是看版本号,可能对于程序处于什么状态并不能完全掌握,此时还需附带版本阶段相关英文单词来附加说明,格式:版本号-版本阶段英文单字

如看到 `dva@1.3.0-beta就知道 dva 的版本号为1.3.0`,当前处于 公测阶段,本身还存在 Bug,给部分用户体验,用户提出 Bug 并全部修复完成后才能正式发布。

版本号附带英文字母

程序版本阶段对应英文如下,大家遵守规范,看到英文单词就这个这个版本当前处于什么阶段。

  • alpha 内测阶段:该阶段主要实现程序功能,通常只在内部开发人员之间交流,该阶段存在 Bug 较多,待完善。

  • beta 公测阶段:该阶段较 alpha 来说修复不少 Bug,但仍存在隐藏问题。由于内部人手有限,先发布该阶段版本让广大发烧友用户们先做体验,发现问题,解决问题,不断完善。比较熟悉的就如小米发烧友就会很积极的测试功能。

  • rc 候选阶段:该阶段基本解决完 beta 阶段的所有 Bug,算是比较完善的一个版本了,可以发布给所有用户使用。该阶段与 release 阶段相差无几,那为什么不直接忽略此阶段版本呢?

    我猜测应该还是考虑一个稳妥的问题。比如:固定 20 号发布一个 release 版本,15 号的时候就已经开发完成并测试通过进入 rc 候选阶段,如果剩下五天不出叉子,那么这个 rc 版本就是后面的 release 版本,万一运气不好,又测出 Bug,那么就修改发布 rc2 版本作为新的候选版本。

  • release 正式发行版:啦啦啦啦,正式上线版本,给广大用户使用,此时要是再有明显 Bug 是及其影响用户体验,损失用户量的,该阶段可以算是完全体了。

当然,对于用于来说,频繁的更新版本也是一件很痛苦的事。比如我们使用 node,我们就是用户,node 官方要是隔三差五就更新一次版本,我们在项目中也需要被迫更新 node 版本,这是难以忍受的。于是,node 推出里两个版本阶段可供选择。

  • LTS(Long-Term Support)长期支持版本:该阶段相当于上面的 release 版本,基本没啥大 Bug,可供 node 开发人员长期使用,大概 18 个月才会有一次大更新,也就是说安装 LTS 版本之后就不会频繁更新。
  • Current 当前阶段:在 LTS 阶段,如果 node 再添加新的特性或者修复 Bug 怎么办?统统放到 Current 阶段里,该阶段并不稳定,api 经常会变,对于开发人员来说,并不推荐使用。等到 18 个月会将该阶段升级为 LTS 稳定阶段。

Node 官方主页

三、那么多程序,那么多版本,如何记忆?

在前端开发中,使用的每个前端框架(Vue or Angular or React or Dva…..)、UI 框架都有自己的版本控制,如何去知道什么框架升级到什么版本有什么新的功能呢?

3.1 开源社区

市面上框架那么多,你的项目肯定不是每种都用的吧,着重关注项目中使用到的程序版本问题。如我的项目中使用 dvaant-designroadhog微信小程序,还有一些开源项目,这些项目并不会每天都有更新,官方勤快一点的每周固定更新一次,懒一点的半个月,一个月左右更新一次。所以我一般每周一去开源社区逛一逛,看看最新动态,社区里会有更新日志,没有日志的可以去 Issue 库里看看又出现了什么新的问题。

3.2 开源中国网站

开源中国社区首页有一个板块专门介绍软件更新资讯,里面有更新的软件版本,更新内容,并且涉及面极广。每天逛一逛再也不用担心拉下什么重要更新事项了。

开源社区软件更新板块

首页
友链
归档
dkvirus
动态
RSS