写机房收费系统的这三个月，对写代码的认识更深刻了，对学习的过程也更多了点体会。

多敲代码：从软件工程到UML，C#,设计模式，再到vb.net。这个过程中只敲了敲教程中的代码，没实现过其他什么例子，也没想到用新学的语言敲一遍机房收费系统。代码敲的少的后果就是，在这次实现机房收费系统的过程中，开始的一段时间都用在了熟悉语法上。

做什么都有一个逐步提高的过程。当初想一下子把机房收费系统做完善，分层、加抽象工厂。当初三层和设计模式都是在刚刚了解的基础上，结果一起拿上来用，有种和别人吃饭，一桌子生人，想赶紧跑的感觉。

后来实在做不下去了，从新用简单的三层，把功能实现了下。然后再思考如何加设计模式的时候，感觉思路清晰多了。

一下子想把所有的方面都做好，结果所有的问题都混在了一起，弄的自己都没做的兴趣了。写程序一步一步来，到后来还写的挺带劲。慢慢的，很多问题思路就清晰了，可能之前没注意的问题也会提起你的注意。即使思路很清晰了，也写出代码来试试，看看哪块自己没有考虑到，看看哪块有漏洞。

做事情挑着容易的做，做的再多，可能对完成自己的任务没有帮助。机房收费系统的实体层和D层挺好写，然后有段时间就一下子把那都写完了，都照着一个模式，简单的重复。做事情，挑关键的做，促进事情整体向前走。我在机房收犯了这个毛病，什么好做做什么，结果关键的大多没做，因此整个系统很长一段时间内没什么实质性的进度，关键性的问题不解决，其他的大都白费。

思考太少了。遇到了问题，不知道该怎么解决，还没思考这个问题到底是个什么性质的问题，还没弄明白这个问题难在哪里，而是想都把视频看了一遍了，竟然遇到问题了。现在看着这个想法很可笑，当时真有一段时间是这么想的，明明把书看了一遍那，不该有问题的。肯定是在书上的某一处有解决方法，于是看书去了，用了很长的时间把书看了一遍，也许看完书都忘了主要要解决的什么问题了。于是时间就这样过去了。

遇到了问题先不急着寻找解决方法，先看一下问题是什么类型，为什么会出现这样的问题。思考过后，对问题有深刻的认识上再去寻找解决方法，就不盲从了。

在CSDN的论坛上搜一个问题的时候，在相关的搜索里有关于这个问题的方方面面，别急着找符合自己角度的那么先看一下这些解决方案的角度，为什么会有不同的角度，对问题和解决方法有一个整体的认识，然后再寻求最符合的解决方法，感觉这样学知识掌握的非常全面。

总之， 敲过机房收费系统之后，发现很多原来没以为是问题的问题。