有了沙盘，弄熟了工具，下面我们来谈谈参与一个项目的开发和测试。我们先从项目的参与者角度开讲，之后再谈项目的发起者应注意的事项。如前所说，这些是我的一些体会和建议，很多方面都是“仁者见仁、智者见智”，所以欢迎大家拍砖、提建议和指教。 要参加一个项目，首先要开始学习，一举成名、一口气吃成个胖子的可能性不大。学习包括阅读文档，该项目的维基网页，加入mailing list，阅读项目发展蓝图，加入论坛（forum）潜水等。在做这些的同时，搞一个自己的branch，编译软件，练手调试，改变一些东西后再编译以满足自己的好奇心，这些都是非常有效的学习手段。 通过在mailing list和论坛上潜水，你可以了解到主要人员的活动、重要的源代码、发展方向、和他们的个性等。如果交流是以英文为主，还可以学习到常用的名词，为以后的研究、搜索、和提问带来方便，因为你会注意到，网上查资料搜索的关键是知道关键词！当然有些比较流行的软件还会有其他独立的社区，如Google group等，那里也可能有些有用的东西。 邮件表的历史很多都有归档，所以那里也可能有有价值的东西。另外，不少开源软件还有互联网聊天频道，IRC，一般是在freenode上。像MariaDB在freenode上的maria频道就比较活跃。这个真是因项目不同而异。一般来讲，我个人并不建议在聊天频道上呆太久，因为很浪费时间并且会分心，很难集中精力花时间做好一件事。但IRC频道的聊天有时也会有记录，所以周期性的快速浏览下可能发现点东西。如果你是有备而来，如果主力人物都在聊天频道上的话，有针对性的在IRC上讨论些问题可能会比较快和直接地找到答案。 在潜水的同时，也要注意性能和bug的标签。如在Launchpad上，有的项目给一些性能和故障贴上low hanging fruit，即易采摘果实的标签。你可以先从这里开始，看看自己能不能搞定。不妨先在自己的沙盘里大胆尝试下，写单元测试实验案例，改下代码，编译测试，推测和验证各种假设。反正是自己的沙盘，尝试下又有何妨？只有敢于尝试，满足自己的好奇心，才能提高自己的功力。 同时，参与并帮助一个项目的测试和文档也是融入该项目的好方法。开源项目是分布式开发，程序员分布在不同的地方，实际上不少非开源项目也是如此。人不在一个地方甚至国家，很可能有语言障碍，就需要花时间了解沟通和建立互信。如果你可以先在测试、文档等基本方面帮忙，就可以建立起良性的互动。这也是我建议先读文档、入邮件表、到论坛潜水学习的原因之一。比方说你可以帮助完善该项目的维基网页，提交一些自己亲身做过的how to文档，提交测试案例等。因为大家一开始对你不了解，如果你一上来不先做调查研究，做好功课，就开始指点江山、激扬文字，要显示自己的聪明才智和独到之处，那么，抱歉，没多少人会买你的帐。 在开发和使用的过程中，你可能会遇到故障。发生了这种情况，在提交故障报告（bug report）之前，请首先在故障表、邮件表、论坛里搜素下，看看别人是否已经提交。如果没有，那你应当提交一个故障报告。提交时，请注意说明系统环境和配置，有没有绕开该故障的办法，怎样才能重生该故障。如果你知道怎么来解决这个故障，那当然更好，那就请提交你自己的补丁。有的项目需要提交测试案例（test cases），有的不需要，但作为一个程序员，你要有自己的test case。我以后会专门写到测试。 —— 下面简单说说我关于项目发起的想法和建议。 首先，心里要有这个数：我这个项目是给自己kuai痒的（英文俚语scratch an itch，正式用语可能是抓痒吧，至少鲁南话说三声的kuai，不知有没有这个字）。这个项目满足了我的需求，对我本人有用，这是最重要的。能切实解决我的问题，那别人遇到类似情况，我的解决方案也就可能管用！我开发的过程中会有乐趣，会有挑战和能学到新东西，但知道它能帮助别人也是很大的乐趣。我希望它能火，并且也下力气让它火，但是它火不了的话也没关系。这不是阿Q的精神胜利法，这是全球各地绝大多数开源软件所面对的现实！ 那么，我做开源，有意义吗？当然有。简要地说，自己做开源基本上是业余，而不是全职的做商业软件，所以风险小。但如果火起来的话，会有商业利益过来。另外，开源的目的是知识的积累和分享，发起者在这个过程中可以得到全方位的成长：文档、测试、开发、协调、发布等，还可以认识到朋友和同仁来打通人脉。或许这个项目只能给不到一百甚至不到十个人带来益处，但只要它能给自己带来益处，就已经足够。 好，不谈哲学和自己做开源的其他好处，下面我们来谈谈想法和建议。 1. 要有好文档。好文档要告诉读者这个项目的目的，使用方法和流程，注意事项和如何扩展等。最好能做成维基式文档，这样的话可以便于别人的参与。这个文档要有典型的应用案例，给出自始至终的过程指导； 2. 要有良好的测试方法和机制，并把它写入文档。有效和系统的测试是生产可靠、稳定、高性能、高扩展软件的必要条件！ 3. 如果有了规模，注意建立起自己的mail list，forum，group等，这样便于知识的积累，便于提问和解疑； 4. 要有计划性，这表现在有好的设计、蓝图和具体的任务清单（software specification，blueprint和To-do list）等，这样便于和别人讨论和鼓励参与； 5. 应当还有别的。先写到这儿，欢迎指正 🙂

