这是一个创建于 1855 天前的主题，其中的信息可能已经有所发展或是发生改变。
项目有时需要加些新的功能，然后，直接在网上找到满足的库。但是，这个库需要升级框架的版本，例如:vue @2.3.4 -> 2.4.3.
我是比较赞成升版本的，因为可以修复些框架的 bugs,还能紧跟 vue 的版本。
但是，有些同事——测试和 PM 是不太愿意的。因为，他们觉得升级会引入风险，有可能导致更多 bugs 出现。而且，这个框架版本一直在用没出现问题，所以最好不要升。他们是比较保守希望减少风险引入的态度的。
其实，这些情况我也能理解。所以，我是推荐在不发包的那段时间升级。如果离发包前只剩两周，我也是不推荐升级的。
如果是你们，你们会怎样处理？如何说服同事升级版本呢？
第 1 条附言 · 2019-10-18 10:12:24 +08:00
其实，看看整个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 1
@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 都费劲
|
Select Language