前言：读完“一次亲身学习经历”后，感慨良多，也感觉到自己在学习中走了很多弯路，因此根据自己的经验有了下面的文字，或者说是工作几年的一个总结吧，希望能给正在摸索的同志一点启示和帮助，也希望园子的人也说说自己的方法。文中如有偏颇，欢迎拍砖。

每个人的资质、能力都各有不同，因此修炼的方法就因人而异了。大多时候各人都是靠自己摸索，或者找个参照物照搬其方法（这个大概是因为我上学的时候，老师调位子来诱导自己这样做的）。网上也有不少人发帖询问，我看回答不外乎：多看书，多看MSDN，多实践，多提问……，然后不少人推荐出一些大部头，小部头书籍来，对于他们来说修炼就是这么简单，一句话就如同一颗灵丹妙药瞬间就让你傲视群雄，初学者听了似乎马上信心百倍，可是回头想一想仍然一无所获。

就o看来，人类的学习历程就是学习经验然后再创造。

学习经验可以依靠自己，也可以依靠别人传授（当然依靠别人传授也会相对快捷，但是其质量不一定高，毕竟化功大法和北冥神功的高下很容易分辨的出来的）。看完“学习历程”后o归结了几个要点：

1、举一反三

要从学习过程中，要从碰到的问题中掌握当前的知识，同时也要发散性的扩展到相关的知识点上面。就这点来说我看许多人是说到做不到，包括我自己也是，大多时候都是浅尝辄止解决问题本身就了事，并没有去看看相关的问题，这样学习起来到头来只能事倍功半。可是如何发散性的来掌握知识？这应该是和自身的积累相关的，比如“学习历程”提到的编码问题：

1）         因为我是开发人员，我会首先想到.net中使用c#如何来得到各个编码的数据，并且他们之间如何相互转换。

2）         因为我前段时间看完了AnyTao的“你必须知道的.net”一书，深受其“掌握底层以不变应万变”的思想影响，我会去看看具体的IL代码以及reflector下framework来学习下相关的东东。

3）         因为我目前在阅读设计模式的书籍，我还会考虑到如何合理的编码来应对今后不同需求的变化，是采用策略模式？简单工厂模式？还是其他多种模式的综合？

4）         因为我今后还想做架构设计人员，我还会考虑到如何定位这个模块？如何设计这个模块和其他模块的交互，同时也能方便今后的扩展？

5）         ……其他能想到的东西。

其实只要你专心的去想，你能由一个问题想到很多问题，不是有句话叫：懂的越多问题越多吗？人的想象力是无穷的，通过想象力来学习，相信只要你坚持不懈一定会取得意想不到的结果（当然是好的）

既然做了技术这行，既然知道这行更新快，那我们就应该在平时对于过去、现在、将来进行积极的思考，我以前那里没做好？我现在这样做合理吗？我将来如何改进？

每天我们都会碰到许多问题，有的自己能够解决，有的需要借助外力比如网络比如同事，来帮助解决（o非常欣赏海贼王中lufee义正言辞的反驳个体强大论说：因为我做不了。人无完人，每个人都有自己擅长的和不擅长的，只要相互帮助才能战胜一切困难），解决问题固然重要，但是问题背后的东西不是每个人都想去追究的。以前o在CSDN上混的时候就发现大多数人当问题解决后就不管了，只有极少数人会穷根究底的探索，而且许多通过google通过msdn就能很快找到答案的问题几乎每天都能在上面看到，这只能说明许多人都是为了问题而问题，这样的学习是最没有效率和前途的。

2、万法归一

看到很多人抱怨微软的东西更新的快，更新的多，让很多人无所适从；也看到一段时间语言优胜论的讨论；也看到在讨论LINQ的存在合理性……

O觉得学习的最高境界是无招胜有招，一切皆梦幻泡影，一切皆浮云：）

归根结底就是要掌握、抓住事物的本质，这种境界如果不是天才没个长时间的修炼是无法体会得到的。

该修炼也是一个由专而博，然后博而专的过程。

何解？

人总是有好奇心的，因此在学习一门技术的同时免不了对于其他的技术也有强烈的求知欲，通过学习一门技术也了解了其他技术，并且也对比下解决同一个问题的差别和共同点，从而加深对正在钻研的技术的理解，是有极大裨益的。这就是所谓的专而博，不过值得注意的是，我们在博的同时也得适度，贪多嚼不烂嘛。

随着学习的深入以及不断的思考总结，对于不同技术的相信也会有了较为成熟的看法。这样解决问题就不会单向的看而是多方位立体的看待问题，不拘泥任何一种形式、技术，不拘泥与某一块某一部分，而是牢牢的把握住问题的关键和核心，从而有效的快捷的解决问题。这就是博而专。