今天起,文章开头都会推荐一两首好听的歌曲,以符合行文的节奏心情,纪念我们流逝的青春。第一天先推荐,许巍的《时光》、《曾经的你》。

编程领域从架构上,可分为两大部分,框架开发和应用开发。

每个人都是从应用开发起步的,使用着各种官方或第三方框架。Java非常依赖各种框架,J2EE, Spring等。.NET一般只须.NET Framework。框架是现代编程语言不可分割的一部分,框架要精无须大而全,一个不足百KB的JQuery就改变了整个Web的面貌。

在实际开发中,对框架往往有两种不正确的认识:

一、把框架地位看得过高,往往发生在初学者身上。以为掌握框架就是掌握了这门语言。端着本上千页的《xxx高级编程》,啃得是头昏眼花,水平一点也没长进。ADO.NET、WPF、WCF这些,要那么高级知识干嘛?项目根本用不上。

二、把框架看得过于简单,一般出现于有数年经验的开发者身上。随着开发的磨练,对框架有了一些自己的认识,很多人开始自己建框架,又称造轮子,发到博客上觉得很不错。可如果用到实际项目中,这种“框架”会让未来重构痛不欲生。如果只是用来练习提高也不错,不过要注意表费太多时间,因为架构往往都很不成熟。我个人就有几次,自己累得半死,项目还无法保证质量完成,教训刻骨铭心。

开发框架并不一定牛,但能设计好一个框架一定很牛。那些少于10万行代码的项目最好不要搞自己的框架,没写到10万行代码,千万别在实际项目中设计“框架”。

如果确实想练练手,更好的主意是参加开源项目,GitCodePlex上都有许多优秀框架,包括.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编程,要总结一篇出色的攻略,需要有非凡的想象力。

学速成攻略,是降低工作压力,提高生活质量的好途径。不要担心所谓软件开发的内功,你以为是练九阴真经的白骨爪吗?天下有奇遇练成上乘内功的有几个呢?实际他们顶多是气宗,我们是剑宗,到底孰强孰弱,金老先生早就给了我们答案。

posted on 2014-01-12 20:03  小城故事  阅读(4319)  评论(11编辑  收藏  举报