前言

最近读两本书有感，想分享一下我的想法给大家，希望对你有帮助。感想就是如何避免生活中的思维定式，当我们碰到 A 场景的时候，我们不由自主的就想到利用 a1 方法去解决，而没有思考 a1 方法的正确性与否，而是根据我们平时的经验和习惯所导致的，这就是我今天想讨论的话题，如何在发生 A 场景下，我们思考一下 a1 方法的可行性，是否有 a2 a3 方法，这几种方法哪一个更合适。

这样举例子我们没有带入感，我这里用生活中的例子来描述一下这种思维定式的一些缺点，这不代表着没有优点，我们只讨论一下它的缺点，毕竟是有则改之无则加勉。

举例说明

两本书中提到了这个问题，其中有几个例子我记忆深刻，这里我讲一下。
有一个货车司机 A 常在山区开车，但是有一天他过一个弯道的时候，对面也开过来一个货车司机 B ，并且大声向 A 说：“猪、猪、猪！”。当时 A 的第一反应就是马上回骂道：“你才是猪，你全家才是猪。”，最后转过弯道的时候发现有一群猪在路中间，然后司机刹车不及时导致车祸发生。这个例子可以说明就是司机根据自己以前的生活经历，来条件反射一样的回复对面司机，没有考虑到其他情况，这是其中的反例。

软件开发中的思维定式

通过客车司机的思维定式，我们来思考一下我们平时软件开发中会遇到什么思维定式，我这里举两个咱们熟悉的点：

• 项目很紧，赶紧完成任务，代码写的不严谨也没关系，以后重构
• 遇到产品又改需求的时候，第一反应就是，怎么又改需求？老子不改

第一个情况大家都明白，留到以后重构，估计是猴年马月了，所以业务在忙，你也要想清楚了，或者通过UML 图来分析一下业务的结构，看以后是否会发生变化，提前适配拥抱变化。

第二个情况就是我们平时对产品的更改需求的深恶痛绝，但是毕竟是于人于己，我们应该更换一个态度来看待这个问题，就是我们能不能思考一下这个功能的添加的必要性，是否有必要？是否有更好的方案来实现它的需求，我们这样思考有利于我们对于产品的思考，不只是停留于码农的思考阶段。

总结

最后，国际老惯例，开始总接一下我的观点，就是我们要多加思考自己的平时的思维定式，或者做某件频率比较高的事情的时候，考虑五秒钟，是否有更好的方法来解决？