接上篇。上次讲到建立自己的沙盘。这是一个开源软件开发的小系列，简单介绍下一些经验和体会。 凡是有点规模的开发，都需要有源代码管理。实际上，即使是自己编个程序、写个脚本或文档，源代码管理也可以提供很多的便利。 源代码管理经历了几代的沿革和发展。从最初的单文件加锁和没有网络支持，发展到具有网络支持的集中式控制代码管理，现在这种方式还是占据不少的市场份额。在共同开发方面，集中统一式的管理要求你必须先合并（merge）后才能提交（commit）。代表性的统一式代码管理工具和产品有CVS，Subversion，TFS等。在统一式代码管理系统下，我们只有一个总代码库（repository）。 最近几年开始流行分布式源代码管理系统。跟传统的统一代码管理不同的一点是分散式代码库：即每一个开发员有会自己的代码库实例。代码被改动过之后，开发人员可以先提交到自己的实例上，然后合并。代表性的产品和工具有Bazaar，Git，和Mercurial。 我用过CVS，Subversion，Bazaar，和Git。我个人的经验是它们各有利弊，当然我没有build engineer的经历，所以我在这方面的经验并不丰富。Linus Torvalds几年前在股沟有一个关于Git的讲演。他讲得不错，有时间的话值得一看/听。当然用哪一个系统（中央vs分布）在很大程度上取决于开发团队的技术强项、熟悉程度、公司的目标和制度。不过现在从长远来看，分布式的源代码管理是大趋势。 插点花絮。Linus Torvalds（Linux的主创）和Monty Widenius（MySQL的主创）都是以瑞典语为母语的芬兰人。Linus讲基本上听不出外国口音的美式英语，个性比较高傲。Monty的英语口音比较重，但表达没问题。口音不可怕，能听懂，可以把意思说出来就好。 从开源的角度来看，用什么代码库和工具在很大程度上取决于这个项目放在什么平台上。如果你感兴趣的项目在Launchpad上，那你当然要花时间学好bzr，如果是在Github上，就要练习好git。当然如果你是一个项目的发起者，你就可以自己决定用哪个平台。现在比较流行的平台有Googlecode，Launchpad，Github，SourceForge等。Launchpad只用Bazaar；Github当然只有git;Googlecode支持Subversion，git和Mercurial（应当是三者选一）;SourceForge好像只支持CVS和Subversion。 不管哪个平台，特别是分布式代码系统的东西，很多情况下你需要通过ssh来和托管机器（hosting URL或机器）交流，这就需要你自己的ssh key。如果你还没有，可以通过Linux系统上的ssh-keygen来生成这个外向和私有的key。生成了自己的id_rsa和id_rsa.pub的key文件之后，要把它们保管好，因为那个id_rsa.pub的key会被提交到Github，Launchpad等地。而id_rsa.pub是外向的，我们可以用它来和私有的id_rsa来验明你的身份。 选中了源代码管理工具和托管的机器或平台，你可以自己建几个Utility的项目来练习一下，如果你对源代码工具不熟的话。像在Googlecode，Github，和Launchpad等地很容易就可以建立起自己的开源项目，你可以放进去自己常用的脚本和自己写得小工具等。这即可以保存自己的脑力劳动成果，也可以练习源代码工具的使用。实际上在开源领域里做，bzr/Launchpad，git/Github/Googlecode等都要熟悉。常用的命令如clone，commit，pull，push，status，log，revert，blame等要明白和会用。 当然你也要知道怎样用diff来做个补丁（patch），和怎样来贴别人提交的补丁。这包括只补一个文件，多个文件，和多个分散在不同文件夹里的文件。关于运用diff和patch，这些东西只要可以接触到Linux的机器就可以练练。 说起diff，有很多的GUI工具比较好用。在Windows上你可以用开源免费的WinMerge。在Linux上我有时会用kdiff3，比较喜欢。我以前在公司里用Mac的时候，听说苹果的FileMerge比较好用，但我没试过。如果你用git和Linux，那么gitk这个GUI工具非常好，观看历史，分支，标签等都一目了然。我上次和MariaDB的wlad在一起，他告诉过我一个不错的bzr的GUI工具，好像是在Linux上，但我忘掉是哪一个了。 之所以讲diff，是因为我感觉在任何提交（commit）之前，你要再读一下diff。我以为这是一个最佳实践。阅读其他程序猿的diff也是一个好主意，这样你会对同事和合作伙伴有更多的了解。这也是一个非正式的code review，你也可能学到不少东西。 其他最佳实践还有要舍得用标签（tags）。标签不占地方，特别是在分布式代码管理上，但它却可以提供一个简洁明了的记号，便于管理和分类。另外，在提交时要写好的、言简意赅的短评。不要只说“bug 123 fix”，简要告诉我bug 123是怎么回事和如何改正。当然能做到言简意赅最好，如果做不到，没关系，以后慢慢提高，但请宁多勿缺，如果自己写不短的话，长一点没关系。 当然，在提交之前至少要过自己的unit test，并提交test cases。还要过其他的测试。测试太重要，以后会专门来写一篇。

