我们前TestLab团队的负责人Czar Pino是教给我很多我现在作为开发人员的知识的人之一。 有时，当他做出决定或在解释某件事时，他会问： “这有意义吗？” 。
我相信这是思考事物的好方法。 当我们开发软件（或实际上做任何事情）时，我们应该总是问自己： “这有意义吗？”。 当我们做出决定时，它们应该永远是明智的。
明智的：（根据陈述或行动方式）根据智慧或审慎选择的； 可能会受益。 （Google.com，2017）
您可能会认为这很明显，而且所有这些，但我们经常做出的决策没有多大意义或根本没有任何意义。 这全都是因为我们的大脑和我们所谓的认知偏见，顾名思义，这就是我们思维方式的偏见。 确认偏差就是一个例子，其中我们倾向于寻找证据来确认我们喜欢或已经知道的东西。 我强烈建议您查看此认知偏见列表，以供参考。
为什么会这样？ 这是因为我们的大脑高效。 听起来违反直觉？ 我知道，对吧？ 通过创建快捷方式，它变得有效，而这些快捷方式会导致这些认知偏差。 这些捷径过去在我们还是肉食性的山洞居民时非常有用，而我实际上仍然是（loljk），因为当我们即将被群殴并因骄傲而被撕成碎片时，我们必须做出迅速的决定。剑齿小猫。 这些大脑捷径在当时很重要。 现在，不是很多。 这是丹尼尔·卡尼曼（Daniel Kahneman）在其《 思考快慢》中的理论的“快速思考”或“系统1”部分。
如今，我们需要学会缓慢思考-进行更多的计算，并花时间进行决策。 这样，我们就有更好的机会避免认知偏差。 减少认知偏见的另一种方法是让值得信赖的人来评估我们和我们的决定。 我们所有人也都有对其他人的认知偏见，例如“基本归因错误”，但至少有两种思想，而不仅仅是一种思想，彼此之间可以诚实。
减少认知的另一种™方式是问一个问题：“这有意义吗？”。
这个问题是思考我们思维过程的第一步。 听起来确实很中继，但确实很棒。 这个问题引发了许多其他问题，例如：
- 为什么那没有道理？ （弱点）
- 为什么有道理？ （优点）
- 我为什么做出这个决定？ （该思路背后的原因和条件）
- 我是如何得出这个决定的？ （导致该决定的想法）
- 是过度杀伤力吗？ （过早优化）
- 我真的需要吗？ （极简主义）
- 有没有更好的办法？ （更好的可能性）
- 这项决定的成本是多少？ （费用）
- 别人听懂我刚才说的吗？ （说明清楚）
- 5岁的孩子能听懂吗？ （如果不能，则说明您的主题不够好）
和其他类似的东西。 该问题会引发一系列的问题连锁反应，可帮助您确认或无效该决定-查看该决定是否实际上是“根据智慧或审慎”做出的。
让我们尝试将其放在上下文中。
（这是自以为是的，所以请不要杀死我。）
假设您是一家开发音乐应用程序的小公司。 您需要能够在2个月内构建原型。 您的技术负责人决定您将使用以下堆栈：
- API：进行时的GraphQL
- Web前端： Inferno和Redux
- 手机： 颤振
- 数据库： MySQL
您的团队知道什么：
- 休息
- PHP（ Laravel ）
- Javascript（ Node.js ， Meteor ， React ＆ Redux ）
- MongoDB
- 的MySQL
您开始对这里看到的一切不知所措。 现在是问这个问题的好时机：“这有意义吗？”。 让我们逐步了解并找出答案。
API
在REST 上使用GraphQL 是否有意义 ？
好吧，它有助于节省带宽，并且与REST相比，API的使用者更容易使用。
为什么在REST上不使用GraphQL有意义？
团队知道REST。 他们可能熟悉GraphQL，但是他们不知道如何实现它。
使用Go over PHP或Node 是否有意义 ？
Go比PHP或Node更快，因为它是底层的，并且对并发性有很好的支持。
为什么不使用Go over PHP或Node有意义？
您只有两个月的时间来构建原型。 您的开发人员都不知道Go或C（这也是底层的）。 与开发时间相比，您不知道提高性能是否值得。
网络前端
使用Inferno 是否有意义 ？
好吧，您的团队知道React和Inferno，并且两者之间并没有太大区别，因此开发时间实际上不会有太大区别。 除了Inferno通常比React快。 问题是： 您真的需要那种速度吗？ 您是否真的需要紧紧抓住每一个下降的速度？ 答案取决于您。
那React 16呢？
那是另一回事了。 由于新的光纤架构，React显然变得更快。 由你决定。 如果性能提升确实很重要，也许您可以检查Inferno在速度上是否优于React16。如果没有，也许您应该坚持使用React，因为开发人员已经有使用它的经验。
使用Redux 是否有意义 ？
您的团队已经了解Redux。 使用Redux。
为什么使用Redux 没有意义 ？
它会成为一个巨大的应用程序吗？ 它会有很多活动部件吗？ 如果是，那么使用Redux是一个不错的选择。 另外，如果您的团队从事函数式编程 ，那么Redux非常适合该范例。 如果它不是一个庞大的应用程序，或者您确定团队中的每个成员都会编写干净的代码，则可以使用MobX。 如果您更喜欢面向对象的范例而不是功能的范例，那么MobX也是一个不错的选择。 更好的是，根本不使用状态管理库。 对于原型，也许您可以尝试MobX，但要考虑未来：该应用程序是否会比现在复杂得多？ 如果没有，也许您可以继续使用MobX或完全删除它。 如果会更复杂，请从一开始就使用Redux。
移动
使用Flutter 是否有意义 ？
不，不是。 您没有时间学习Dart。 使用React Native或Cordova代替，因为您的团队已经知道React。
数据库
使用MySQL 是否有意义 ？
您的团队了解MySQL。 因为您已经习惯了它，这将使您和您的团队成员更轻松地开发原型。
为什么使用MySQL 没有意义 ？
您的应用程序将来可能会有大数据 。 如果是这种情况， MongoDB可能更合适。
爱德华·德·博诺（Edward de Bono）博士创建了一个由六种不同类型的思维系统组成的系统，他称其为“ 六顶思考帽” 。 思想帽子如下：
白帽需要已知或需要的信息 。 “事实，就是事实。”
黄帽子象征着光明与乐观 。 在这顶帽子下，您将探索积极之处，并探索价值和利益。
戴黑帽子是一种判断-魔鬼的拥护者或为什么某些东西可能行不通。 发现困难和危险； 哪里可能出问题了 。 可能是最强大，最有用的“帽子”，但如果使用过度则会出现问题。
红帽象征着感觉，预感和直觉。 使用这顶帽子时，您可以表达情感和感受，并分享恐惧，喜欢，不喜欢，爱和恨。
绿帽专注于创造力； 可能性，替代方案和新想法 。 这是表达新概念和新观念的机会。
Blue Hat用于管理思考过程。 这是确保遵守《六顶思考帽》指南的控制机制。
例如，您可以从戴白帽子开始，思考一下事实和严格的要求。 然后，您可以戴上绿色帽子，然后变得疯狂，并提出新的想法。 之后，您可以“戴” Yellow Hat来探索某个想法的最佳部分和“精打细算”，然后“戴” Black Hat并思考可能会出错的所有方面。
我认为这是一种非常有效的思维方式，因为它往往只带有一两个思考帽。 该系统为我们提供了突破常规思维方式的机会。
做出决定时，您可以尝试以下方法：
- 始终考虑您所做的决定
- 确保他们有知情的决定
- 确保您进行研究
- 确保问自己相关问题
- 确保向队友询问相关问题
- 始终检查其他观点（尝试其他思考方式）
- 问问自己， “这有意义吗？”
而已！ 我希望这可以帮助您做出更好的决定。 别担心，每个人都会做出错误的决定。 我也不例外 我们可以更好地做出正确的决定。
如果您喜欢这篇文章，请向下方的👏按钮发送垃圾邮件！ 🔥
祝你有美好的一天！ 🎉
