一个程序员的年终总结

时光荏苒，转眼我加入XX已经将近6年了，回首这6年，有很多感想和体会。在总结这最近3年的工作之前，首先非常感谢公司给我这个工作机会，以及公司领导和同事对我的栽培和帮助。让我在这三年里不管是技术上还是处理问题的能力上都感觉到莫大的进步。

20xx年n月-20yy年m月，这一年时间，主要参与开发XXXXDE项目，该项目的客户需求来源于国外一些大学，他们希望在将社会经济学和政治经济学理论通过类似课堂游戏的方式形象化表达给学生，而学生通过亲身参与更好的掌握理论知识。这方面的需求从目前看，仍然很大，很有前景。

在这个项目中，我主要完成几个新的实验的开发，根据客户需求，完善系统功能；根据系统运行情况，调整系统框架，参与替换服务端游戏框架，提升系统运行性能。另外，在参与项目开发的过程中，也逐步学习到一些项目管理的理论和实践。

XXXXDE这个项目对我们团队来说，是希望能做成一个产品，一个运营平台，老师可以通过上传脚本让其自定义实验直接运行在我们的平台上，或者针对于一些较复杂的实验，我们可以通过为老师定制的这种方式来销售服务，但后来该项目的发展走入了困境，我觉得原因有如下几方面：

1.从技术上来说，我们采用的是flex，在当时，它确实是一种新型而且发展势头很强劲的技术，它的富客户端以及和服务端JAVA技术交互能力都有很大的优势。可由于移动互联网技术的发展，flex的劣势就越来越突出，Adobe虽然后来推出了AIR技术，而且我们也曾经将EconVison的客户端使用AIR来重构生成移动应用，但由于Adobe技术的封闭以及其市场占有率过低，根本无法比拟ios的原生Object-C开发的应用。另外游戏框架的选择不当，以及后来的更换，也延长了项目开发周期。

2.战线拉的太长，人手不足。整个项目组开发人员只有我们经理某某，王某，张某和我，刘某后来加入，她亲切的称我们为XX第一小组，不过她这句话的重音是放在“小”字上，后来YY加入，但这个时候项目已经进行了两年了，仍然没有上线，有些为时过晚。

3.具体业务需求模糊，什么都想做的结果可能就是什么都做不好。虽然整个项目的大致目标是明确的：我们要做一个产品，一个平台，一个可以支持客户自定义脚本的系统平台，一个可以卖服务的运营平台。但是实际开发过程中的具体需求模糊，导致我们在很多十分细节的地方话费大量的时间，例如：CallMarket等几个实验，我们前前后后都做过好几个版本，需求以及业务逻辑各不相同，这些影响到了项目进度以及开发人员的势头，所谓一鼓作气，再而衰，三而竭，就是这个道理。虽然在真实的产品开发过程中，我们只能采取措施尽量减少需求的反复，想要完全避免是不可能的，但凡事都需要有个度，如果没有控制好，肯定会影响大家的情绪，如果这些情绪没有很好的释放，那就会影响到项目本身，毕竟工作是要人去做的。

XXXXDE项目虽然进展不是很顺利，但就像硬币两面，它同时也带给我们一些积极的东西，例如：知识和技术的积累，开发能力的锤炼和提高，还有一些经验和教训，最重要的是Charlize通过这个项目积累了一些人脉和市场资源，直接推出了Platform项目。

从2012年3月，我们项目组已经开始了解Platform项目的一些前期需求了，这部分工作主要是Charlize和王在做，后来MM和ZZ协作完成的一个Demo，打败了其他的竞争对手，让NXXn最终选择了我们。

2012年6月，我们刚确定了Platform项目的具体技术选择，以及整个大的框架定义，我刚开发Platform项目的客户端原型第一版本，一场突如其来的变化，改变了我们的团队结构，王X在上班路上出了事故，王X的暂时缺席，以及后来YY的离职，我们项目组又成了XX第一小组。

