“當你有一把錘子，你會把一切看成是釘子。”
——馬斯洛
技術人員經常會陷入“錘子理論”中。當掌握一門新技術，了解一門新框架，或者編寫了一個插件，我們總是迫不及待的想大展身手，把這些新的東西，融入到產品中、項目中，或者自己的作品里，甚至很少會去想，它是否真的適合？
昨天下午，在我的HoorayOS交流群里，和群友討論圖標拖動排序的原理，后面討論到拖動結束后排序是否要改變dom結構，有人提了個不錯的思路，就是不改變dom結構，只改變dom的top和left樣式，實現排序更新，達到高效。
無需質疑，這肯定是個好方法，並且當晚我就在考慮怎么將現有排序修改dom的模式換成新模式。然而在實際情況下，卻有很多問題，比如，想要達到不修改dom必須保證dom元素必須是同輩的，如果將桌面圖標拖動到文件夾，這種情況就無法處理。
但我有新思路，就是當拖動的區域處於同個父級下時，采用不更新dom結構的模式，跨區域拖動依舊采用原有模式。問題又來了，如果不更新dom結構順序，那就必須創建一個數組來記錄圖標的實際順序，每次拖動結束后，更新數組，然后通知dom更新top和top。
這時候，我不得不開始思考，這種模式是否真的適用？因為提供專屬的解決方案只能解決某種特定環境下的拖動，如果這樣操作，勢必會提高維護的成本，同時也潛在的增加了代碼的閱讀體驗。同一個操作為什么會有不同的處理模式，新手閱讀代碼會很困惑，這樣我就必須花下足夠的時間成本去講解，讓其明白其中的“奧妙”。在這幾點的權衡上，我決定放棄。
這件事過后，我就想到了“錘子理論”，還真是像，不過我很慶幸，我沒有陷入。一把錘子，想解決所有問題，必然不可能。而我們要做的是，權衡這把錘子，它可能每下能敲3個釘子，但敲每下必須用出原先5倍的力氣，這就需要我們自己來決定是否使用這把錘子了。
架構師尤其要在這方面注意，因為每一步的舉棋落棋，都影響着整個項目、產品的未來，不要盲目的去“為了解決問題而解決問題”。