听说wiki这东西已经是好几年前的东西了，但一直没有用过，只是偶尔享受别人的成果，感觉很特别。公司最近准备开始使用wiki，理由是为了开发人员能更好地交流。讨论到最后，发现wiki其实也是一个知识共享的平台，大家可以把工作中积累的经验或教训在wiki中发表，避免错误的重复发生，同时让好多东西能够更广泛地传播。同时，wiki也可以很好地充当开发文档的角色。这些都是在决定使用wiki之前没想到的。
因为开发团队中各成员的水平参差不齐，通常有经验的员工曾经遇到的问题，犯过的错误，年轻员工也在不断着地重复着。我在Review代码时常常看到一些类似的问题，总是一犯再犯。于是我告诉有经验的员工对比较典型的问题进行总结，用邮件的方式传播，保证每个人都能看到，同时吸取教训或是经验。这样就起到一个知识分享的作用，好的东西总是受人喜爱的。但这也引发了两个问题，一是邮件这种方式决定了写邮件的人不会很注重格式，认为它不是正式的文档，就不会花很多心思让它的内容和结构变得更条理。如果重写再重发，收到邮件的人通常都不会再仔细看了，效果不好。二是新员工无法得到他入职之前我们已经分享过的成果。于是他又再重蹈覆辙，然后花费不少的时间和精力（包括很多人的）去修正。
我也曾经想过制定完整的开发规范，但没有积累到一定程度，这个规范怎么都无法符合我的要求。况且每次更新都只能是个别的员工去做，更新完之后，有没有人去看它也是个问题。这里涉及到不只是员工本身的积极性，也有人性的东西在里面。再怎么强求也没用，所谓勉强没幸福的。
现在决定使用wiki，可以解决不少问题。首先，谁都可以去编辑它，激发了每个人的积极性。既然是我写的，而且还会有很多人看，责任感就出来了。至少不会像邮件一样，三五句就打发了，也不管别人看不看得懂。其次，wiki不像是文档那么枯燥，你不会还没打开就已经失去兴趣。说不定可以得到意外的收获，或是发现有问题的地方，需要你的帮助。wiki是沟通，不是说教，没那么容易让人犯困。第三，我们的文档也可以写在wiki里面，既好维护，又易共享，也容易查找。就我所知，开发文档的维护是一件非常困难的事，常常过了几个版本后，最初的开发文档和需求可能已经找不到了，或者好不容易找到了一些，发现已经老的不能再老，跟现在的情况已经差了好几代。
当然，wiki也有它的缺点，就是难以控制内容的质量。不过我觉得瑕不掩玉，值得一用。
第一次正式使用wiki，先抛出一块砖。过段时间会再总结一下心得，与大家分享。