接开门篇，这是个小系列。 古人说得好，吃一堑，长一智。又云：失败是成功之母。记得有位外国著名科学家曾经说过这样一句话：“砖家是在一个狭窄的领域里犯过所有痛苦错误的人”。总而言之，古今中外的经验告诉我们，人是在错误中成长起来，所以不要怕犯错。怕得是犯了错但不承认或不愿意从中学习。为了鼓励学习、尝试和应用一些新东西，把错误的成本最小化，我们可以做沙盘演练。而IT的沙盘，在很多情况下是虚拟机。（哈哈，哥想写范文。各位童鞋猜猜看，那句旁征博引用来讨老湿欢心的科学家名言，是我的编造还是真有类似的句子？） 下面是我个人的一些经验、体会和建议： 1. 建立自己的虚拟机，有Debian，Centos，Windows等。有了自己的虚拟机，可以以快照(snapshot)的方式保存基本的虚拟机器。在此基础之上，练习一些软件的编译和制作（compile and build），发现各个部分之间的依赖性(dependencies)，下载源代码并进行阅读和调试，安装一些软件和工具来尝试和学习等。如果做错了，可以打倒重建，没什么大不了的。所以要敢于尝试！ 我现在有一台联想的ThinkPad笔记本，用了Linux Mint 12 KDE的distro，然后自己下载并安装了VirtualBox。在此基础之上，我用Vagrant和veewee来构建和管理虚拟机，感觉非常给力。Vagrant和veewee的一个优势是可以用来比较容易地建立多机环境，web server，database server，proxy server等。我这有个介绍。 2. 用云计算服务来搭建自己的沙盘，虽然我现在用得少了些。 我在云计算厂商（Amazon和Rackspace）有自己的账户。我对国内的云计算厂商的运营方式不了解，但我一月初在北京时听说国内也有类似服务。我经常在Amazon和Rackspace上启动几个机器来做实验，因为花不了几个钱。像在Rackspace上起一个256MB的Linux虚机，一小时也就一美分左右。所以如果国内有这样的服务，自己开个户玩玩挺有意思的。 3. 购买自己的主机服务，一为练手，二为翻墙。 能翻墙是必须的，因为长城很弱智，阻挡了太多的科技信息和交流。每个国家都有网络监管并且也需要网络监管，每个国家都要采取措施来保证信息和网络安全，每个国家都想支持本国的IT发展并且也会出台政策和举措来保护本国产业，这些都无可厚非，没啥偷偷摸摸，不好意思的。但长城，和中国的不少做法一样，搞一刀切，那么僵硬、笨重和愚蠢，里外都不讨好，该想办法改进和提高了！ 翻墙的一个很流行的办法是VPN，而不少VPN是要付费的。这就不如在国外买个主机服务，因为国外的主机服务可以起到一石二鸟的作用：有了自己折腾的机器，同时还可以用来翻墙。主机服务不会比VPN贵到哪里去。有了它之后，你可以用国外主机来暗渡陈仓，搞个ssh tunnel上网，长城拿你没办法。但这要求主机服务允许你这样折腾，所以要注意用哪个厂家的。感觉Linode比较靠谱，因为看上去给你root，并且可以打倒重建。在这方面，冯大辉的这篇博客有不少好建议。搞个具备境外支付的信用卡也是个好主意。我几年前写过怎样用ssh在Windows上挖个地道来传输http的交通，那时公司内网管得紧。不知道现在还管用吧，但至少可以提供些关键词供你查询。 有了自己的沙盘，就可以无后顾之忧地在上面耍耍，满足自己的好奇心，多尝试和总结经验教训，我想就会慢慢提高自己的内功。