一个女程序员第七年工作总结.docx

一个女程序员第七年工作总结今年的天气似乎特别暖和，虽说已经是冬天了，我们这里依然一片秋色。 （写于2011年11月7日）这是我工作的第七年，要是一段感情的话正是七年之痒的时候。如果在感情中每年作一份总结，是不是就不会有传说中的坎儿。我所在的公司不大，地方也不大。见识不广，深度不够，太多的随遇而安让我的工作这么多年都起伏不大，必须承认我骨子里就是个吃货和懒鬼。这篇文章仅仅是自己过去一年工作的总结，对于有理想有抱负的好青年就当看个反面教材然后鞭策自己更加努力吧。另外我现在的心境也是工作这么些年后的感受，欢迎阅读以前的总结，在那里你也许会找到共鸣。1、个人技术话说毕业头两年我觉得技术噌噌的往上涨，会了好多东西，然后的几年就缓慢爬行了。一个是我的工作性质是做应用的本来也不探讨什么高深的技术点，另一个就是自己懒没有好好利用时间充实自己。而今年64bit的普及，赖以生存的AutoCAD开始嫌弃古老的VB6，劳动力市场等等原因使我不得不接触掌握新技术。一些技术点，诸如SQL Server的spatial部分，把GIS的理论算法引入我所在的应用领域；利用AutoCAD的.NET类重新设计已有系统。Linq, C#多线程，WPF编写美观的界面等等。学习新技术是个享受的过程，觉得自己开始跟得上时代的步伐。当然如果项目时间紧的话也会有压力，总觉得用原来的技术很短时间搞定的东西，现在却大大增加了开发时间。和上一次系统学习比起来，这次自己就要稳重的多，虽然过去几年并没有在技术点上特别精进但是基本功更加扎实了，不会向上次那样不知道从哪里下手。这次算是心理有底有步骤有计划地学习，感觉好很多。技术点的学习与应用不仅仅对于我个人能力的一种提高，更是在很大程度上帮助软件重新架构。由于平台的转换，我们有机会对原有系统重新作分析、设计。以前的我完全是一个实施者，而现在所扮演的更多的是一个设计者。这种角色的转变意味着责任更大，如果出错就不是浪费我一个人的时间，而是从整体上浪费团队资源。去年写总结的时候我在寻觅软件设计上面的建议，今年系统的看了UML和设计模式。强烈的意识到从理解理论到灵活运用实在不是一件简单的事情。我的做法是从大的系统中选取一个相对独立的子系统，根据学到的理论自己搭个设计，想想再搭另外一个，跟团对讨论下，找找感觉。这个过程我大量依赖mindmap, flowchar, UML。 开始的草稿是Mindmap把需求细分，然后UML建立块之间的关系。UML是个好东西，虽然它的各种规范让设计在软件生命周期中所占比例加大，但是它对于细节的考量是非常到位的。如果我可以把所要软件的类图、顺序图画好那基本上就能证明这个东西我想明白了，另外还可以把它解释给其他组员。在设计思想上我一般会从业务逻辑出发，比较注重可读性，或者说是结构更符合人脑逻辑。除非在非常要效率的地方，一些函数，类的分布才会看起来不那么顺溜。每每这个时候一定要配有相关文档。之所以会这样一层一层的，大部分来源于自信心不强，没有这些图表文档的支持，我不确定是否能够把意思清晰准确的传达给团队其他成员，当然也不能够保证过段时间自己就不会忘记。目前我还在磕磕绊绊的前进中，真心希望将来的某一天我可以熟练运用UML工具，做个合格软件建筑师。对我来说做架构的过程是一个挑战自己决策能力的过程。毕竟软件是有生命的，它不断成长完善，或者某些部分在不久的将来被卸掉。我看不到那么远，设计时间太长影响工程进度，只能折中平衡。实施是同样的道理，同一个函数可以用不同的方法实现。平衡与博弈是超出软件设计与实施之外的能力，也就是俗话说的经验。在这个方面我还太嫩。2、团队管理 去年的总结里面我写了大段大段自认为的带领小团队的方法，如今总结为四个字：“敏捷开发”。年初的时候我的一个组员推荐我读了敏捷开发的书，才发现我那些实践中创出来的方法其实都是敏捷开发的一部分。建立在实践基础上的理论学习让人茅塞顿开。下面写一下除了去年那些方法我看过书以后觉得特别重要一定要记录的a) TDD(Test Driven Develop)。看过书才知道这个多重要，作为程序员，闷头写代码可以，但是如果写测试，很多人都会不情不愿的(尤其小公司，没有专门的人写测试的script)。但是Test case的建立对于功能的拓展，维护是相当重要的，虽然开头看起来写测试是麻烦了一点，但是这为以后节省的时间和资源是很大的。我所在的项目要是写script的话还是比较困难的，于是我要求我的团队写文档。b) 当我们结束每一个Bug/Feature是真的结束而非半吊子。结束就是包括代码、注释、对应文档等等。当团队Build那一天不会因为某个看似完成实际上还需要那么两三句话的Bug而耽误。c) 无论是否面向客户，每一个Build都是一个完整的msi(归档备案)。这样我们可以轻松的比较每个版本之间的不同。前两个月又有两个人归到我的团队下，我们开会规范统一了编码规范，比如每一个函数前都会加三个单引号(这个在.NET里面很好用，可以自动生成帮助)。比如如何命名函数、变量。其实经过一同工作，大家的编码规范已经在不经意中逐步统一，这次只是正式明确出来以便新的组员尽快上手。敏捷开发是现在比较流行的软件开发模式，我的认识是他非常合适8个人以下的小团队灵活作战。它充分发挥团队成员的主观能动性，可以比较及时地调整状态，降低资源损耗。虽然敏捷有正式的管理模式、工具，但一切一切的根源来自于团队成员间的坦诚交流、相互信任。这两样没有，根本敏不起来，大家心里都有自己的小九九，还不如不用敏捷。信任和坦诚这种东西没有硬性标准，只能靠团队慢慢磨和，也靠缘分吧。这个方面我的运气不错，组内合作讨论的气氛非常好。从这些比我勤奋比我有经验的组员们身上学到了很多东西。目前我们组的这个运转模式得到了部门经理的认同，已经升级了现有的管理软件，我就可以比较规范的依据敏捷模式管理了。今年我们部门作了一次人事变动，去年提及的那个不作为的经理走了新来了一个。在一定程度上我需要辅助他的工作，这也给我提供了一些作为代表参与部门间会议以及决策层会议的机会。一种会议是传递意见给大家，需要演讲。对于正式的演讲不够自信，总怕不能准确表达自己的意思。于是搭建了演示平台，特别作了事例分析，作了ppt用作主脉络。效果意外的好，得到了很多积极的反馈，对于以后的开发思路很有帮助。另外一种是听取意见的，售前的哥们很能吹毛求疵，挑得毛病那个细那个偏。关键还不早说，开发周期尾端才说，一改又是麻烦。以前这样的会议我不是主角跟着听听就好，现在成了主听者，第一反应就是抵触、辩解。但是轮到我说话，我都只能说对不起，我们没有考虑周到，下次会注意，也希望在开发进程中多多交流。能有这样的态度也是工作时间长了的缘故，初出茅庐的时候应该不会这样说。“对不起”一说，明显感觉到售前松了口气，开发和销售本来就不是两个对立面，只有把这样挑的毛病细化，在开发进程中循环出现才会减少不必要的成本浪费。我们是小公司，这些个互相交流指正不需要大家很正式的到会议室坐下，就是互相串门子的时候带一句。做开发的把态度摆出来，欢迎各种意见建议，人家自然也就愿意过