马斯洛的锤子

沪江技术学院 · 掘金 · · 2018-03-02 06:20

正文

请到「今天看啥」查看全文

文：Kyne

本文原创，转载请注明作者及出处

你可能从来没有听说过亚伯拉罕·马斯洛，但你一定会知道他的5层需求层次理论：生理需求、安全需求、社交需求、尊重需求和自我实现需求。不过今天我们不讨论他的需求层次理论，而是谈谈他的“工具法则”，即马斯洛的锤子。

在马斯洛经典的语录中有这样一句话：“当你只有一个锤子时，任何东西看起来都像个钉子”。

该名言至少包含以下两个重要含义。第一个含义，我们都有一种试图使用自己熟悉的工具或仪器来解决当前问题的倾向。如果你是一名 Java 后端程序员，可能会尝试使用 Java 语言来分析和实施任何需求。如果你是一名前端开发，可能首选使用 H5 或者 Swift 去实现功能。如果你是一名 DBA ，可能更倾向于考虑如何使用 DB 来解决问题。

在我的职业生涯中碰到过不少这样的例子，特别是在做架构师的阶段。有一次参与公司重要私有存储选择讨论会，有非常多的架构师参与架构设计。会上，我们各自拿出自己的设计方案并进行评审。有的选择功能简单的 DFS，有的选择高可用的 NFS，而我也祭出了自己比较熟悉的 ceph 方案。

不难发现，大部分人提供的设计方案或多或少的都会使用自己熟悉的架构或技术。并不是说这种方式不好，对熟悉事物的把控肯定比对不了解的事物把控来的高。只是我们会忽略一点，这样的设计真的是最合适的吗？

设想一下，如果家中水槽坏了，根据马洛斯的锤子定理，我们会使用锤子去敲打水槽，其结果很有可能会对水槽造成进一步的破坏。应该从需求的深层次去思考，需求到底是什么？锤子是否真的适合修理水槽？

把这个理论延伸到系统可扩展性上，本来一个简单的文档型存储就能解决的数据存储问题，我们为什么要使用关系型数据库实现？如果路由器就能屏蔽某些端口，何必要使用防火墙呢？

在上面的例子中，存储的是公司十几年来积累提炼的核心数据资产，数据量倒是其次，尤其要保障的是可用性和分区容忍性，即 CAP 理论中典型的 AP 系统。在我们熟悉的“锤子”中，要做到这两点需要投入很大的成本。如果前期投入不足，很容易造成线上事故，影响业务发展。

在此案例中既然数据体量不大，又强调高可用和高容错，云存储是比较合适的解决方案。虽然存储成本成指数增长，初期的成本小于自建成本，但时间一长云存储的成本必然会大于自建成本。不过在这之前，我们能够利用这段时间，做好充足的技术储备，解决初期投入成本问题。

马洛斯的锤子定理的第二个含义，其实是建立在第一个含义的基础之上的。在我们的组织内，如果持续引进有类似技能的人来解决问题或实施新产品，我们很可能会用类似的工具和第三方产品获得一致的答案。这样做的问题是，虽然组织内的成员对某些方案容易达成一致和获取高的可预见性，却会驱使我们去使用对完成任务来说不适当或不理想的工具或方法。在看似一片祥和的气息中，却暗藏着危机。

我们在面试或带人的过程中，很多时候会选择有同样经历或技能的候选人，自然的选择“排除异己”。举个自己犯过的错误：系统需要一位对某中间件比较熟悉的开发人员，对岌岌可危的中间件进行长期的维护和二次开发，而组内成员又对此中间件并不熟悉。

在众多的简历中，其中一位候选人对此中间件非常熟悉，但却对我们熟悉的其它技能没有那么精通。而另一位较为平衡，不但对此中间件略有了解，更重要的是符合我们的择职风格。我不幸被马斯洛言中，物以类聚，人以群分的选择了后者。但之后发生的事让我吃足了苦头：新来的伙伴无法完全把控中间件的特性，出现了无法恢复的问题，系统为此降级了近1个月时间。

架构中我们需要选择更加合适需求的解决方案，而不是自己擅长或熟悉的。当然，最好最适合的解决方案正好是我们熟悉的。团队组建中也需要引入不同的技术栈成员，知人善用，让合适的人做最合适的事，同时也让有不同的技术栈的伙伴成为自省的明镜。

让团队中有更多的工具而不是各式各样的锤子；即便我们只有一把锤子，也不能把所有的问题都看成钉子。这便是马斯洛的锤子给我们的启示。

推荐阅读

手把手教你开发一个 Webpack Loader