Notes on q3notes [0] – 问题驱动式的日志

工作日志，尤其是给自己看的那种，我个人喜欢以「问题—答案」的格式来书写。毕竟程序员的工作原理上就是解决一个个的编程问题，那么将这些问题记录整理并索引对于个人以及对于团队内的其他成员而言都是十分有利的。

卡片日志

在上一个关于笔记的文章中，我们提到了「流式日志」，即所有或长或短的内容都堆放在一起，中间再夹杂一些用于索引和格式化的小标记。这种日志方案对于个人生活的记录是很合适的，但是对于有特定主题的日志，比如工作日志或者研究日志，将所有东西都堆在一起容易让人感觉眼花缭乱、没有头绪。

所以，对于有特定主题的日志，不妨抽点时间将每一个日志条目整理为独立的个体。

问题—答案格式

我们以一个简单的例子来说明这种记录格式：

问题：由 ARMClang 和 ARM GCC 编译出来的二进制是否通用呢？

答案：（上述问题的答案，此处从略）

这里的问题可以很宽泛，这里的答案可以很复杂。但基本的格式就是：提出一个问题作为话题，之后围绕着这个问题解答。答案甚至可以图文并茂，以十分专业的水准去解答一个看似平凡的问题。这么做看似有种闲得蛋疼的意味，不过某种意义上也属于合法摸鱼。

现有的工作日志软件

老老实实写日志 (OneNote, 印象笔记等)

缺少交叉引用。这个在之前就提到过了。

老老实实写文档（TeX, Word 等）

上云麻烦。TeX 需要额外编译，Word 跨平台支持不佳（而且交叉引用能力孱弱）。虽然 OverLeaf 可以整活云上 TeX, 但是 6GiB 的 Docker 镜像着实把我劝退了：我目前还没有一台服务器可以整活这种重量级镜像。

看板

市面上用于管理开发进度的软件都是实现了一个电子看板。电子看板虽然看起来很直观、很好用，但是说实话，看板是一种管理工具而非研究工具。看板假定了每一个问题都是原子性问题，但说实话，很多看似原子性的问题仍然需要深入研究并拆分成夸克性问题。

在解答问题的过程中，会遇到新的问题。新的问题本身也可以再单独成一个卡片，继续作答。这个时候就体现出了交叉引用的绝对必要性——一个复杂的工程问题会被拆分成多个子问题，其答案由对这些子问题的引用和综述组成。如果没有交叉引用，这些零散的子问题就难以为原本复杂的问题提供支撑。看板本身并不支持交叉引用，而且所有「已完成」的事情过一段时间就会消逝在历史的长河里，形成不了任何积淀。

思维导图

有许多人推荐使用思维导图进行工作日志的写作。寥寥数语、几条线就能勾勒出一天、一周、一个月甚至一个季度的工作计划和结果。看起来也是非常直观、好用。配合什么 PDCA, KPTP 等等汇报格式，写出一份完美的工作日志不在话下。

但问题是目前我的需求是记录我工作中实际遇到并要解决的问题，它更偏向于研究流水账而不是漂亮的工作汇报——后者我自然会用其他工具去写。而且，你见过哪个正经人会用思维导图写图文并茂几千字的？¯\_(ツ)_/¯

结论

那么，还是需要自己整活。q3notes 将需要支持这种记录形式，以及这种记录形式所依赖的所有能力。

这可真是个大坑啊。