大多数人的大部分思维都是处在潜意识水平的，没有将思考的细节提升到词语水平。[1]
前几个月我在知乎上开了一个专栏叫「ADoyle 的深度思考」，我常常在思考各种各样的问题，因而开专栏以专门输出我的思考。有一天某人问我“你都在思考些什么呢？”突然我意识到自己的思考其实很模糊，不精确，并且是碎片化的。我真的懂什么是深度思考吗？不，我无法对思考行为给出一个合理解释，甚至都不能回答为什么我要思考。
虽然不能清晰认知自身的行为，事实上这并不妨碍我进行思考这个行为，并总结出一些结论和经验。这样的现象让我觉得很神奇。
我想通过写下文字试图理清思路，以便回答以下几个问题：
本文是我对思考这件事入门阶段的输出。它阐述了我的思考过程和思维模式，不一定适合你，但是希望能给你带来启发。
一年前，我读了高杉尚孝著的《麦肯锡问题分析与解决技巧》，其中对于问题的清晰定义和 MECE 分析法让我印象深刻（只记得这两个了）。
我觉得清晰定义问题是什么，是决策的根基。一切决策应当从问题出发。
因此基于此书的 1~4 章节，以及个人的深度思考，我实践总结了一套思维框架，与你分享一下。这个框架的目标是清晰辨识问题，快速分析出问题的本质。
不过在谈问题分析之前，先来看看在问题的认知上，我们可能会陷入什么误区。
你是否曾困扰于这样的情况，提了一个问题却无人问津；口干舌燥跟人讲了一堆，别人还是没听懂你的问题；又或者没有得到令自己满意的回答。
如果你没有这方面的困扰，很好，下文就不必读了你可以跳到文末总结看下思维导图。
我整理了一个提问的框架，目的是为了帮助建立有效的问答，从而让提问者的问题能够得到彻底解决。
此框架可能不适合用于话题性质的提问，以及不求甚解的提问。
下文将介绍提问时的原则、技巧和注意点。
向想要自己设计 DSL 的新手，分享一点我的经验总结。很多概念想法代入了个人见解，不具备权威性，请辩证看待。
本文不介绍 DSL 适合的场景，不解释为什么要用 DSL。以后我会另写一篇文章进行说明的。
本文主要介绍某种风格的 DSL 设计参考：基于 YAML 等通用数据结构设计 DSL。
有个朋友提了这样的一个问题：
同样的文件，用 zip 打包两次，打包出来的文件 md5 怎么不一样啊？
我自己做了一遍惊讶地发现真是如此，第一反应是打包混入了时间戳。但 google 却没找到恰当的答案。于是开启了我的探索之旅。
我做了一份关于技术面试的思维导图。主要是站在面试官的角度，看面试官和面试者这两个角色的关注点，以及整个面试流程的步骤。电话面试为主，现场笔试比较少。
这份导图是根据我的经验，并参考网络上很多人的文章，在一年前就大致作成的。之后又经历了一年的实践验证修改。我每次面试前都会看一遍。
虽然是技术面试，但面试思路对其他领域也是有借鉴意义。
我设计了一种声明式编程语言，以下暂称为 comia language。
该语言借鉴了函数式编程的思想，冯·诺依曼机器模型，以及 Minecraft 的红石原理。
它是一种可以基于任何编程语言实现的高级抽象语言。
它既不是 OOP，也不是 FP。它跟命令式编程语言有很大差别，请做好心理准备。
从 2016 年 8 月开始，我就在实践构建个人知识库，主要为了建立全面而深度的专业知识体系。也想有个备忘录，以备随时查阅。
后来思维导图在我工作生活中起到了重要的作用。截至 2018 年 2 月 28 日，我已经积累了 151 个思维导图，知识库已初见规模，其中有很详细的领域知识，也有几句话的想法。
接下来，将分享我构建个人知识库的经验。
如果你觉得文章太长看着麻烦，那就直接跳到最后一章，直接看本文的思维导图。当然两者是不等价的，文章包含更多细节。
本文翻译自 Scott Nonnenberg 的文章 《Think in alternatives》
当时选择翻译《Think in alternatives》这篇文章，是因为它给了我启发。我觉得这是一个开发者必经的思考成长过程，从「只会一个方法 / The one true way」到「多个看似正确的方案 / Multiple correct solutions」，然后是「协调权衡 / A classic continuum」，然后「增加思考的维度 / A few more axes」来帮助权衡筛选方案，最后是「创新 / Breaking out of the box」。这大概就是所谓的「守破离」的过程吧。
另外作者在最后对于如何与团队讨论决策也有心得，当你尽力考虑过所有方案时，以合适的时间在合适的地点提出来。参与到细节和全局，考虑到人和物，才能做出最正确的决策。
其实这篇翻译在我电脑里躺了一年……一年后再看，没有了当初阅读的欣喜，只觉得是很自然的想法，一切都在于「权衡」这个词。
二次校对和润色后，发现初次的翻译果然很糟糕，现在终于把还能入眼的译文发布出来了。
