简介
二元思维
一日，正一个工作干的兴起，一个其它部门的同事找我帮忙解决一个问题，他问题也说的不是特别清楚，但看着很复杂的样子，于是我就说这事儿弄不了（留给他最原始麻烦的办法去做）。第二天早上去公司（我有提前一两个小时上班的习惯）， 闲下来尝试做了一下，发现不是很麻烦。
我发现一个工作上的误区：很多事其实不是不能干，而是当下事情太多，正兴起的时候中止掉去干一个不知道花多长时间的事情，人的内心是容易拒绝的。
在分布式时代，消息调用结果有三种：成功、失败、超时。而我们还停留在单机的成功、失败二元时代：做与不做、做不了，会与不会，想与不想，同意与不同意。其实呢：
- 做与不做之间，还有明天做、等闲下来做等
- 会与不会之间，还有花一段时间学会
- 想与不想，还有缓一缓，让自己静下心来思考，或多方咨询再做决定
- 同意不同意，还有保留意见，让对方试错回头的方式
甚至更宽泛一点，生活中的很多问题都不单纯是一个二元问题：
- 学习知识以广度为主还是深度为主？知识的广度和深度
- 大公司还是小公司
- 要不要紧跟潮流学习人工智能、区块链等
有质量的的提问
- 项目报错了，帮忙看一下。一般附上一个哭脸或色色的表情
- xx项目报了xx错误，帮忙看一下，项目地址在xx，在xxx可以看到报错信息
- xx项目报了xx错误，帮忙看一下，项目地址在xx，在xxx可以看到报错信息。我一开始认为是因为xx，经过验证不是这个原因，一时没有思路。
- xx项目报了xx错误，帮忙看一下，项目地址在xx，在xxx可以看到报错信息。我一开始认为是因为xx，经过验证不是这个原因，一时没有思路。这个项目昨天还是好的，今天我改了xx就不行了。
很多时候，等你把错误、前因后果都说清楚了，估计自己就找到答案了。
靠搜索而不是靠分析
很多程序员，碰到一个bug、error信息（笔者有时候也是），最直接的反应不是分析原因，而是将error 信息粘贴到google、百度搜索框中，然后不停地搜索。
但笔者比较建议的方案是：
- 直接搜索，两三次发现找不到，则放弃搜索
- 分析上一次成功 到这一次失败，自己所做的代码改动
- 分析error 信息，判断哪几种原因会导致该错误（等于换了个问题，这个问题可以google一下）
- 逐步分析排错可能的几种原因
这种思维方式，虽然不见得能够最终解决问题，但总会有所收获
我们不停地去搜索 而不是去分析的底层原因是什么？
- 懒
- 不自信，不认为自己可以解决这个问题
- 依赖第三方框架，自己不熟悉，也不想了解这个框架
- 时间很紧张，起初以为自己搜一下就可以很快解决，或者总觉得下一次搜索可以解决问题。
今日资本的徐新在一次视频演讲时提到，现在人的一个重要特征是：懒，不仅是身体的懒，更是思维的懒。后者更可怕，因为很多时候都发觉不到。
没有分层思维
程序猿作为“主体”，去认知和实践“客体”。这些“客体”有哪些呢？
- code，代码实现
- design，项目设计
- 技术或知识，学习新知识/技术
- 学习/认知本身，认知本身有什么规律
但在认知和实践过程中，都有哪些问题呢？
- code，代码写在一个类、函数里，一点不考虑“逻辑是分层的” 这一事实。以一个app http 请求为例，如果不是controller-service-dao 的惯例 + 数据访问框架，我一点不怀疑一些开发 会将接收请求和jdbc 混在一起 放到一个函数中。
- design 项目设计，还以一个普通的web 业务为例，如果数据库表定好了，页面很多时候也会被设计成一个表的crud，说白了就是给一个表做了一个web view 而已。简单点的项目（用controller-service-dao）问题不大，复杂点的业务本身通常有很多业务概念，这个时候可以尝试下ddd设计。
- 学习新技术，根据认知的几点规律：知识是分层的。大部分程序猿在学习新技术时，只看到一些细节，且不会与已有的知识体系相结合。
很多程序猿 一直秉承着 “我在为某个项目学习一个技术”或者 “我在给某个产品经理实现一个业务”，从未考虑将正在做的事情内化为自己的理解，技术和业务都是别人的，需求结束了，自己和这些技术的关系也就结束了。说白了还是懒，“实现效果不就好了嘛”。
分层需要你花更多的心思琢磨这个事情，在已知和未知之间保持 优雅的联系。某篇文章中提到：读书在当今的时代真的是一项能力，一本书看完，作者想表达的观点到底是什么，如何与你的生活与实际进行结合，书中的知识怎么和你的存量知识进行连接，这是一个需要长期锻炼的能力。
说了就干，干了再想
笔者最近和小伙伴碰到一类问题：事情都快做完了，突然想到更好地方法，这个时候就会有些懊恼，“为什么刚开始没想到”？ 这就要求我们：
- 书写是更好的表达，关于写文章的一点经验对于任何问题的思考，想清楚、讲清楚、写清楚是三个完全不同的维度。「写清楚」是一个很好的反思过程，把「讲给别人听」的逻辑，通过文字书写出来，大脑就再也不用费力去存储那些内容，更多的精力可以用于不断的反思自己的观点，体系化的完善那些观点，因为往往写出来的时候才发现需要有很多背景要交代，有很多思考逻辑需要斟酌，有一些漏洞会被识别，有一些自己不完整的知识体系被觉察，这个过程中的成长其实才是最宝贵的。
-
多看，写作即思考，而思考不是凭空出现的，思考需要原料，常见的原料就是我们实际的工作经验，然而一个人的体验毕竟是非常有限的，而阅读他人的体验及思考，以谦卑的态度为自己的思考提供更多原料，显然是明智的做法。
- 给予设计足够的重视，尤其是以文档的形式 将设计 准确、优雅、简单的表达出来，写文档的过程就是对自己的设计进行完备性测试。实际过程中，经常一听需求直接就开干了，复杂点的或许画个草图。
- 一个人的想法总是有局限的，可以将第一步得出的文档转给多个人看，尤其是大牛看，接受他们的challenge
- 足够的快，设计项目的时候你对项目的认知最少，完成项目的时候对项目的认知最多，这是不可避免的。只有足够的快，不求完备，小步快跑，快速验证，才能减少设计失误带来的负面影响。
思维的懒
有很多很简单的道理，我们知道做不到，对大多数人来说是知易行难。行动分为两种
- 看见的行动，比如早起早睡
- 思维的“行动”
行动比知道难，思维比行动难。
德扑
笔者回顾玩德扑时几次“血亏”的过程，发现越是重要的决策，反而想的最少，甚至都没有认真分析过对方的牌，分析对方第一次下了多少筹码、第二次、第三次…，进而得出一个初步结论。
出牌的时候想想对方的下注过程很难么？是一个想不到的方法么？都不是，但就是不去想。说白了就是懒，思维上的懒。
时间管理
在时间管理领域，我们都知道事情根据时间和重要性两个维度划分为
- 不紧急不重要
- 不紧急但重要
- 紧急但不重要
- 紧急且重要
但碰到事情，我们还是手忙脚乱，进退失据。我们只会采用最简单的方法，来一件事做一件事，只会被动应对没有主动把控。
神探狄仁杰与排查bug
笔者时不时的会看下《神探狄仁杰》，一开始听到“狄公真乃神人也”的时候觉得在尬吹。但多看几遍，味道就很不一样了。我们观众站在上帝视角，知道发生了哪些事情，但主角不知道，他要根据一系列现象去分析，最终得出一个有意义的结论。
我们排查bug 也是如此，根据一系列现象，得出一系列推论，缩小“问题域”。若是证据不足，可能要针对“嫌疑人”进行试探。这背后是一个思维闭环：
- 有哪些现象（尤其是反常现象），通常什么原因会导致这些现象。
- 有哪些推论
- 选择合适的方法排除不必要的选项
- 剩下的那个便是结论
而大部分开发在排查时，根本不知从何入手，“狄仁杰”脑子里是一条面，很多开发脑子里是一条线，这条线走不通，便摊手找老大帮忙。更有甚者，碰到bug只知道频繁的重启重试。
比如笔者一直对pullrequest 的流程总是忘记，但是有一天github 拉下来一个源码，本地切换分支commit 发现没权限，顿时恍然大悟，不是contributor，自然只能push 到自己的库中了，进而fork 操作也就是必要的了。
将显意识炼成自己的潜意识
“人饿了找吃的” 这件事不用动脑子，但对方加注时分析收益率却需要人主动地去思考，在情绪刺激下“理性”甚至会被抛在脑后。人要取得更长远的进步，就要打破自己的“舒适区”，将第二、三反应炼成自己的第一反应。因为这事太难，所以一旦掌握便威力巨大，比如更高的德扑胜率。