加入“考试系统优化组”已1个月有余。
初期，是对“考试系统”中错误进行排除(主要内容大多数是U层的问题)。后期，经过人员重组，并提出了一些新的“功能”(涉及到逻辑)。
由于初期只顾得解决U层中的问题，并没有涉及到业务逻辑，总觉得自己的收获甚微。主要原因在于自己总是被动的等着组长给你分配任务，自己并没有主动性去了解业务。只是为了完成工作而工作，并不是本着一种学习的态度去钻研。
建议："没事找事"!学习是主动，不能总是被动的等待别人给你讲。即便是有别人为你讲，前提也是建立在”你对系统有了一定了解”的基础上，只有对讲述的知识点产生共鸣，才会受益颇多。否则，也只是形式主义，收获甚微。
后期，领到的任务是”显示试题可用性等详细信息”。这次倒是涉及到代码逻辑了，只是要阅读别人的代码，甚是头疼呀!还不如重构呢?!
建议：值得肯定的是，阅读别人的代码，可以从中萃取出自己所需要的内容，借以提高生产力。其次，阅读别人的代码是一项基本功，是跟随代码猿一辈子的事情，又何必急在一时呢?当然，一般来讲，只有亲手写代码的人员才对自己领域的知识点熟悉。这时候，就该”主动去打扰别人了”。
开始阶段也只是在项目的启动地方设置断点，然后F11一步一步的去理解别人的思路，有种狗熊掰棒子的感觉。Tabel表中的if层层嵌套都把自己套进去了。想找实现此功能需要的B/D层的类、方法在哪里?虽然有文件夹做分割，但是找起来还是很费劲。因为对业务不了解，所以就不知道类的英文名称究竟是用来干什么的?尤其是，当你想添加一个方法的时候，还要去找一下，前人是不是已经封装了这个方法。
建议：领到任务以后。首先，要宏观的了解”这个功能是用来干嘛的”?主要分为哪几个步骤?而不需要从第一行读起。阅读代码的目的在于，了解全貌而非地毯式的读遍每一段代码。其次，要了解”这个功能是给谁用的”?他想要达到一种怎样的效果?倘若你只是忙于解决问题，而没有把落脚点放在为客户服务身上，那么也只是费力不讨好而已。最后，也需要对整个系统的框架、语言、数据库、命名规范有一定的了解。
总结：项目开发也好，项目优化也罢，都要本着一种主动学习的态度去对待。你付出的越多，收获的也就越多。其次，不要总认为U层的优化没有什么用途，工作以后，没有这方面的经验，你照样做不来!最后，开始任务之前，宏观了解业务很重要，前期的项目培训是必不可少的，这就需要我们的项目经理多费心了。
