前几天看一些Go框架的源码和相关工具，由于之前没有在正式项目中用过Go，看起来是有些吃力的，有一种顾头不顾尾的感觉，到之后仍然是困于其中，不得精髓。这和本人的一些学习习惯有关：迷信源码，觉得只有理解其源码，才能运用自如，不知道是不是部分受于C/C++出身的影响，底层思维根深蒂固。之前看的一些框架(skynet,firefly,kbengine等)也是一样，虽然直接看的源码，但是由于缺少实践，对其运用场景，优缺点没有足够的认识，能够吸收的干货也比较有限。加之工作上开始忙起来，难免急躁，事倍功半。
于是开始反思自己的学习方法，在游戏服务器这个领域也有两年多了，对这方面的技术细节，常用构件，设计模式等已经非常熟悉了，了解过多种语言设计服务器的特性和方式，因此技术细节和语言障碍对我来说已经问题不大了，如果按照木桶原理来说，我觉得，架构设计，线上经验，解决问题的能力才是木桶的短板，而这一块需要恰巧不是深度而是广度，以问题为出发点，将多种解决方案纵向对比，能够选出一套合适的方案并加以实施，才是正解。换句话说，如果设计一个可靠，易于维护的服务器，才是目前我应该关注的东西。其它的工具，都只是实现这个目标的一种方案。关于广度的学习，我觉得分为三个层级：
- 了解：了解方案的出发点，适用情形，以及别人的经验教训
- 实践：在项目中实践运用，评估其优缺点，瓶颈
- 剖析：在必要的时候，通过源码验证自己的想法，并针对于现有问题进行改进/优化
如此看来，自己确实是有些本末倒置了，错把技术而不是解决问题当做最终目标，这并不是说技术细节不重要，而是合适的学习方法，能够让你站在一个更高的角度去理解事物的出发点，目标，以及其存在的理由，更高效地学习。另一个重要的点是，技术始终是为产品服务的。
第一篇水文就这样了，引以为诫。