总结之H3C汇聚层交换机认证在线人数展示系统

前情提要：意外接了老师说的一个小程序，然后计划7天（实际10天）的小项目就冒出来了。

（1）时间与工程量。在和老师开始谈具体需求前，我凭感觉猜了猜完成这个小项目的时间。然后，再和老师确定需求后，再回头看我自己估计的时间。两个字，愚蠢。事实上作为一名理工生，做事应该讲究证据，而并非凭直觉下判断。工程量的确定，不是凭个人感觉就能OK的。正确的做法应该是在不断的实践中，对工程量进行估计，代码量或者每个模块需要的时间，锻炼自己这种估算能力。这点我差的远。从自己这次对这个小项目的时间统计和此前预计的对比，差距真大。

（2）关于项目延期的事情。最初答应老师7天后完成这个小项目，然而直到截止日期，我也仅仅将核心功能完成，然后，着急。还是向老师汇报了，这是第一次失败。然后老师肯定了我当前完成的工作，又给我延期了一天，结果还是没有完成，这是第二次失败。此时我“以为”相关的技术原型已经确定，于是老师又延期了一天。结果，未完成，这是第三次失败。这次我就不好意思告诉老师了，就自己默默再做了一天，完成后交给了老师，结果是完成。事实上，现在来看，第一次失败，原因是自己对时间规划不合理，拖延症。第二次失败，此前的单元测试不完善，功能集不完整，系统边界模糊。从而导致此前的返工，因此延期。第三次失败，高估自己的能力，对技术原型把握不到位。其中，自己存在一个很大的问题，第三次失败后，没有及时向老师反馈，这是错误的做法。应该及时告知老师。自己的心态还需要改变。将项目完成后，提交给老师。就项目延期的事情咨询了老师，老师给出的回答是没有几个项目能够不延期，尤其是初期的经验，通常都是惨痛的。如果有人告诉你一直顺利，他也是骗你的。我想还是我自己心态和能力的问题，对项目技术难度把握不到位，对时间把握不到位。实践不够。

（3）给用户呈现项目进度。在最初给老师展示完成的功能点时，我是直接录了个操作视频，发给老师，再加以文字描述。事实上我这种做法是错误的。用户不关心你是如何实现的，他需要看见的是用户需要中的执行流程，而并非系统的执行流程。同时，在向用户描述时应该是自然语言。给用户看见他想看见的。我的描述能力需要继续锻炼。

（4）项目中的技术原型问题。这次涉及到的编程语言有js(JQery)、java、html。具体技术java的servlet与jsp（html）交互、java中list转json、JQuery操作DOM元素、AJAX技术、highcharts、java多线程、java定时任务和js定时刷新。感慨，自己的基础知识真的很不扎实，看书+实践，查漏补缺。

（5）项目中风险最高的部分应该最先做。此前仅仅将这句话挂在心上，这次真正体会到了。此前未接触过java多线程编程，忐忑完成该技术原型，最初在怀疑中确定完成该部分，然而此后两次返工，多次失败后方才确定该核心模块符合期望效果。惨痛教训。

（6）在不断的实践中，才有可能成功。会坚持的人，会做的人更少。真正的执行。感觉很好。

（7）最后一点，言出必行，不轻易承诺，一旦承诺他人的事情就必须做到，若做不到，也应给出合理的原因而并非解释或逃避。这点能做到的人越来越少了。

送自己常说的一句话，“路漫漫其修远兮，吾将上下而求索”。

最后，感谢老师给了我一次救赎的机会，一次成长的机会。