Wiki what?

信息工作的基本组成:记录,思考,定义,重构,判断,创造。这个 Wiki 既是状态,也是过程。因为问题的复杂度经常超过(未经专门训练的)大脑所能承载的容量,我没有时间、胆量和意愿专门做这样的训练,又希望能随时访问一个第二大脑,因此采取了这样的形式。

学科:地理学

职业相关:?内容行业 | 写作

兴趣/Yak-shaving:?Emacs | ?Racket | ?信息素养 | ?知识经济

Wiki how?

使用 Ikiwiki。

命名空间用子目录定义。

除了页面的相互链接之外,用标签表示类似 Wikipedia 的 category 概念。

链接会经常变动,文字在确保尽量反映认知水平的前提下才考虑可读性,也就是可能会有一些我自己完全能读懂但别人读起来比较费力的字句。

你也可以编辑这个 Wiki

在任何页面点击 Edit 按钮可以进入注册/登录界面。注册用户可以编辑每个页面的讨论页和自己的用户页面。

如果需要编辑其他页面,请在对应讨论页面留下 gitlab.com 账号,我会给你临时提交 Pull Request 的权限。

Wiki why?

在软件行业有技术债的概念。有时软件开发人员在忙碌的工作中,难免需要在尚未对问题完全理解的情况下完成任务,甚至“面向 Stack Overflow 编程“,这造成后续的开发需要用更多的时间来理清思路和解决问题,它们就是技术债。

在软件行业之外,这并不是一个太容易理解的概念,许多使用这个概念的人误以为技术债是指先交付质量差的代码,之后再重构成质量较好的代码还债。于是概念的提出者 Ward Cunningham 1 后来又从认知的角度定义了技术债2:

If you develop a program for a long period of time by only adding features but never reorganize it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it takes longer and longer.

一段代码如果不经常更新,以反映自己对需要解决的问题有什么认识上的变化,就会渐渐与自己的想法脱节。这个认识可以不局限于软件行业。知识工作者每天都在接触大量的信息,在接受、加工、输出信息时,我们也未必能让词句绝对准确地表达我们的意思。更何况,人对一个概念、一个想法的认识,也是在不断变化的。不难想象,我们写下的文字比我们写的软件代码会更快地偏离当前的认识。

写字的人比软件工程师更容易欠下“技术债”,或者不如说“认知债”。如果这些文字主要是给别人看的也就罢了,因为读的人自会留意文章发表的时间。但个人总有写给自己不时回顾用的文字,这些文字如果不能反映个人的认知状况,也就失去了继续留存的意义。

这是目前我能想到的,大部分人无法长期坚持写博客的最有解释力的缘由。因为多数人的看法和关注点是经常变化的,关注点一变,几天前写的帖子就很难看出和自己当前的关注有什么关联了。过上一个月,可能根本不想看自己博客写了什么——与当前的关注没有一点关系了。

而用纸笔记录一时的想法,倒是比较容易坚持。我也经常翻阅过去的日记,回顾当时的想法。但一时的想法在纸面上不容易连缀成系统的表述,时间一长,记录分散在几个本子里,就更难放在一起整体地查看。

而 Wiki 看起来是个逐渐偿还认知债的好办法。我可以不断更新它,同时又能看到创建以来的所有历史记录。不同的页面代表了不同的关注主题,一段时间不更新也只是表示个人的认识没有更新,要用时还是随时可以找到它们。通过经常翻看、回顾和反刍纸面上的笔记,再创建或更新 Wiki 上的页面,我可以有效地减少认知债。

本雅明写作《拱廊街项目》的时候,似乎也是用类似的方法把拼贴式的文字整理到不同的主题下的。

Ward Cunningham 同时也是 Wiki 概念的提出者,并维护着互联网上历史最悠久的 Wiki 社区,我相信这并非偶然,Wiki 就是他在软件工程领域之外解决技术债问题的答案。


  1. Cunningham 在 1992 年的报告 The WyCash Portfolio Management System 中首次使用 "debt" 一词表示交付后需要优化的代码。
  2. https://wiki.c2.com/?WardExplainsDebtMetaphor,要点是书写足够清晰的代码,以确保回头你能根据对问题的最新理解去重构,而不是写单纯质量好的代码。