如何走出问题的迷宫

  在我们生活和工作中，或多或少都会遇到一些非常“繁复”的事，基于我们自身认知的情况下没有办法一下就处理完毕。可能是筹划一个完美的 party；可能是需要做一个面面俱到的旅行计划；也有可能和我一样，需要在工作中去解决一个”复杂”的问题。
  如果你用敲钉子的办法去解决他们，那你很有可能会走入问题的迷宫。请跟着我一起看看，到底是什么样的方法让我成功走出重构了这个“复杂”业务的迷宫。

Maze

问题来了

  那个时候我正在参与一个大型项目的第二阶段。项目中核心业务的代码实现逻辑与我们和客户确认的业务模型有一定的出入。需要将这个不匹配的模块进行重构成和实际业务模型一样。项目上的后端开发人员中，只有我一个人是拥有项目第一阶段的所有上下文。这时，我自告奋勇的去接受了这个重构任务。

敲不完的钉子

  以我以往的经验来看，这不过是重构的时间稍长而已。一开始，我就想象着可以挥舞钉锤那样去锤下那一个个翘起的钉子一样把重构就能完成了。
  但是事情接下来的发展出乎了我的意料。钉子们被敲了进去，另外一边刚敲下去的钉子又冒了出来，甚至出现了很多新的钉子。就这样按下葫芦浮起瓢，我埋着头在被改的乱七八糟的源码里面晕晕乎乎的搞了好几天，重构没有一点进展。这时候的心态也和这块需要钉钉子的板子一样，一片狼藉了。

Hammer

走出迷宫

  因为这几天我都在做着同一件事，但是没有任何的内容产出。于是找到了 TL 沟通。我告诉他：“我先找到一个点去改，结果发现改了这个地方导致其他地方也需要改，然后我就这样不停的改啊改啊，不知道改了多少次，也不知道还要改多少才能做完。”他听完以后告诉我：“你这样去做比较简单的事是没有问题的，因为事情很简单，每个改动的边界是可以感知和控制的。但用这种方法做看不到边界，无法控制每次修改影响范围的事。结果就会是做了很多，还不知道对错，最后陷入进退两难的境地。好在我们其实是有方法去解决这种复杂的问题的，就是任务分解。”
  紧接着，他一条条的给我讲解了什么是任务分解，然后，我们一起通过结对编程的方式刻意练习了这种方法。

任务分解怎么做

1. 将一个复杂的事情拆分成 N 个有明确目标和范围的的小任务
2. 我们将这些小任务进行优先级排序
3. 按排序的先后开始去一个个完成任务
4. 在完成过程中会发现一些新的问题,先不要去解决他，我们把这个问题同样当成小任务放到我们的任务列表里面（我们往往就是在这里迷失了方向）
5. 重复 3-4，直到我们把任务列表都完成通过使用任务分解，我把需要重构的内容，分解成了一个个范围我们可以控制的任务。

没想到比之前在“迷宫”中花的时间还短，就完成了整个重构。

Tasklist

最后的一些思考

  一切美好的事物都是曲折地接近自己的目标，一切笔直都是骗人的，所有真理都是弯曲的，时间本身就是一个圆圈。

Curve
  复杂的问题我们通过任务分解的方式一步步的去曲折的靠近目标，一开始看到的笔直不过是在欺骗我们。当我自认为很快可以解决这个问题的时候，已经迷失在了问题的迷宫中了。其实在我们平时接触到很多实践和方法论中都或多或少的出现了它的身影。比如 TDD 通过一个个功能点测试去完成整个功能；Scrum 中将一些大的问题拆分成了一张张 story 卡。
  如果，大家遇到了和我类似的情况，不如试一试任务分解，说不定你的问题就能一点点的解决掉了。