如何走出問題的迷宮
在我們生活和工作中，或多或少都會遇到一些非常“繁複”的事，基於我們自身認知的情況下沒有辦法一下就處理完畢。可能是籌劃一個完美的 party；可能是需要做一個面面俱到的旅行計劃；也有可能和我一樣，需要在工作中去解決一個”複雜”的問題。
如果你用敲釘子的辦法去解決他們，那你很有可能會走入問題的迷宮。請跟着我一起看看，到底是什麼樣的方法讓我成功走出重構了這個“複雜”業務的迷宮。
問題來了
那個時候我正在參與一個大型項目的第二階段。項目中核心業務的代碼實現邏輯與我們和客戶確認的業務模型有一定的出入。需要將這個不匹配的模塊進行重構成和實際業務模型一樣。項目上的後端開發人員中，只有我一個人是擁有項目第一階段的所有上下文。這時，我自告奮勇的去接受了這個重構任務。
敲不完的釘子
以我以往的經驗來看，這不過是重構的時間稍長而已。一開始，我就想象着可以揮舞釘錘那樣去錘下那一個個翹起的釘子一樣把重構就能完成了。
但是事情接下來的發展出乎了我的意料。釘子們被敲了進去，另外一邊剛敲下去的釘子又冒了出來，甚至出現了很多新的釘子。就這樣按下葫蘆浮起瓢，我埋着頭在被改的亂七八糟的源碼裏面暈暈乎乎的搞了好幾天，重構沒有一點進展。這時候的心態也和這塊需要釘釘子的板子一樣，一片狼藉了。
走出迷宮
因爲這幾天我都在做着同一件事，但是沒有任何的內容產出。於是找到了 TL 溝通。我告訴他：“我先找到一個點去改，結果發現改了這個地方導致其他地方也需要改，然後我就這樣不停的改啊改啊，不知道改了多少次，也不知道還要改多少才能做完。”他聽完以後告訴我：“你這樣去做比較簡單的事是沒有問題的，因爲事情很簡單，每個改動的邊界是可以感知和控制的。但用這種方法做看不到邊界，無法控制每次修改影響範圍的事。結果就會是做了很多，還不知道對錯，最後陷入進退兩難的境地。好在我們其實是有方法去解決這種複雜的問題的，就是任務分解。”
緊接着，他一條條的給我講解了什麼是任務分解，然後，我們一起通過結對編程的方式刻意練習了這種方法。
任務分解怎麼做
- 將一個複雜的事情拆分成 N 個有明確目標和範圍的的小任務
- 我們將這些小任務進行優先級排序
- 按排序的先後開始去一個個完成任務
- 在完成過程中會發現一些新的問題,先不要去解決他，我們把這個問題同樣當成小任務放到我們的任務列表裏面（我們往往就是在這裏迷失了方向）
- 重複 3-4，直到我們把任務列表都完成通過使用任務分解，我把需要重構的內容，分解成了一個個範圍我們可以控制的任務。
沒想到比之前在“迷宮”中花的時間還短，就完成了整個重構。
最後的一些思考
一切美好的事物都是曲折地接近自己的目標，一切筆直都是騙人的，所有真理都是彎曲的，時間本身就是一個圓圈。
複雜的問題我們通過任務分解的方式一步步的去曲折的靠近目標，一開始看到的筆直不過是在欺騙我們。當我自認爲很快可以解決這個問題的時候，已經迷失在了問題的迷宮中了。其實在我們平時接觸到很多實踐和方法論中都或多或少的出現了它的身影。比如 TDD 通過一個個功能點測試去完成整個功能；Scrum 中將一些大的問題拆分成了一張張 story 卡。
如果，大家遇到了和我類似的情況，不如試一試任務分解，說不定你的問題就能一點點的解決掉了。
