有一个同学。问我一个问题：增加Tiny是否必须从写单元測试用例和文档作起？
此问题引发我诸多感触，故形成乱弹一篇。
作为一个新增加者。多看、少说，是正点。
而这个时候。写写測试用例、文档，就是个不错的选择。
这样入手比較easy，也比較easy体现水平。
能够说好的程序猿。測试和文档都是写得好的。
測试和文档一定写不好的，一定不是好的程序猿。
同一时候，在看代码。写測试用例、写文档的过程中。还能够这样思考：
他为什么要这么设计？换成我，我会怎么设计？然后有相当一部分。会转化成：哦，原来是这个样子的。这个时候你进步了。然后有一部分留下来。让原作者转化成：哦，原来是这个样子的！然后他进步了，开源作品进步了。另一部分，他会告诉你，故事是这样发生的。因此要如此这般。再转化成你的：哦。原来是这个样子的。！
。于是你更进一步了。
事实上写文档也是相同的道理。正所谓：測试用例就是程序，文档就是程序。
在你熟悉了相当一部分之后，你的发言权越来越大，你得到大家的认可越来越多。你的工作范围当然也会越来越宽广、丰富。
之所以说。多看、少说，是由于，这里的一切都你都还很陌生，很多故事，你还没有了解清楚，这个时候。多看。能够多发现他的长处、或者存疑的缺点，再慢慢印证，剔除自己理解错误的，留下真正存在的。这个时候，你就很easy融入团队。
最忌讳的一种情况就是。仅仅看了几眼代码，就这也不正确、那也不好。可能你说的有几条是确实有的。可是很多其它的是你有些东西没有理解清楚，毕竟，要挑战别人已经细致推敲、思考过的解决方式。须要有更深的分析、积累、沉淀。。假设你提得很好、很对。团队会很感谢你，毕竟能做开源的。胸襟肯定是有的；假设总是拿自己的不细致阅读、思考来浪费别人的时间，最后就难于融入团队。
当年。很多好汉增加水泊梁山，都要去做一点事情，表示你是真心愿意增加的，比方：下山去干一票，取个人头回来等等。
在增加Tiny框架时，在你的真正水平显现之前。先做做測试用例和写写文档，也是这么个意思。假设写得測试用例质量好，还发现了原来存在的若干重大缺陷，怎么可能会不被重用？假设连測试用例也写不好，文档也写不好。也就意味着让你写代码。你也写不好測试用例，写不好文档，这对于开源组织来说是无法承受的。
所以。不要看不起写測试用例和文档相关的工作。
欢迎訪问开源技术社区：http://bbs.tinygroup.org。本例涉及的代码和框架资料，将会在社区分享。《自己动手写框架》成员QQ群：228977971。让我们一起动手，了解开源框架的奥秘！
版权声明：本文博主原创文章。博客，未经同意不得转载。