有一个同学，问我一个问题：加入Tiny是否必须从写单元测试用例和文档作起？
此问题引发我诸多感触，故形成乱弹一篇。
作为一个新加入者，多看、少说，是正点。而这个时候，写写测试用例、文档，就是个不错的选择。这样入手比较容易，也比较容易体现水平。
可以说好的程序员，测试和文档都是写得好的。测试和文档一定写不好的，一定不是好的程序员。
同时，在看代码，写测试用例、写文档的过程中，还可以这样思考：
他为什么要这么设计？换成我，我会怎么设计？然后有相当一部分，会转化成：哦，原来是这个样子的！这个时候你进步了。然后有一部分留下来，让原作者转化成：哦，原来是这个样子的！然后他进步了，开源作品进步了。还有一部分，他会告诉你，故事是这样发生的，因此要如此这般，再转化成你的：哦，原来是这个样子的！！！于是你更进一步了。
其实写文档也是同样的道理，正所谓：测试用例就是程序，文档就是程序。
在你熟悉了相当一部分之后，你的发言权越来越大，你得到大家的认可越来越多，你的工作范围当然也会越来越宽广、丰富。
之所以说，多看、少说，是因为，这里的一切都你都还很陌生，许多故事，你还没有了解清楚，这个时候，多看，可以多发现他的优点、或者存疑的缺点，再慢慢印证，剔除自己理解错误的，留下真正存在的，这个时候，你就非常容易融入团队。
最忌讳的一种情况就是，只看了几眼代码，就这也不对、那也不好，可能你说的有几条是确实有的，但是更多的是你有些东西没有理解清楚，毕竟，要挑战别人已经仔细推敲、思考过的解决方案，需要有更深的分析、积累、沉淀。，如果你提得非常好、非常对，团队会非常感谢你，毕竟能做开源的，胸襟肯定是有的；如果总是拿自己的不仔细阅读、思考来浪费别人的时间，最后就难于融入团队。
当年，许多好汉加入水泊梁山，都要去做一点事情，表示你是真心愿意加入的，比如：下山去干一票，取个人头回来等等。在加入Tiny框架时，在你的真正水平显现之前，先做做测试用例和写写文档，也是这么个意思。如果写得测试用例质量好，还发现了原来存在的若干重大缺陷，怎么可能会不被重用？如果连测试用例也写不好，文档也写不好。也就意味着让你写代码，你也写不好测试用例，写不好文档，这对于开源组织来说是无法承受的。
所以，不要看不起写测试用例和文档相关的工作。
