有一個同學，問我一個問題：加入Tiny是否必須從寫單元測試用例和文檔作起？
此問題引發我諸多感觸，故形成亂彈一篇。
作爲一個新加入者，多看、少說，是正點。而這個時候，寫寫測試用例、文檔，就是個不錯的選擇。這樣入手比較容易，也比較容易體現水平。
可以說好的程序員，測試和文檔都是寫得好的。測試和文檔一定寫不好的，一定不是好的程序員。
同時，在看代碼，寫測試用例、寫文檔的過程中，還可以這樣思考：
他爲什麼要這麼設計？換成我，我會怎麼設計？然後有相當一部分，會轉化成：哦，原來是這個樣子的！這個時候你進步了。然後有一部分留下來，讓原作者轉化成：哦，原來是這個樣子的！然後他進步了，開源作品進步了。還有一部分，他會告訴你，故事是這樣發生的，因此要如此這般，再轉化成你的：哦，原來是這個樣子的！！！於是你更進一步了。
其實寫文檔也是同樣的道理，正所謂：測試用例就是程序，文檔就是程序。
在你熟悉了相當一部分之後，你的發言權越來越大，你得到大家的認可越來越多，你的工作範圍當然也會越來越寬廣、豐富。
之所以說，多看、少說，是因爲，這裏的一切都你都還很陌生，許多故事，你還沒有了解清楚，這個時候，多看，可以多發現他的優點、或者存疑的缺點，再慢慢印證，剔除自己理解錯誤的，留下真正存在的，這個時候，你就非常容易融入團隊。
最忌諱的一種情況就是，只看了幾眼代碼，就這也不對、那也不好，可能你說的有幾條是確實有的，但是更多的是你有些東西沒有理解清楚，畢竟，要挑戰別人已經仔細推敲、思考過的解決方案，需要有更深的分析、積累、沉澱。，如果你提得非常好、非常對，團隊會非常感謝你，畢竟能做開源的，胸襟肯定是有的；如果總是拿自己的不仔細閱讀、思考來浪費別人的時間，最後就難於融入團隊。
當年，許多好漢加入水泊梁山，都要去做一點事情，表示你是真心願意加入的，比如：下山去幹一票，取個人頭回來等等。在加入Tiny框架時，在你的真正水平顯現之前，先做做測試用例和寫寫文檔，也是這麼個意思。如果寫得測試用例質量好，還發現了原來存在的若干重大缺陷，怎麼可能會不被重用？如果連測試用例也寫不好，文檔也寫不好。也就意味着讓你寫代碼，你也寫不好測試用例，寫不好文檔，這對於開源組織來說是無法承受的。
所以，不要看不起寫測試用例和文檔相關的工作。
歡迎訪問開源技術社區：http://bbs.tinygroup.org。本例涉及的代碼和框架資料，將會在社區分享。《自己動手寫框架》成員羣：228977971，讓我們一起動手，瞭解開源框架的奧祕！
