一个程序员一个月维护经历的咀嚼

维护考试系统已经一个月有余了，乍一想来似乎没有明确的收获，可是，仔细回味一下却大不相同了。

背景：

正式接手考试系统是刚学完牛腩新闻发布系统没几天的时候。在这个阶段已经有了分层、设计模式、面向对象编基础、css样式设计、asp.net界面设计、sql数据库的一些基础知识。可以说这次运维是在.net平台上针对以上所学的一个综合运用。

学到现在做过的成型的系统也就一个机房收费系统和牛腩发布系统。机房收费系统是c/s阶段的一个小结，在这个阶段已经融入了软件工程和面向对象的思想，是设计模式和分层的一次系统性实践。牛腩新闻发布系统标志着开始进入b/s阶段。进入b/s阶段后主要学习了css样式设计，接触到了一些javascript，对asp.net有了一些了解。整体感觉进入b/s后界面的设计是与c/s设计差别最大的地方，同时融入了javascript脚本语言。b/s最大的优点就是不受空间的限制，而且b/s的运行机制与c/s也有所不同，具体内容这里不做赘述。

总结一句话就是：在维护系统的时候刚刚有了点初步的b/s基础。

学习方法的收获：

从刚开始接触系统的维护到现在，之间穿插着天轰穿和北大青鸟的关于asp.net控件、孙鑫的xml和牛腩的javascript的学习。可以说是这一个月的学习是在运维的基础上成长的。

这一个多月的学习进度是慢了点，但是感觉对我的学习方法和对程序的认识有了很大的改善。

在运维之前针对知识的学习都是先学习后运用，而在运维的过程中，并不是多有的语言都是很懂，比如说，js。虽然不懂得具体的非常细的语法知识，但是拿到一些代码之后，针对代码的意思可以看个大概，甚至在修改的时候，只需参照某种格式套用一下就可以了。换句话说，就是针对js的学习先经过囫囵吞枣式的运用，然后再回头研究、学习。

也正是在这样的模式下，对米老师针对我的弱点提出的整体把握，不要局限于某个点上的学习思想有了深刻的认识。

给我影响最大的有这么几次讲课。一次是跟随九期听米老师讲vb与数据库交互的知识，也就是数据库的入门。凡是都有它的“眼”，数据库的眼就是“数据”，无论是一条记录，一个表，一个数据库等等都是一个数据。数据库就是针对数据的增删改查，也即是说可以是针对记录、表和数据库级别的。从去年开始接触数据库到现在经历了一年的时间，却没有这么一个高度的概括。仔细想想，不是自己想不出来，只是学习的过程中缺少这样的高度实质性的总结。

“提纲挈领”、“纲举目张”。以维护经历为基础，结合米老师的教导，这一个月在这方面有了很大的改善。现在习惯性的在学习一门语言的时候就先去找到将要学习知识的“眼”。

这段时间在学习javascript，一方面要加快进度；另一方面，学知识的角度与高度改变了。经过这段时间的维护对学习方法的改善是这段时间来最大的收获之一。

说到学习方法，还需要说一下程序中整体思路设计的重要性。其实一些经典的算法往往反应了我们做事的最优思路，也可以说是一些经典思想的展现。给我影响最大的是动物学在信息采集室模拟测试的时候。因为需求改变了抽题的时候需要细化到章节。之前这段代码还不能正常运行，做了一下修改之后，可以将细化后的模板，写到数据库了。我自己在调试的时候仅关注了试卷的总分以及二次登陆是否可以修改到数据库。原本以为不会出错，可是仅仅30多人的测试就不少人抽到了重题。刚测试完，米老师到机房把握叫到会议室，同时还有七期的全部，根据我写的伪代码，剖析了一下我思考解决事情的思路。

有时候，我们做事情只是知道一个大概，距离实际实现还是有差距的。防止抽到重题的思路很简单，记录第一次抽到试题的id，第二次抽的时候检测是否已经抽到即可。如果做事情缺少清晰的整体架构思路，那么很容易就在看似小的事情上栽倒。我烦的最大的错误在于降低了标识抽题的布尔值的级别。本应该先假设一个值，如果抽到就改变布尔值。如果定义到第二次抽题的函数内部，这种做事的思路，就是不科学的。回来后看了看抽到重题的代码，犯的错误是类似的。第二次抽题的函数使用的判断标识根本就没有起到作用。原始的代码判断试题是否抽到的思路，不是比对id，而是在代码中直接为试题添加一个布尔标识。由于搀和了数组，第二次抽到的试题的数组中这个标示是不起作用的。

所以说，敲代码就是做事，重要的事放到的级别也是不一样的。清晰的思路，科学的方法，才会写出健壮的代码。这也往往是一些经典的算法给我们的启示。鉴于这件事，反映出基础不扎实的缺点，同样在学习的闲暇去咀嚼一下经典的算法，玩味其中的奥妙，既是非常有趣，又是一件非常必要的事儿。

总结：经过一个月的维护，意识到解决问题的正确的思路和整体架构的思想；针对知识去抓本质，注重知识与知识之间的联系与比对。

经验总结：

经过一个月的维护，感觉针对以前的学习有了一些潜移默化的变化，无论是在系统的架构还是敲代码的思路上，从根本上发生了变化。

因为深谙一个写死的程序会给维护人员带来多大的痛苦，所以，在架构系统的时候，第一反应就是如何保持系统的灵活性以及扩展性。

比如说，考试的分值，我们在设计之初应当尽可能适应各个类型的要求，如果一开始就设置成整型的，如果日后要有小数级别的分值需求，我们的工作量必定会是相当繁琐的，因为系统中肯定会有大量的地方涉及到。

维护本身并不重要，重要的是通过这次维护，发现学习中的问题，在维护的过程中优化自己的思路。通过维护整体上提升自己的程序积淀。

另外，这次使用考试系统的有近八千人，vb和公共课考试采用不同的考试形式。在组织考试的时候，要求有不同的侧重。

vb考试随堂考，持续了一周，一般的情况下五楼的两个机房同时在考。因为持续时间长，我不可能每次考试都在场，但是谁也不能保证不出现任何异常，另外还需要保证每个考试的学生都填写考生记录。所以安排了许多人监考。考试之前针对监考的人员，针对考试注意事项，做了简要说明。但是考试临近，很难在同一时间把所有的人聚齐。在组织管理上，还是缺少统一性。

近代史公共课考试是两千多人在二楼、三楼五楼同时考，一天内同时考完。在第一场考试的时候任课老师没有考生登记表，第一场考试有五百多人，而且题比较容易，不过半小时已经有人交卷了，当场应急，现做了一些学生登记表。虽然这并不是需要我们做的，但是我当时并没有想到这方面的事情，做事情还是缺少经验，从另一个方面看维护只局限于程序是否可以正常运行，眼光和思路太局限了。

经过一个月的维护，进度慢了点，但给我的编程生涯和以后的发展带来了重要的影响。