间接依赖各带一份版本，画清依赖树才好谈怎么收敛
明明只引了一个库，打包出来的目录里却躺着同一个底层组件的两份，一份新一份旧。查的人翻了半天配置也没找出是谁多引的，后来才看清：两个上层库各自按自己的节奏往前走，各自捎带了一份不同版本的底层件。一、先把谁引了谁画成一张树
从自己写的这层往下一层层展开，每一条线上标清是哪个库、要的是哪个版本范围。画出来比在配置文件里一行行猜快得多，哪个节点分了叉、哪两处指向了同一个名字，一眼就能认出来。
树上也标出哪些是直接写的、哪些是别人捎带来的。直接写的自己能改，捎带来的得先找它上头那位商量。分不清这两类，就容易对着一个自己根本没写过的版本号较劲，改半天也没落到根上。台账里谁引了谁，由哪个人负责填要事先说定，不然谁都觉得顺手能补，末了谁也没补，那一栏空着比填错还难查。
二、同一名字的两份先认出差别
两份版本摆在一起，别急着删掉一份，先看它们各自被谁用着、用到了哪几处行为。有的只是名字相同，走的其实是不相干的两条路；有的新版悄悄改了返回的顺序，删错一份，某条冷门路径当时看不出来，过几天才冒头。
把差别记成几行，哪一处行为变了、哪个上层库正好踩在这一处。记下来了，后面跟维护那边说的时候也有依据，不用只说一句好像不太对，对方问细了答不上来。新带进来的东西登记在哪一页，给个固定位置，随手夹在讨论记录里的那几行，过两个月连写的人自己都认不出。
三、收敛要挑一处统一的版本
认完差别再定往哪一版并，通常挑几个上层库都能接受的那一份。定完别指望一次改完，先让引得窄的那两处跟上来，跑稳了再动引得广的，一层层往里收。
定的时候顺带看一眼这版还在不在维护。挑了个快没人管的新版，眼前是齐了，过些日子再出一个新问题，想找人问都找不着；宁可选稍旧一点但一直有人跟的那版，后面省的心更多。来源那几处分别由谁核，列成一小张贴在值班处，半夜要补一份清单，不必挨个把人从群里问醒。
四、把范围写清楚别留活口
有些库写依赖时图省事，版本范围放得很宽，构建时取到哪一版全看当天仓库里有什么。同一份代码，周一和周五打出来的东西可能就不一样，查问题的时候连该照着哪一份复现都说不清。
范围收紧到能确定下来的那一档，再由锁定文件把实际取到的版本记死。改范围这件事要有人复核，别谁顺手一改就过去；复核的人看一眼树上有没有被牵动，比事后等构建报错划算。每季度挑一天把台账和仓库里的实况对一遍，差在哪一行当场标出来，拖到下次再对，中间改过几回就说不清了。
五、每回收敛都留一份前后对照
动之前把树存一份，动之后再存一份，两份并排看：少了哪条分叉、哪几个节点换了版本、有没有冒出新的捎带关系。光看构建通过不算数，树没变干净，下次照样会攒出两份来。
对照里也记下这回没能并掉的那一处，写清卡在哪儿。有的是上层库还没跟上，有的是两处行为确实没法共用。留着这一笔，下回再谈的时候直接从这儿接，不用把整棵树重新翻一遍。同一名字的两份东西归谁判，定一个人就行，两个人各判一半，碰上要合的时候还得先花工夫把两种说法并到一起。
六、定个由头定期再翻一次
依赖这东西不会自己保持整齐，上层库隔一阵就会捎点新东西进来。定个由头，比如每回大版本变动之后，或者每季度头一周，把树重新展开看一眼，趁分叉还小的时候顺手收掉。
翻的时候不必大动，重点看有没有新冒出的同名两份、有没有哪个范围又被放宽了。小口子当下补，几乎不费事；攒到打包目录里躺了五六份，再想理清就得专门腾出几天。台账改动留个由头，一句话写清是谁提的、为什么改，隔一阵回看，比只记一个新数字更容易想起当时的难处。
两份底层件并排躺着，很少是谁写错了配置，多半是几处上层库各自往前走，没人把整棵树摊开看过。画树、认差别、挑版本、收范围、留对照、定期翻，六步做下来，目录自然就清爽了；缺了画树这一步，后面五步都不知道该往哪儿使劲。 讨论氛围很好，大家都在理性交流，这样的论坛环境太舒服了。 楼主考虑得很全面，不仅讲了方法，还提到了注意事项，非常贴心。 对新手特别友好，解释得很细致，就算零基础也能看懂大半。 内容真实不做作，没有多余套路，都是实实在在的经验之谈。 讲得很透彻，把复杂的问题简单化，理解起来轻松了很多。 看完之后深有感触，有些话真的说到心坎里了，很有共鸣。
页:
[1]