从4月25日到5月6日，历经十二天，终于把课设的编码部分完成了。我还没有沉湎于完成作品的狂喜中，相反，我在以一种怀疑的、批判的目光审视它。我在以做一个反省，对自己这十天来的工作做一个总结。马马虎虎总算是达到了给老师交作业的基本要求，但是，离我的实际预想，还差得太多。
我看着自己的代码，就想看着一件到处是破洞的衣服，心中不断泛起一丝丝想吐的冲动……我没有夸张，呵呵，各位看官莫怪，目前作为一个低效、危险的程序员，我只想说：OK，我又完成了一件“垃圾”，但是，垃圾也有用处，失败的作品也有其独有的作用——供我反思，反省。
先简单回顾一下我的经历吧：4.25，写了4个小时代码；4.26，发现4.25的代码不能继续做了，删掉，重做，3个小时；4.27，把4.26的代码删掉重做，3个小时……4.28~~5.02，学会了，每做一个小时，就把代码保存一份，这段时间主要精力都放在界面显示上；5.02~~5.06，这三天其实只编了3小时。
误区1：对问题没有足够的理解，就急急忙忙上手编代码；
误区2：不明白工作的重心是在网络异步通讯，而花将近一半的时间在界面上
误区3：在对MFC架构是太熟悉的情况下，贸然选择自己并不熟悉的方法来做，导致花费了大量的时间。（本来在单文档结构下很容易可以事件窗口划分，我却要自己去重写在对话框基础上的划分窗口）
误区4：在一开始就想要把整个项目事无巨细得考虑周全，而做到最后发现刚开始考虑的问题只有50%不到是有用的
误区5：VC使用不够熟练，文档组织混乱，不善于利用插件和调试工具。
误区6：不善坚持（在此要多谢钟老师，在我想要放弃的时候给了我信心和很大的帮助）
误区7：不善于使用MSDN
在此，转帖一篇51CTO的文章：
我常年程序员的经历让我知道了一些关于软件编程的事情。下面的这些事情可能会让朋友们对软件开发感到惊讶：
1.一个程序员用在写程序上的时间大概占他的工作时间的10-20%，大部分的程序员每天大约能写出10-12行的能进入最终的产品的代码——不管他的技术水平有多高。好的程序员花去90%的时间在思考、研究和实验，来找出最优方案。差的程序员花去90%的时间在调试问题程序、盲目的修改程序，期望某种写法能可行。“一个卓越的车床工可以要求比一个一般的车床工多拿数倍高的工资，但一个卓越的软件写手的价值会10000倍于一个普通的写手。”——比尔盖茨
2.一个优秀的程序员的效率会是一个普通的程序员的十倍之上。一个伟大的程序员的效率会是一个普通程序员的20-100倍。这不是夸张——1960年以来的无数研究都一致的证明了这一点。一个差的程序员不仅仅是没效率——他不仅不能完成任务，写出的大量代码也让别人头痛的没法维护。
3.伟大的程序员只花很少的时间去写代码——至少指那些最终形成产品的代码。那些要花掉大量时间写代码的程序员都是太懒惰，太自大，太傲慢，不屑用现有的方案去解决老问题。伟大的程序员的精明之处在于懂得欣赏和重复利用通用模式。好的程序员并不害怕经常的重构（重写）他们的代码以求达到最好效果。差的程序员写的代码缺乏整体概念，冗余，没有层次，没有模式，导致很难重构。把这些代码扔掉重做也比修改起来容易。
4.软件遵循熵的定律，跟其它所有东西一样。持续的变更会导致软件腐烂，腐蚀掉对原始设计的完整性概念。软件的腐烂是不可避免的，但程序员在开发软件时没有考虑完整性，将会使软件腐烂的如此之快，以至于软件在还没有完成之前就已经毫无价值了。软件完整性上的熵变可能是软件项目失败最常见的原因。（第二大常见失败原因是做出的不是客户想要的东西。）软件腐烂使开发进度呈指数级速度放缓，大量的软件在失败之前都是面对着突增的时间要求和资金预算。
5.2004年的一项研究表明大多数的软件项目（51%）会在关键功能上失败，其中15%是完全的失败。这比1994年前有很大的改进，当时是31%。
6.尽管大多数软件都是团体开发的，但这并不是一项民/主的活动。通常，一个人负责设计，其他人负责实现细节。
7.编程是个很难的工作。是一种剧烈的脑力劳动。好的程序员7×24小时的思考他们的工作。他们最重要的程序都是在淋浴时、睡梦中写成的。因为这最重要的工作都是在远离键盘的情况下完成的，所以软件工程不可能通过增加在办公室的工作时间或增加人手来加快进度。
看了这篇文章的前三条，我很肯定地给自己一个定义：差的没有效率的程序员。
认识到自己的不足是好事，因为这意味着你将从此开始进步，下一刻的你会比现在的你更加优秀！！！