[置顶] 年度回忆录（2011.01----2011.07）

看了看上次的总结是2011年1月1日，距离这次的总结有将近七个月的时间，下面来说一说这七个月的学习情况（按照时间进度）。

l  英语（1月——now）

上次做总结的时候恰逢我们学完软件工程，过年的时候暂时放下了计算机的学习，开始了对英语的研究。其实说到英语学习真正学到的东西是很少的。因为不管哪门外语绝对不会在你学了几十天后有明显的效果，外语这个东西就是需要时间去打磨，需要毅力去雕琢的。

这段期间写了几篇关于英语的博客，都是情感性的没有什么技术性的总结（外语能有啥技术！）。外语嘛就是看，听，听，看……然后如此循环Until（ 自己真正有了英文思维）。其实关于“英文思维”这是老师的目标，对于自己而言开始的时候并没有这么“深奥”的目标。当时自己仅仅是希望可以听懂外语，能用外语和别人进行简单的交流。

但是不得不说的是，寒假的40天学习虽然没有达到这个目标，而且自己感觉关于英语的水平丝毫没有进展，但是令人欣慰的是自己不再讨厌英语，而是能听进去了。注意“听不进去”和“听进去”是一回事，“听懂”和“听进去”是另一回事。

假期在看英语时很多时候都是半睡半醒的状态，这是一个特别严重的问题。一方面我们要抛弃中文的思维来学习英文，把她当做母语来学，不用中文的思维去考虑；把自己当做婴儿来看待，想学就学累了就睡。一方面我们又要充分发挥我们是成年人的优势，就是能更多的集中注意力来进行语言的学习，而不是完全和婴儿似的每天最多集中几十分钟的注意力。

我们现在的问题是认真听但是听不懂，具体听不懂有两个原因：第一，生词不懂所以不懂；第二、说的太快。上面两种情况都需要我们要把听不懂的音与情境对应记忆，反复多次后就会有印象。但是婴儿或者几个月大的孩子他们的反复是高效的，想想你是怎么教孩子喊“爸爸”的？很可能你喊他几百遍“爸爸”他才喊你一声“爸爸”。相对而言我们的反复是低效率的，一个单词或者一个句子在这个视频中看完了，和情境对应了，但是等到下次再看估计是几个月之后了，不能说没有效果，只能说效果甚微而已。所以说我们需要高效的重复，于是现在自己就在做这件事情，一个视频或者音频反复的听知道理解为止，不在迷恋量的多少，而更加注重质的高低！

通过整个寒假的学习基本上适应了这种建立英文思维的学习方法。现在要做的就是坚持每天利用这种方法看英语，相信在不久得将来可以有巨大的收获，我相信！

 

l  计算机（寒假结束——now）

寒假结束后就开始运用软件工程的思想来重新实现机房收费系统。因为是第二遍做这个系统了，所以需求什么的很明确，于是就直接开始根据自己以前了解的需求动手画用例图。在整个建模的过程中再次复习UML的相关知识，并且在这个过程中熟悉了不同的UML工具（Rose以及EA还有PD等等）。在这一遍做的时候充分感受到了软件工程带来的好处，思路清晰，目标明确。与面向过程的方式完全不同的是，通过UML建模可以对整个系统的各个方面（从需求分析到详细设计）都能一一体现出来，做到了一行代码不写，也可以将整个软件的枝枝叶叶捋清楚。从用例图描述需求，知道整个系统要实现那些功能，然后开始画包图，包图的确定代表整个系统架构的确定，为了将系统的架构设计的更合理，更利于后期的维护，于是我们学习了三层架构

 

在系统设计阶段系统的学习了三层架构的相关知识，了解了为什么我们以前面向过程的那些个代码为什么难以维护，难以升级。原因就是之前的代码耦合度是非常高的，设计的好的话实现应该不是问题，但是后期的升级维护非常困难不敢轻易改动。添加功能还好一点，要是改动功能的话就可能导致其他的功能受到影响，当然添加功能到一定程度后整个系统的臃肿程度就不堪设想了。

三层架构的思想按照目前自己的理解一言以蔽之：解耦！

无论网上资料说的天花乱坠，归根结底就是解耦！因为他就为了实现快速开发、便捷维护、简单升级而出现的。也就是说用三层架构写出来的东西比面向过程那些代码要松散的多，这样的话一定程度上前期的实现可以分工合作，后期的维护避免了“牵一发而动全身”的尴尬。之所以说“一定程度上”是因为并不是所有运用三层架构的系统设计的都是那么合理，如果设计的不好就算用了三层架构照样耦合度很高。

通过分层一般得到界面层（UI）、业务逻辑层（BLL）、数据访问层（DAL）这三层。如果是多层的话也是由这三层衍生而来。比如在各层之间加接口，或者在DAL层下面在加一个SQLhelper层等等，都是些换汤不换药的做法，归根结底还是三层。分层结束后可以说整个软件的骨架就敲定了，然后就开始真正考虑每层的类的设计了。当然这一个过程中最先得到的应该是实体类，也就是数据库中表的设计。

 

