“当你有一把锤子，你会把一切看成是钉子。”
——马斯洛
技术人员经常会陷入“锤子理论”中。当掌握一门新技术，了解一门新框架，或者编写了一个插件，我们总是迫不及待的想大展身手，把这些新的东西，融入到产品中、项目中，或者自己的作品里，甚至很少会去想，它是否真的适合？
昨天下午，在我的HoorayOS交流群里，和群友讨论图标拖动排序的原理，后面讨论到拖动结束后排序是否要改变dom结构，有人提了个不错的思路，就是不改变dom结构，只改变dom的top和left样式，实现排序更新，达到高效。
无需质疑，这肯定是个好方法，并且当晚我就在考虑怎么将现有排序修改dom的模式换成新模式。然而在实际情况下，却有很多问题，比如，想要达到不修改dom必须保证dom元素必须是同辈的，如果将桌面图标拖动到文件夹，这种情况就无法处理。
但我有新思路，就是当拖动的区域处于同个父级下时，采用不更新dom结构的模式，跨区域拖动依旧采用原有模式。问题又来了，如果不更新dom结构顺序，那就必须创建一个数组来记录图标的实际顺序，每次拖动结束后，更新数组，然后通知dom更新top和top。
这时候，我不得不开始思考，这种模式是否真的适用？因为提供专属的解决方案只能解决某种特定环境下的拖动，如果这样操作，势必会提高维护的成本，同时也潜在的增加了代码的阅读体验。同一个操作为什么会有不同的处理模式，新手阅读代码会很困惑，这样我就必须花下足够的时间成本去讲解，让其明白其中的“奥妙”。在这几点的权衡上，我决定放弃。
这件事过后，我就想到了“锤子理论”，还真是像，不过我很庆幸，我没有陷入。一把锤子，想解决所有问题，必然不可能。而我们要做的是，权衡这把锤子，它可能每下能敲3个钉子，但敲每下必须用出原先5倍的力气，这就需要我们自己来决定是否使用这把锤子了。
架构师尤其要在这方面注意，因为每一步的举棋落棋，都影响着整个项目、产品的未来，不要盲目的去“为了解决问题而解决问题”。