最近老看到聚勒的新闻，一会儿说他厉害，身体壮得跟堵墙似的，一会儿又说他体重超标，态度有问题。这让我想起了我之前捣鼓一个东西时候遇到的情况，真有点像。
那会儿我接手一个小项目，里面有个核心模块，别人留下来的。一开始看，这模块真牛，处理核心数据那叫一个稳，基本上没出过错，感觉特别可靠，就像聚勒站在后防线上，看着就让人放心，觉得能扛住事儿。
刚开始的印象
刚接触的时候，我就觉得捡到宝了。这模块功能强大，文档也还算有（虽然不多），跑起来处理那块特定任务，效率也还行。心里想着，这下省事了，核心部分这么稳，我只要在外围修修补补，加点新功能就行了。
- 优点： 处理核心任务稳定、准确，不容易出错。
- 感觉： 就像有个靠谱的大个子在后面顶着。
后来发现的问题
可时间一长，问题就来了。这模块确实稳，但也确实笨重。想稍微改动一下，或者让它跟新加的功能互动一下，那叫一个费劲。牵一发动全身，改一点代码，可能其他地方就莫名其妙报错了，调试起来特别痛苦。
而且它对环境要求还挺苛刻，稍微有点变化就闹脾气。最要命的是，它的性能瓶颈也慢慢显现出来了，数据量稍微一大，或者并发请求一多，速度就明显跟不上，拖慢整个项目的节奏。这感觉就像聚勒，防守是硬朗，但万一对方打快速反击，他就有点追不上了，转身慢的问题暴露无遗。
那段时间，团队里为这模块的事儿没少开会讨论。有人说干脆换掉，长痛不如短痛；有人说还是接着用，毕竟重写风险太大，时间也不够。我们尝试了各种优化方法，给它打补丁，想绕开它的缺点，但效果都不太理想。真是头疼。
的折腾
怎么弄的？我们没彻底换掉它，主要是没那个时间和资源去重写一个同样稳定的核心。但是我们也没完全放任不管。
我们是这么干的：
- 把新功能和这个老模块尽可能隔离开，减少它们之间的直接调用和依赖。
- 针对它处理慢的问题，加了缓存，异步处理这些常见手段，尽量减轻它的压力。
- 把它负责的范围进一步缩小，就让它干最核心、最不能出错的那一小块活儿。
等于说，承认了它的优点，也接受了它的缺点，然后想办法扬长避短，尽量把它放在一个它能发挥最大价值，同时又不容易暴露短板的位置上。就像用聚勒，你知道他转身慢，那就尽量别让他大范围回追，多安排协防保护，利用好他的正面防守和身体对抗优势。
所以说，有时候评价一个东西，或者一个人，不能光看一方面。聚勒这种，有明显的强项，也有明显的短板，关键看你怎么用，放在什么体系里。咱们自己做东西也是一样，遇到这种“聚勒式”的模块或者工具，别急着一棒子打死，也别盲目迷信，好好分析清楚，找到最合适的用法，可能比推倒重来更实际。
还没有评论，来说两句吧...