在这一遍做机房收费系统的时候又复习了数据库比较高级的应用，例如存储过程、三范式云云。在这个过程中才真正体会到一个优秀的数据库设计对于一个高效的系统是多么的重要。三个范式保证了数据库中的数据不会冗余，提高了数据库的效率，为系统操作数据库节省了资源的消耗。而存储过程的应用提高了编程人员的效率，本来在代码中需要几个方法才能完成的任务一个存储过程就可以搞定，但是万事有利有弊滥的，用存储过程的后果就像回到了面向过程时代一样，强耦合的副作用将体现的淋漓尽致。具体的存储过程的使用可以看我的两篇博客：《存储过程懂不懂》、《存储过程进阶》

 

数据库敲定之后开始转到界面的设计当中去，开始考虑怎样将界面设计的满足用户的需求，这个阶段就是些拖拖拽拽的工作了。当界面和数据库确定后就开始了整个软件开发阶段关键的地方，同时也是UML建模中自己认为比较难的地方——时序图。

 

与此同时在考虑各层中类应该怎么设计的时候不得不用到的知识是设计模式，不得不提的是这次机房收费系统中用的最典型的设计模式就是“抽象工程加反射”来实现多个数据库的切换。设计模式的应用可以在这个时候考虑，也可以在系统完成设计后，进行对系统重构的时候考虑。由于“抽象工厂加反射”这个技术经常被用到，所以没必要等到系统完成后再去重构，于是在设计阶段就直接用之。当然在重构的过程中还会用到其他的设计模式比如：“单例模式”，如果每层之间都用接口的话那么整个系统就是一个“外观模式”等等。

 

时序图画完之后就开始进入了实现阶段，开始了盼望已久的敲代码阶段。如果时序图画的比较好的话，那么各层中的各个类的方法属性应该有个大致的眉目了。在这个阶段逐步熟悉新的开发环境——.NET平台，比较深入了解了这个平台提供的强大的功能；新的编程语言VB.net，再次加深了对对面向对象语言的理解。其实如果具有了编程的思想，就是记事本也可以写出非常厉害的程序，环境只不过是提高了人们的编程效率而已，而语言就更加不值得一提了。

在面向对象的世界里，万物皆对象，在做任何之前首先要考虑的就是封装、继承、多态。只有真正做到面向对象了，前期的那些建模分层工作才是有生产力的，不然的话你永远是用面向对象的语言、面向对象的工具来做着面向过程的事。和以前面向过程开发比起来没有丝毫的优势可言。写出的系统依然是一坨鸡窝！

 

开发过程中同样巩固了对编程标准的理解，软件的实现是每个开发者义不容辞的责任，但是写的代码让别人能看懂，而且是轻而易举的看懂则是一个更加高级的要求。更加重要的是这个要求绝对是检验是否是专业人士的标准之一。从变量的命名到方法的注释无一不体现一个开发人员的个人素质，而这个素质恰恰决定一个团队的成功与否。

 

个人版的第二遍机房收费系统完工后，就开始了投入到合作版的机房收费系统的开发周期当中。和个人版的流程是一致的，同样是需求——用例图、架构——包图、详细设计——类图+流程图+活动图。与上次个人开发不同的是更加需要大家的同心协力，而不是单打独斗。

只有合作的想法是不够的，还需要技术的支持，于是在这个过程中熟悉了对SVN的应用，熟悉了版本控制的操作流程。技术永远都不是最困难的，而人员之间的协调合作才是最棘手的，合作开发的过程中领悟到一个优秀的团队中不但需要有一个给力的领导，还需要各个组员之间进行有效的沟通，要懂得礼貌，要懂得尊敬。这些不只是要放在嘴上的，更要落实到行动当中，一个团队中任何一个小小的错误都可能导致系统不能如期完工。

 

合作版本的机房收费系统完工后C/S 的学习就告一个段落了，于是就开始了B/S的学习。首先是看了牛腩的新闻发布系统。根据一贯的类比的学习方法，通过对C/S和B/S的对比发现其实这两者除了界面层的实现方式不同之外其他的地方简直一模一样。看完了牛腩的新闻发布系统对B/S系统有了一个大致的了解，为了能做出更好的、更漂亮得界面于是开始了对html、javascript、jquery、asp.net、CSS+DIV的学习，这些内容目前正在学习当中。和C/S对比起来B/S的开发显得更加麻烦，所谓麻烦就是要注重界面的设计，在C/S系统中界面的制作只需要拖拖拽拽几个控件就可以了，但是B/S中不但要求逐步调整页面的布局，还要求满足不同浏览器的兼容性，有时候经常会为了一个样式调整半天，麻烦多多啊！

 

对B/S学习了一段时间后又开始了真正做工程的阶段，在这个阶段发现一个完美的系统是需要良好的“用户体验”的，保证系统能够高效的运行的确重要，但是一个令人赏心悦目的界面更是不可或缺的。界面布局、菜单设计等等这些都是给用户的第一印象。如果界面做的不好的话用户将不能正确的使用这个软件。而我们做软件的目的不就是为了服务他人提高工作效率么，所以说界面的设计的重要性丝毫不亚于后台的设计！

 

纵观自己的学习过程俨然就是一个软件开发过程的放大图，同时也是软件工程发展的缩小图。整个的学习过程：先理论后实践，在实践中去体会理论、完善理论。最后，配一图简要表述一下学习计算机以来的整个学习过程。