`
coolerbaosi
  • 浏览: 721944 次
文章分类
社区版块
存档分类
最新评论

熟悉的陌生人——软件工程

 
阅读更多
熟悉的陌生人——软件工程

去年暑假到现在是一个蜕变的过程!从软件工程到UML到设计模式再到三层架构(其实这些都属于软工的范畴),这是一条充满艰辛,充满曲折的道路,一路走来,感触颇多。

进入提高班,再次接触软件工程,让我觉得既熟悉又陌生。造成这种让人纠结的状态只能怪自己当时太无知。没有好好听大学老师讲课。不过也不必太自责,大家也都知道现在中国的教育现状。我想如果我当时好好跟着任课老师学,对软工认识的程度肯定也无法跟现在相比。很庆幸自己选择跟着米老师一直走下去。这个决定可以说是我长这么大最正确的一次!感谢米老师的悉心教导!

软件工程

软件工程,可以说是一门博大精深的学科。如果要用一种武功来比喻软件工程,那么我感觉也只有少林寺的《易筋经》能够体现出它在软件界的重要地位了。软件工程贯穿整个软件开发的始终,从设计到编码到之后的测试发布以及后期的维护,都离不开软件工程的思想。软件工程其实就是一种工具,将软件开发工程化,用科学的方法分析设计软件,为软件开发指制定合理的计划,最大限度的保证软件可以按时保量的完成。软件工程是一门需要终身学习的课程。随着以后不断的积累对于软工的认识会慢慢的加深,继续努力吧!

UML

UML是软件开发过程中一个非常重要的环节,可以说UML是软件工程的灵魂。它是对软件的整体设计与把控。UMLj将软工的思想绘成各种图,然后通过这些图加上设计模式,转化成系统的代码框架。有了框架,有了轮廓,剩下的具体实现的代码就可以一蹴而就。一气呵成了!
UML的四种关系——关联(组合、聚合)、依赖、泛化/继承、实现。还有九图都是学习UML的重点。九种图里面类图是重中之重。另外我感觉画时序图也很让人纠结,在做机房收费系统的时候,画的图就不太好,结果在写代码的时候就编写边改。着实让人头疼,吸取经验下次一定好好研究UML图。

设计模式

第一次用.NET做机房收费系统的时候用了一抽象工厂,稍微感受到了一下设计模式的好处。使用合适的设计模式可以让代码之间更加的独立,专业术语叫做低耦合。使代码更易复用。可谓好处多多啊。但值得注意的是,不要单纯的为了用设计模式而用设计模式。一定要结合实际情况,看看到底这里适不适合用设计模式,适合用哪种设计模式。这样才能发挥设计模式的作用,否则只会适得其反。总之设计模式是前人总结的精华,我们要用,更要会用,以便让它发挥最大的作用。想了解更多我关于设计模式的感受,请移步《大话设计模式读后感》

三层架构

三层的学习也颇费周折,这次米老师没有像之前那样给我们现成的资料,而是让我们自己去搜寻——为的是锻炼我们自己捕获事物,汲取营养的能力,从而让我们更适应大自然的生存环境。想要获得知识,世界上最大的知识库莫过于或联网,于是乎我就整天游荡于各大程序员社区——CSDN。博客园。51CTO等 都少不了我的身影。从那些大牛的博客里学习三层,逐渐的明白了三层到底是怎么一回事。
其实三层说白了就是将代码按照不同的功能分为不同的几个层,每一层都有自己的职责。例如负责跟数据库打交道的代码就放在DAL层(Data Access Layers),而一些逻辑判断就放在BLL层(Business Logic Layer)等等。说白了分层跟用设计模式用着异曲同工之妙,都是为了降低代码的耦合度,从而使得所开发的软件更易扩展、易维护。
分层也是一种思想,不同的阶段对于分层有着不同的理解。随着不断的学习,不断积累经验,对于分层的理解会慢慢的加深。

C#跟VB.NET

学习C#一是为了学习设计模式,因为《大话》中的代码是用C#实现的;而是为了让我们初步认识一下面向对象的编程思想。而学习VB.NET是为了从之前学的VB6无缝过渡到以后的面向对象。这一点很好的提现了米老师的“吃饭理论”——通过自己熟悉的知识去获得自己不熟悉的知识。

重构机房收费系统

又说到我们提高班的经典项目了——机房收费系统。这次重新做机房收费系统,首先是分层,然后又用了抽象工厂+反射+配置文件。而第一次做机房收费系统,用的是VB6,那个时候简直就是一个小白,什么UML、设计模式、分层都一呼不呼。所有代码都直接写到窗体下面,现在看之前做的东西,说难听点就跟屎一样!但是正是因为有当初的屎,才有了现在茁壮成长的庄稼!路是一步步走的,知识是一点点学的,所以不要在乎你现在有多差、水平有多低,只要肯努力,肯付出,再加上一个正确的方法,某天回头望去,发现自己已然到达了一个新的高度!所谓不积跬步无以至千里,不积小流无以成江海。说的就是这个道理,学习其实就是一个积累的过程。

合作开发机房收费系统

很无奈,又是它。这次你明白它为啥是提高班的经典了吧!合作开发主要是为了培养我们合作的能力,学习一下SVN的使用,同事也加深一下对三层和设计模式的理解。合作开发要比一个人开发快多了,这也是为啥要分层的一个原因,分层之后代码的耦合度降低,每个人负责一部分,只要按照一定标准跟规范就可以同时并行开发了,然后各自写完之后再合并,最后调试、打包就OK啦!这次合作没有什么太多的新东西,只是在原来的基础上加了一个外观模式。这次合作让我感受到注释说明很重要,如果注释说明写的清楚明白,那么几乎组员之间不用多余的交流就可以把项目做完,相反,如果写的不好,那么做起来就费劲了,写两句就要沟通一下,这样就没法进行下去了,而且还会带来理解上的偏差,这都会造成很多不必要的麻烦,所以合作很重要的一点就是制定好标准和规范。

结束语


写这篇博客真是不容易啊,因为之前的年度总结《我的IT之路2011(二)》里面已经对这一阶段进行了比较详细的总结,现在又重新再写一次,说白了就是用不同的话把一件事说了两遍,这对于我这个写作水平非常有限的人来说真是个挑战啊!还好写完了,好与不好各位多担待吧!不早了两点多了该睡觉啦!晚安各位!

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics