个人工作总结

 
个人工作总结
 
 
2010-04-12 作者：ttion 来源：ttion的blog
 
一个人的软件工程

一个简单的网页、自助建站、个人Blog、CMS，这是本人自认的站长生涯，我人生的第一桶金也是来自个人建站，对“个人站长”这个词汇总会有点感慨，而一个人的软件工程即始于此，做的第一套系统的名称叫做“免费者内容管理系统”(最初的想法是想通过这套程序开源，建立一个中国的开源社区“免费者www.mianfeizhe.com”，后来整个域名和网站出售掉了)。

免费者内容管理系统，采用jsp+servlet框架（当时，只学了这些技术）进行开发，版本通过U盘进行控制，当时整体需求还算是比较明确的，因为是防系统，所以开发起来遇到不是业务上的问题，而恰恰遇到的是一些技术问题，前台静态化、模板标签，都是当时开发中的拦路虎，而此时回顾那些通过字符串解析、IO流输入输出静态页面，还是有些欣慰的，因为通过这些实现建立在这套系统之上的一套语言（模板标签），后来了解到的FreeMarker（模板搜索引擎）正是我所需要的。现在如果让我再去维护那套系统的话，我想我做的第一件事情就是推翻重写，以前的代码看起来真的太幼稚了，不知道再过一年来看自己的代码，我会是什么样的心态和感想呢？一个人的软件工程有痛苦并快乐着。

所谓的迭代开发

这是我做的第一个真实的项目，一个关于手机上网，无线网关的数据配置的开发，整个项目开发周期是3个月，采用迭代开发，开发人数6人，三天时间通过会议室形式了解需求，以及领取工作任务，然后便埋头投入到了项目当中，每天加班熬夜到10点钟左右，同时经常是加完班以后再回家吃饭，每天在心情极度低下，那一阵子经常容易忘事，有时候进入房间就忘记自己要做什么了。在开发过程当中，由于缺乏沟通，开发出来的东西总是会有些出入（包括开发与开发之间的，开发与需求上的），在后期测试过程当中，发现存取数据没有经过转码，页面过于复杂，导致用户体验是那么的不尽如意，后来差不多推翻了重新开发，再次进入无发估摸的开发过程当中，现在回想起来都有些后怕。我想是由于前期分析不足、没有有效的沟通、难以掌控的工作计划、个人编码能力等等，导致了整个项目的失败吧。当然，任何事物都是相对的，有坏的一面肯定也存在好的一面，通过这个项目，首先在技术得到了很大程度的提升，同时通过这个项目自己对软件工程的重要性也理解的更为深刻，也让自己对编码规范、编程思想引起了注意，态度的转变应该是最大的收获吧。

敏捷开发

近几年在软件开发行业，敏捷开发无疑是最热门的话题，而09年3月份进入的BMS敏捷项目组，也算是接触了敏捷，从项目开工会，Story评估会议，Story撰写，站立会议，持续集成，统一IDE构建，结对编程等等，对我来说都是新鲜的事物，这些新鲜事物总会让我着迷，一个又一个有趣的实践，让我感受到了开发当中的快乐，以前提交版本时的忐忑与不安，在这个项目过程当中，我完全感受不到。做完整个项目最大的感受——整体计划可控制，小粒度的Story可以让每个组员明确每天做什么。不再纠缠在无法估摸的项目进度当中，饱满的8个小时工作，整体工作效率有明显的提升。

敏捷的精髓是“充分沟通、坦诚合作”，敏捷当中的很多实践都是围绕着这展开的。

敏捷宣言：

– 个体和交互 胜过 过程和工具

– 可以工作的软件 胜过 面面俱到的文档

– 客户合作 胜过 合同谈判

– 响应变化 胜过 遵循计划

虽然右边的也有价值，但是我们认为左边的具有更大的价值

敏捷流派XP的价值观：简单、交流、反馈、勇气、尊重。

敏捷实践

Story评估会议

参会人员：开发、测试、资料（如果客户不能在现场，可由资料作为客户代表）、PM，会议采用举牌的形式决定Story的粒度，取最小的Story的力度作为单位，以举牌的形式决定一个Story的开发-测试结束周期，一般天数可写为：1、2、5、10、14、20（一般单位为半天），然后通过全体举牌的形式得出总分，再除以全体举牌人数得出一个Story的周期，当然，你有弃权的权利，所以准备牌的时候总会留一张笑脸来表示弃权。每一次参与这个会议时，总会让我感到比较的高兴，像极了拍卖会。

结对编程

结对编程此前是一项比较受质疑的一个实践，而经历过结对编程这一实践的人员，是最乐意接受这一实践的，至少我是。第一个和我结对的是个女同志，后来由于工作原因，她离开了项目组，而后我和项目经理结对开发，两个人一台电脑一个鼠标一个键盘，两个头脑，一个是驾驶员（敲键盘的人），一个是领航员（前后观察），两个人每过十分钟就可以进行角色互换。当然在项目开始前，挑选Pair时，一定是自愿的，且能够互相尊重的。有效的结对编程可以很大程度的保证代码质量，可以省去Code Review这一过程，同时这个实践也是非常容易培养新手。

本地构建&持续集成

在现在我已经很乐意去接收这个实践了，使用的CC作为服务器，此前由于机器内存不够，导致运行CC时，就不能做其他事情了，同时由于项目工程较多，在持续集成构建与执行上面花费的时间太多，所以此前总是有那么一点的反感，而当机器更换后、个人编码能力的提升、持续集成形成制度，接受持续集成也变得那么的水到渠成。持续集成就像一个炼丹炉，一直在运行的过程当中，而我们所做的就是一直往炉子里面扔代码，CC自动对那些代码进行检查，然后生成报告。持续集成是很好的试金石，通过持续集成也能提高个人的编码能力。

TDD(Test-Driven Development)

测试驱动开发，这也是自己一直在努力做好的一个实践，以前第一次写单元测试代码时总是有那么一些的不理解，当时觉得写这些代码是没用的，第一，由于项目组没有把测试代码作为交互物，第二，当时个人对单元测试代码了解不深刻，觉得是无用的工作。而在后来的重构过程当中，越来越认识到单元测试代码的重要性，有时候修改代码中的一个小点，都需要围绕该小点进行一次很充分的测试，浪费了大量的工作时间，同时现在项目组当中，将测试代码作为编码过程当中的一部分（新增代码单元测试代码行覆盖率需要达到100%，修改代码单元测试代码行覆盖率达到80%），自己对单元测试代码编写也越来越感兴趣，不过由于以前老代码过于复杂，可测性不高，在修改代码时，单元测试代码的编写总是那么的困难，在编写过程当中我们项目组使用了，反射、EasyMock等技术来编写测试代码，在维护代码时，TDD执行起来总是那么的困难，当然老代码是一个原因，个人的态度也是一个重要的原因，革命尚未成功，同志仍需努力！

TDD的意思是，在编码过程当中，先编写UT代码，他是简单的UT代码，此时可能会出现红灯，甚至编译不通过，根据UT编写代码，让UT代码一步一步通过，直到出现绿灯。在JavaEye中了解到有些项目组将单元测试代码作为交互物，替换掉一些文档，其实代码就是一个很好的文档，当然，你的代码要写的足够优美、简单。

站立会议(Stand up meeting)

第一次接触站立会议时，就感觉的比较的好奇，一块白板，所有人围成一圈，项目经理在中间，以结对组为单位，点到哪个Story时，相应负责人根据如下模板进行陈述。

“我昨天完成了...”

“今天要完成…”

“我遇到了…困难”

项目组是第一次执行敏捷，在大家反馈的时候跑题时，可爱的项目经理总会打断，会后讨论。

站立会议一般控制在15分钟之内，毕竟站着说话腰痛（这是个人理解的）。

我想站立会议，是很好体现敏捷流派XP的勇气、反馈、交流价值观的一个实践，你对问题进行反馈就需要勇气，反馈的过程当中就产生了交流，确实是一个非常有趣的实践。在执行过程当中，最好能按照上面的模板进行陈述，让每个人参与进来，今天是pair中的一个人员反馈，明天就换一个，同时项目经理对人员反馈时，不能带有个人情绪进行指责，我想这样一天的好心情都破坏了，同时在执行过程当中不要跑题、延长会议时间、开小会，毕竟其他人还站着呢。

