今天起，文章开头都会推荐一两首好听的歌曲，以符合行文的节奏心情，纪念我们流逝的青春。第一天先推荐，许巍的《时光》、《曾经的你》。
编程领域从架构上，可分为两大部分，框架开发和应用开发。
每个人都是从应用开发起步的，使用着各种官方或第三方框架。Java非常依赖各种框架，J2EE, Spring等。.NET一般只须.NET Framework。框架是现代编程语言不可分割的一部分，框架要精无须大而全，一个不足百KB的JQuery就改变了整个Web的面貌。
在实际开发中，对框架往往有两种不正确的认识：
一、把框架地位看得过高，往往发生在初学者身上。以为掌握框架就是掌握了这门语言。端着本上千页的《xxx高级编程》，啃得是头昏眼花，水平一点也没长进。ADO.NET、WPF、WCF这些，要那么高级知识干嘛？项目根本用不上。
二、把框架看得过于简单，一般出现于有数年经验的开发者身上。随着开发的磨练，对框架有了一些自己的认识，很多人开始自己建框架，又称造轮子，发到博客上觉得很不错。可如果用到实际项目中，这种“框架”会让未来重构痛不欲生。如果只是用来练习提高也不错，不过要注意表费太多时间，因为架构往往都很不成熟。我个人就有几次，自己累得半死，项目还无法保证质量完成，教训刻骨铭心。
开发框架并不一定牛，但能设计好一个框架一定很牛。那些少于10万行代码的项目最好不要搞自己的框架，没写到10万行代码，千万别在实际项目中设计“框架”。
如果确实想练练手，更好的主意是参加开源项目，Git和CodePlex上都有许多优秀框架，包括.Net Framework一部分的EF和MVC就在CodePlex上，Git上则应有尽有，最著名的就是Mono。
不想做将军的士兵不是好士兵，不想写框架的程序员是属于混日子的那种。这种程序员，即使做应用开发也不会专业起来。
我也没写过拿得出的框架，所以不能说怎么写，只能谈怎么学习框架。概括就四个字：边用边学。
具体起来，分作五步吧，无数大牛就是从这五部曲走过来的：
1. 掌握基本语言特性。类属性方法静态继承这些就算用不熟，至少能认出来。不用多说。
2. 找一篇好文章演练框架。这步很关键，一篇好文章就可以让你熟悉一个相对较小的框架，比如StructureMap。对于一个复杂框架比如Asp.NET，一篇文章可以让你完整认识一个方面，比如数据绑定。这个过程快则一天，慢则一周。
就我自己经验来说，不喜欢按部就班按示例，我喜欢这里变点那里变点，其实我是好奇而已，费时间多一点不过值得。
.NET BCL发展到4.5，已经有点臃肿了，迫切需要瘦身了。几百M几万个类，怎么可能死记硬背？知道引入哪个程序集，在哪个命名空间下能得到自己需要的API就好。
网上教程资源良莠不齐，而且很大一部分早已过时，对初学者来说，要找到这样的好文章真的很难。本文最后，将附上一些我觉得适合快速入门，又提供扩展想象的优秀文章链接，个人视野有限，希望大家提醒，将不断补充。
3. 在你的项目中应用，哪里不会就google，问同事，问社区。 边用边思考，这个API是否可以更方便，那里配置是不是用什么设计模式。初学乍练，我们经常并不是最恰当的方式用API，要有不断重构优化的觉悟。
开发应用时，要想着某一天要做框架。有时间的话，可以研究一下框架的源码。要注意不是研究其逻辑实现，重点在于其架构模式，以及跟其他框架、系统底层的交互，这是我们提高框架设计能力必备的。
不是做应用开发就不必了解设计模式，恰恰相反，做应用开发因为接触得少，更需要主动了解设计模式，以免成日陷于业务海洋中成了砖家，专门搬砖盖永远盖不到顶的业务大楼。而且有一些模式，应用开发中用的更频繁。对于架构模式同理。
不要用一些“超前”的模式或架构，如果不懂它们也不要紧，因为你的代码写得不够多，或者项目不够复杂。要紧密结合自己的项目，如果自己工作项目规模不够，可以研究开源。
昨天刚看到一个朋友，发文抱怨用EF时被Repository模式误导。这一方面确实要归疚于那些“大牛”，很多人都人云亦云，根本没指出甚至都没想过这个模式带来什么样的便利。另一方面，作者应该也吸取了教训，不要随便用你看不懂的东西，如果它确实有用，那就到你能领悟的时候再用。
关于此条和前一条，陈梓瀚的一篇“胡扯”可以看看。
4. 框架应用得日臻熟练，得心应手了。这并还不够，世上没有完美的框架。除了已死的框架，框架都是在不断发展完善，要不断学习框架的更新。如果你在应用的时候不断思考，就不会觉得跟不上，因为更新带来正好是期待已久的。
框架既然是不完美的，也一定有其生命周期。比如我们把WebService升级成WCF，就会大大提高扩展性，满足更多更复杂的需求。要注意微软有时候会出一些比较坑的框架，出一版就不再更新，比如Linq2SQL，所以至少要在第二版出来，功能性能大幅提高了再升级框架。
不少人说，技术更新太快跟不上，其实就是太懒而已。框架新功能开发速度，跟你应用的速度差了几个数量级。
虽然我曾经列过20条死于重构的理由，但我知道一定吓不倒前赴后继的勇士。好了，其实大家有一个百死不回的理由－为框架升级而重构，天经地义。出了事情怎么办，要么是框架的问题，要么是系统实在太烂，可以死得光荣瞑目了。
5. 在2、3、4步反复N次后，一个开发平台的主要框架了然于胸，开始框架开发之旅。
可能开始是构造一个个小的应用框架，一定要很谨慎地限制的应用范围，注意扩展性，免得以后难以维护。
不要重复造轮子，现有的框架可能有种种不足，但要想想你又不是铁道部的，别人一定要有充分的理由才会换你的框架。
专业的程序员业余时间可以写点休闲的代码，但任何时候都要设法令自己参与框架更专业。
要有专业的命名，别图省事或在命名上发挥创造力，要让大家都能接受，学《.NET设计规范》。
要有专业的文档，专业的注释。
要有专业的API，设身处地地想别人如何用你的框架，要考虑其他人的习惯，要考虑在各种操作系统、开发平台下的兼容性。
要用专业的标准，比如用W3C标准的Html，采用Unicode/Utf-8.而不是Ansi，不要别出心裁独树一职。
要有专业的分享，听取别人意见，可以让你的框架完善事半功倍，让你的框架和能力得到认可。
最后，最最重要的是，要有专业的态度，持之以恒，不管投身于自己的还是开源框架。只要不断努力，十年之后，你的名字一定会随着你的框架被时代所铭记。
个人认为BCL中框架按使用频率等，分为下面几个表格，等待高手推荐的攻略，欢迎共享。先奉上一篇自己找到并翻译的IoC框架StructureMap的文章。
一级框架：
| 框架名 | 速成攻略/指南 | 备注 |
| ASP.NET | ||
| WCF | ||
| IO | 包括Net IO | |
| ADO + EF | ||
| LINQ | ||
| Concurrent |
二级框架：
| 框架名 | 速成攻略/指南 | 备注 |
| XML | ||
| Reflection | ||
| Winform | ||
| WPF/Silverlight | ||
| Graphics | ||
| Workflow | ||
| MEF |
扩展和第三方框架：
| 框架名 | 速成攻略/指南 | 备注 |
| StructureMap(IoC) | StructureMap极速上手指南（翻译） | |
| NUnit(Unit Test) | ||
| NHibernate | ||
| …… |
特别是千锤百炼的ASP.NET，经过了MVC/Razor/Web API的发展后，需要一个继往开来的全新上手指南，如果实在找不到，很想自己写一个，非常有挑战性。还有蓬勃发展的Cocurrent编程，要总结一篇出色的攻略，需要有非凡的想象力。
学速成攻略，是降低工作压力，提高生活质量的好途径。不要担心所谓软件开发的内功，你以为是练九阴真经的白骨爪吗？天下有奇遇练成上乘内功的有几个呢？实际他们顶多是气宗，我们是剑宗，到底孰强孰弱，金老先生早就给了我们答案。