得，今天就来聊聊我实践中遇到的一个事儿，琢磨了好久，才明白过来到底“错误的是”
是这么个情况。前段时间，我接手了一个有点年头的系统维护工作。你想，老系统嘛文档不全，代码风格也五花八门，交接的人也说得不清不楚。当时我就想着，这玩意儿得先摸透了才能动，不然指不定捅出什么篓子。
我一开始的策略就是：稳。先别急着改，我先看。我花了差不多两个礼拜，天天就对着那堆代码瞅，试图把每个犄角旮旯的逻辑都理顺。我寻思着，只要我把所有东西都搞明白了，到时候再改，肯定万无一失，效率最高。
我的实践过程
具体我是怎么做的？
- 第一步： 我把能找到的所有文档，不管是零散的笔记还是过期的说明，全翻出来看了一遍。
- 第二步： 我开始一行一行地读代码，遇到不明白的就打断点调试，看变量怎么走的，函数调用关系是啥样的。
- 第三步： 我还画了不少流程图，想把主要的业务逻辑可视化出来，方便自己理解。
- 第四步： 碰到实在搞不懂的地方，就去问组里其他人，虽然他们也大多一知半解，但多少能提供点线索。
就这样，我感觉自己像个侦探似的，在那堆故纸堆里刨线索。每天都弄到挺晚，觉得自己特认真，特负责。心里还挺美，觉得这么搞下去，肯定能把这系统拿捏得死死的。
结果？俩礼拜过去了，感觉好像是懂了不少细节，但是新的修改需求一来，我发现自己还是束手束脚。为因为我抠的那些细节，很多跟新需求关系不大，或者说，在我还没完全“摸透”整个系统之前，新的问题又冒出来了。
更要命的是，当我尝试去做第一个小修改的时候，发现因为看得太细，反而被太多可能性给绕进去了。改动 A 地方，担心影响 B；动了 C 模块，又怕牵连 D。思前想后，一个小功能改了好几天，效率低得吓人。
的领悟
这时候我才开始反思，我之前那套“完全摸透再动手”的思路，是不是有点问题？
后来跟老同事聊天，他一句话点醒了我。他说：“老系统就这样，你不可能完全搞懂它，也没必要。重要的是先抓住主干，知道改哪里大概会影响哪些地方，然后小步快跑，边改边测边学。”
我一琢磨，好像真是这么回事！错误的是我一开始那种追求“绝对掌控”、“完全理解”的想法。尤其是对这种复杂又缺乏文档的老系统，这种想法本身就不现实，而且效率极低。
我太专注于“不出错”，反而忘了目标是“解决问题”。我把大部分精力耗在了无休止的“学习”和“理解”上，而不是在实践中去“验证”和“修正”。那种想把所有东西都弄得清清楚楚、明明白白再行动的执念，在这个场景下，恰恰是最大的错误。
后来我调整了策略，开始针对具体需求，快速定位到相关模块，做一个小修改，然后立刻进行充分的测试。遇到问题，再深入研究那一块儿。这样一来，虽然还是会碰到预料之外的麻烦，但至少项目能往前推了，我学习的速度反而更快了，因为学到的都是马上要用到的知识。
有时候我们觉得自己在认真做事，但可能从一开始努力的方向或者那个执念，本身就是“错误”的。认清这一点，比傻乎乎地埋头苦干重要多了。
还没有评论，来说两句吧...