最近瞎琢磨，想起之前碰到的一个挺头疼的事儿。也不是啥大事，但就卡在那儿，感觉跟个“土皇帝”似的，我们内部就半开玩笑地管它叫“raj”，就是那种老规矩、老体系，占着地方，谁也动不它。
开始接触这个“raj”
刚开始接手这摊子事的时候，我是真没把它放眼里。想着不就是个老旧的流程嘛稍微理理顺顺，优化一下不就完？结果一上手就傻眼。这玩意儿牵扯的东西太多，东边连着A，西边接着B，中间还夹着好几个不知道谁留下来的补丁。
我先是试着按照标准的法子去走，提交申请、找负责人沟通。负责人倒是挺客气，就是一问三不知，或者就是说“一直都这样，没啥问题”。我心里那个急，这明明效率低得要死，怎么就没问题。
硬着头皮上
没办法，求人不如求己。我决定自己先摸索摸索。这过程可真是费老劲。
- 第一步，翻文档。 我把能找到的相关资料，不管是电子版的还是纸质的，犄角旮旯的全翻出来。很多都过时，信息也不全，看得头昏眼花。
- 第二步，找老人。 我去请教几个老同事，他们倒是知道点情况，但也说得模棱两可，大概意思就是这东西历史悠久，能不动就不动。
- 第三步，自己试。 光听光看没用，还得自己动手试试。我找个没人的时间段，小心翼翼地测试几个环节，想看看能不能找到突破口。每次测试都提心吊胆，生怕搞出什么大乱子。
找到点门路
就这么折腾差不多两个礼拜，总算让我摸到点规律。原来这个“raj”的核心逻辑并不复杂，复杂的是它外面包一层又一层的“补丁”和临时的解决方案。这些东西互相干扰，才让整个流程看起来那么臃肿和低效。
我的想法是，能不能绕开那些补丁，直接跟核心打交道？
说干就干。我又花两天时间，专门研究怎么能精准地对接那个核心部分，把那些干扰项都屏蔽掉。我画个简单的流程图，标出哪些是必须走的，哪些是可以绕开的“旁路”。
动手改造和结果
接下来就是动手实践。我先是做个小范围的测试方案，跟领导报备一下，说我想试试能不能提高点效率。领导估计也是被这老东西烦透，居然很爽快地同意我小范围试试。
我小心翼翼地按照自己设计的路线走一遍，你猜怎么着？成！ 速度确实快不少，而且没出啥岔子。然后我就把这个小经验赶紧记下来，整理成一个简单的操作步骤。
后来慢慢地，用我这法子的人也多起来。虽然那个老的“raj”体系还在那儿，但我们起码找到一个能更快更顺畅地跟它打交道的方法。也算没白折腾。
这事儿让我明白，有时候碰到这种根深蒂固的老规矩、老家伙（raj），硬碰硬可能不行，但动动脑子，找找侧面的路子，说不定就能绕过去，或者至少能让它碍事少一点。实践出真知，这话不假。
还没有评论，来说两句吧...