软件工程

去年暑假到现在是一个蜕变的过程！从软件工程到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（二）》里面已经对这一阶段进行了比较详细的总结，现在又重新再写一次，说白了就是用不同的话把一件事说了两遍，这对于我这个写作水平非常有限的人来说真是个挑战啊！还好写完了，好与不好各位多担待吧！不早了两点多了该睡觉啦！晚安各位！