这个时候王找我谈话，希望我能接手这个项目的日常开发管理工作，从这开始我便参与到Platform项目的整个开发过程管理，对整个项目从需求到具体可能的实现以及前景等各个方面有了更深层次的了解和认识。

我的日常工作主要包括：

1.将王，刘某和Charlize整理的客户的需求转换成具体任务，并考虑具体实现方式，并做好任务评估

2.等开发周期内任务优先级确定后将已经确定的任务分配给组内开发人员，并录入Redmine

3.参与主要模块任务的开发和部分Bug修改

4.给测试人员提供每次开发周期测试功能点，以及具体需求，并分配测试出来的Bug

5.负责召开并主持每次迭代的Review会议

6.负责项目在各个服务器上的版本升级

这一年多的工作，度过无数个难忘的日日夜夜，数十个迭代，数十个版本，从整体看项目进展顺利，目前已经预上线运行，预计今年9月正式上线运行，有十多个学校会陆续使用我们的系统，而且NXXn后续会有更多的项目要和我们合作。从我自身看，通过这一年多的工作，学习到一些新的技术，提高了自己的开发能力的同时，也学习到一些项目管理经验等。

在这个项目开发中，我们目前采用的敏捷开发，迭代编程模式，这是一种对团队要求非常高的开发模式，给我们开发和测试以及管理人员带来很大的压力。几乎每天王和Charlize都要通一次至少一小时以上长途电话，几乎每两到三天刘某都要和TTT开一次会议，每周一Charlize，王，刘某和我都要开一上午的项目周例会，每天都会有大量的邮件发出或者收到，我们通过这些方式来沟通交流，我们使用Redmine，Redbooth和Email尽量做好记录。

在我们团队内部沟通方面，我们每天有站会，每个迭代结束有Review会议，开发过程中有疑问，随时沟通。我觉得我们现在已经有了一个相对稳定的制度和流程，哪怕这个制度还不是那么完善，我希望我们大家都能各司其职，尽量按流程来做，不要让太多的意外来影响我们的开发流程。

说起意外，我这里有一个记忆犹新的故事：2014年除夕夜，我正在看春晚，微信群里Charlize发来消息：

Charlize：“很抱歉，有个问题。…”（此处省略多少字）

我赶紧回复：“有服务端日志吗？”

Charlize：“有日志，是数据库操作错误”

王：“我一会儿上去看看”

Charlize：“等一下，我发上来。实在不好意思，大过年的”

后来还是王打开电脑，凭借他超人的思维想到了问题所在，把数据库中一个触发器的一段代码注释掉后，暂时解决了问题。我们过了个安稳年，Charlize在讨论过程中还关心我们：“要敲钟了，新年快乐！”。

这种意外有很多次，大部分出现在版本升级后的周末或者节日期间，现在想起来真的很对不起大家，说到底也是我升级的版本有问题，有些错误是我的版本控制由于种种原因没有走既定流程造成。

所以经过这么多教训，我真心觉得有流程和制度，就一定要遵守，当然不仅仅是升级流程。哪怕这个制度可能有缺陷，但是我们在没找到更好的制度之前，还是要遵守它，就像人生总有些东西是是很想达到却有可能永远到不了，但我们不能因此就不做了，我们要朝着它的方向努力，向它靠近。

下面这段话摘抄自领导的微信心灵鸡汤，也许能更准确的表达我的想法：“只要你奔跑，这个世界就会跟着你奔跑，只要你停驻，这个世界就会舍弃你独自奔跑。唯有你确定一个方向，使劲的跑起来，这个世界会为你而让路。”

最后，特别感谢我们的项目经理某某，他对我有知遇之恩，他是我的良师益友，他是一个机器猫，想要什么就有什么，他是个全能型人才，从他身上我学习到很多，而且要一直学习下去。但同时我也感觉到我们整个项目组包括我自己对他的依赖性特别强，这说明我们还需要继续努力。

END

往期热门文章