项目有时需要加些新的功能,然后,直接在网上找到满足的库。但是,这个库需要升级框架的版本,例如:vue @2.3.4 -> 2.4.3.
我是比较赞成升版本的,因为可以修复些框架的 bugs,还能紧跟 vue 的版本。
但是,有些同事——测试和 PM 是不太愿意的。因为,他们觉得升级会引入风险,有可能导致更多 bugs 出现。而且,这个框架版本一直在用没出现问题,所以最好不要升。他们是比较保守希望减少风险引入的态度的。
其实,这些情况我也能理解。所以,我是推荐在不发包的那段时间升级。如果离发包前只剩两周,我也是不推荐升级的。
如果是你们,你们会怎样处理?如何说服同事升级版本呢?
其实,看看整个IT业界,就算制定了major.minor.patch这种版本规则。而且,这些库、框架都有自己的测试用例,保证发布后不会出现兼容问题(当然测试用例的确没法覆盖所有情况。但是,已经是“最大”限度的保障了)。
但是,在一个项目里(非个人),我们都没法接受那怕一个patch版本号的变化。因为习惯了长期使用的某个版本后,对于版本号升级的“恐惧”是非常大的,因为各种条样的原因。所以,这个版本号的约定是不是单单只是一个数字。
因为,对于公司项目里,这个数字只有第一次才能用到。然后,就“永远”停留在那里了(如果没办法自己解决)
1
mcluyu 2019-10-17 11:36:28 +08:00
请仔细阅读《布道之道》
|
2
Necfol 2019-10-17 11:36:36 +08:00
屁股决定脑袋,站在项目工程角度,你是错的
|
4
renmu 2019-10-17 11:42:57 +08:00 via Android
一旦升级出了奇怪的 bug,肯定都是你背锅了
|
5
Raymon111111 2019-10-17 11:44:56 +08:00 6
1. 指出升级带来的好处 (数据支持)
2. 指出不升级的坏处 3. 升级版本带来的变化, 新版本的坑都有哪些 4. 升级所带来的风险评估, 可能出现的问题, 应对手段 (这其中包括怎么做覆盖全面的测试) 5. 团队内有没有和你们业务规模相当组已经升了这个新版本 (让别人先踩坑, 减少不确定性) 欢迎大家补充, 这个列表能理全是工程师的重要素质之一 |
6
littleylv 2019-10-17 11:45:43 +08:00
说实话,如果已经稳定运行了一定时间的项目,我是不敢升级的
|
7
yanqing07 OP @renmu 这个肯定的了。
但是,一直在一个版本。有时可能会出现,新功能只能自己开发,开发周期加长这些问题了。 然后,还有个问题就是版本不更新,当出现某些框架的 bug, 团队无法避免。但是,其实这个 bug 在某个版本修复了,例如:要从 2.3.4 -> 2.8.0 这样的话版本更新跨度更大,还不如定期升级一步步紧上版本安全中 |
8
sambawy 2019-10-17 11:54:08 +08:00
一般情况下,除非当前版本遇到重大安全 BUG,否则不会升级
|
9
sadfQED2 2019-10-17 11:56:23 +08:00 via Android
闲得没事干?线上运行过一段时间的项目,我也不敢升级的
|
10
yanqing07 OP @Raymon111111 谢谢你提出这些要点。
看来 tech leader 有时不写代码是有原因,要把这些要点整理给出数据,所花时间不亚于开发新功能。 不过,我想大部分人还是比较保守,或者懒得做这些要点的调研。包括我~哈哈哈哈~ |
12
wakiki 2019-10-17 12:00:02 +08:00 via iPhone
就问一句,要是半夜线上因为这次升级出问题了,你负责处理么?你能不叫其他同事起床配合你么?
|
13
seki 2019-10-17 12:02:18 +08:00 1
你需要给人信心,比如有足够的单元测试和 e2e 测试 cover 了
|
14
sadfQED2 2019-10-17 12:43:43 +08:00 via Android
@yanqing07 自己玩的和线上项目不一样啊,我自己写玩具,所有框架全部最新,我自己系统都是用预览版,但是我在公司写项目的时候都是选稳定版
|
16
tabris17 2019-10-17 12:49:38 +08:00
你是嫌年底 KPI 不够么
|
17
est 2019-10-17 13:26:43 +08:00
你是嫌年底 KPI 不够么
|
18
hotcool100 2019-10-17 13:29:15 +08:00
你是年底太闲给自己争取加班么
|
19
reus 2019-10-17 14:12:44 +08:00 2
升有升的好,不升有不升的好
有时要升,有时不用升 所以很多软件都有一个叫 LTS 的东西,稍微保守但又不是死守不变的 不论新版旧版,bug 是肯定有的,何况新版可能有很多 bug 修掉了,所以怕新版有 bug 的,根本不是不升级的理由,旧版可能 bug 更多 不敢升级,根本原因是“背锅”文化,有时明知道是好的,但就是因为怕背锅,所以不做 明朝就是这样亡的,想迁都,又没人敢说,想讲和,又没人敢说,因为如果失败了,崇祯只会拿你背锅 结果什么都不做,坐着等死 |
20
Rwing 2019-10-17 14:18:04 +08:00
请仔细阅读《布道之道》
|
22
charlie21 2019-10-17 14:29:40 +08:00
引入一个新包能给测试带来多大工作量?诶
|
23
misaka19000 2019-10-17 14:32:43 +08:00 1
很简单,你就说“升级如果出了问题我全权负责”就可以了
|
24
longaiwp 2019-10-17 14:48:18 +08:00 1
很简单啊,你就说出了 Bug 全都算我的,加班都我来,那就可以了
|
25
akira 2019-10-17 14:50:08 +08:00
你们项目进度是你负责么,是的话 那肯定没问题啊
|
26
remarrexxar 2019-10-17 16:39:45 +08:00
框架升级肯定需要做完整的回归测试,如果项目大部分已完成或者已经上线这个工作量会不小。如果一开始就有很好的自动化测试脚本来覆盖的话能省很多事,做各种升级的时候能规避风险及时发现问题。
|
27
seki 2019-10-17 18:38:25 +08:00
没有测试那还是建议忍忍吧,vue 这一年反正也没啥特别大的更新
|
28
lbp0200 2019-10-17 18:41:42 +08:00
升级,升级后出了问题楼主来改,楼主出钱请客,楼主被扣工资,担负一切责任。
这样,你的同事就会升级了 |
29
learnshare 2019-10-17 18:45:31 +08:00
定期升级是保持代码可维护的必要工作,有完整的测试流程就比较容易升级
不需要说服谁,找领导下命令 |
30
newtype0092 2019-10-17 18:50:54 +08:00
你们升不升级这种大事是靠谁口才好谁说了算?
不是你们提建议然后能拍板的人拍板么? 要是你自己能拍板,你不用说服他们,安慰安慰就行了。 |
31
saltedFish666 2019-10-18 09:21:26 +08:00
我感觉你在挖坑
|
32
fallenjie 2019-10-18 15:28:17 +08:00
不做不错,少做少错,多做多错。
|
33
virus94 2019-10-18 17:13:48 +08:00
劝同事用 composer 都费劲
|