看了看上次的总结是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