罪后的荆棘值不值得去看？看完这篇全面评测你就明白了！

最近搞了个事儿，自己心里头就管它叫‘罪后的荆棘’。不是啥光彩的事，就是自己挖了个坑，然后费老鼻子劲往外爬的过程，顺便记录一下，也算给自己提个醒。

事情得从头说起。大概几个月前，接了个朋友介绍的活儿，帮人优化个小程序。当时也就是简单聊了聊，看了看演示，觉得功能不复杂，界面也挺简单，想着应该花不了多少工夫。当时就是有点自信过头，也没仔细去看里面的代码，觉得凭经验应该能搞定，就一口答应下来了，价钱也说得挺死的。

这就算是种下“罪”根了。等真把东西拿到手，开始动手的时候，我才发现问题大了。那代码写得，简直没法看。命名乱七八糟，逻辑绕来绕去，好多地方都是硬编码写死的。别说优化了，光是看懂都费劲。

开始拔刺儿

没办法，自己揽的活儿，硬着头皮也得上。这就开始了漫长的“拔荆棘”过程。

• 第一步：理顺逻辑。我花了差不多三天时间，啥也没干，就是对着那堆代码，一行一行地啃。一边看，一边画流程图，把各个功能模块的关系先大致搞清楚。那感觉，就像在盘一堆乱麻，得特别有耐心。
• 第二步：重构核心部分。发现原来的核心逻辑有好几个地方效率特别低，而且耦合太严重，动一个地方，其他地方准出问题。没办法，只能动手重写。这部分最花时间，差不多搞了一个多星期。一边写新的，还得一边兼容旧的接口，怕影响其他还没动的部分。
• 第三步：逐步替换和测试。写完一部分，就替换掉旧的那块，然后就是反复测试。点点点，看看有没有新bug出来，看看原来的功能还能不能用。这个过程特别枯燥，但也最不能省。有时候为了测一个小功能，得把整个流程跑好几遍。



• 第四步：处理遗留问题。等核心的都替换完了，还得回头去处理那些犄角旮旯的小问题。比如一些写死的配置、一些没考虑到的边界情况。这些就是那些小刺儿，不致命，但扎手。

整个过程，真的就是一身汗一身泥。有好几次我都想撂挑子不干了。尤其是熬夜调试，改了个bug，又出来仨新bug的时候，那心情，别提多烦躁了。就感觉自己陷在一片荆棘丛里，怎么都挣脱不出来。

这让我想起以前刚上班那会儿，有