重构

现在在项目过程当中，偶尔会停下来进行一次重构，第一次重构是整改一处查询，一是由于查询速度过慢，二是由于查询数据不太准确，而在我接手重构时，也确实头大了一下，十一个功能使用同一处代码（高耦合），其中的查询使用在代码当中拼接查询条件，有时改动其中一小段代码，都可能导致某个功能出现数据库错误，第一个想法是通过配置文件控制SQL语句，整理出一个SQL解析器出来，在这个方案执行了一天以后，由于时间原因，以及其复杂度、难维护性的原因，彻底的放弃了，第二个方案便是采用工厂方法和组合的设计模式进行解耦处理，在重构过程当中，总共分配了两名人员给我，在第一个方案失败后，施行第二个方案，由于时间问题，他们两个担任了测试的工作，从开发到测试，整体重构花费了4天的时间，查询速度由此前的2分钟降低到了2秒钟，代码彻底的解耦，设计的变得简单，当然由于使用工厂方法，日后维护工作量是增加了的。

第二次相对较大规模的重构是，项目组实施代码责任田制度，每个人领取一块代码土地，然后通过单元测试代码覆盖率，圈复杂度，问题单数量，代码结构作为度量项，进行评断责任田的执行结果，并予以相应的奖励。在重构的过程当中，我愈来愈感觉到单元测试代码的重要性，曾经歪了一首《勇气》重构版，聊以抒发对单元测试代码之情，“重构真的需要勇气，来面对流言蜚语，只要你一个单元测试，我的重构就有意义，我的真心！”。

重构应该是一个时刻进行的过程，曾经在JavaEye上面看到了一位仁兄说他们项目组的一件趣事，开发人员A在维护某个类时，五分钟后提交到配置库时，发现代码不见了，然后询问，这时候开发人员B说，我觉得这样实现不太好，我已经将那个类删除了。从这件事情当中可以看出他们重构的力度，每五分钟可以进行一次重构。我想我需要对此更加努力了。

Show Case(技术展示)

这个实践是在敏捷指导书当中看到的，然后，觉得这个实践非常适合我们项目组，老代码过于复杂，整体系统相对比较复杂，每个人都只是某个模块的专家。我想正好可以通过Show Case的形式来改善现状。由某个人提出某个模块，出发缘由可以是，由于遇到了难题，希望通过大家的力量来解决，可以是觉得自己这块代码的实现很好，希望展示一下自己的技术。同时，通过Show Case可以找出需要重构的代码，为问题找到更好的解决方案，这样大家也可以了解其他模块，不再是某个模块的专家。

我们项目组从我提出到现在，执行了三次Show Case，主要以解决问题作为出发点，但是由于讲解人员在展示时，讲的比较发散，没有注重点，结果收效不是很大，倒是成了Code Review。我想我们在进行Show Case时，第一，应该事前通知参与人员，能让参与人员有一个初步的了解。第二，展示人员应该掌握好注重点，不要浪费时间在无足轻重的事情上面，同时要把握好时间度，不要让这有趣的实践变得无味。

Show Case

会议目的:将工作成果展示给用户，获得用户的反馈，让团队所有成员了解项目的进展

会议形式：不限，可能只花15分钟,但是随时都可以进行.通过展示,也可能得到其他团队成员对被展示代码的意见.

展示内容：代码、测试代码、界面原型、重构代码、好的实践、新工具的使用、知识共享、教训、经验等都可以做为技术展示的素材.

参加人员： 开发团队、研发代表、客户

以上是我个人在工作上面的一些总结以及理解，在09年当中学习到了很多东西，在第一个项目组当中学习了技术，以及一些编程思想，同时在痛苦的加班当中，来到了第二个项目组，这也让我深刻的感受到了软件工程的重要性，如何工作，如何进行时间管理，我想这还是一个需要继续努力的方向。