2013年个人总结
时间过得飞快， 2013年就这么结束了。 一年过了，是时候总结一下。
今年我做了的主要的事情：
1. 完成售楼系统中几个功能模块的开发。其中涉及的主要内容包括：
i. 楼栋结构图生成方法
ii. 售中模块的多个子模块。
iii. 财务模块-收支管理 子模块。其中的对冲算法和权限控制有点复杂。
2. 参与建设和管理团队， 并且取得了一定成效。
3. 建立起组内的周会制度， 组织了多次代码审查。
4. 在组内进行了两次知识分享，主要关于Linq、扩展方法、Lambda、正则表达式。
5. 将公司福委会的日常事务下放，不再因福委会的事务影响正常工作。
6. 小学了一下python。 不过没坚持，时间很短，几乎可以忽略不计。
这么写一下，好像一年下来也没做什么事情。 当然其中的总结不包括各种看微博、QQ、聊天、休息、玩游戏的时间。 如果把这些事件都节省下来，用来学习和工作，那么一年能完成的事情应该会多很多。
那么接下来说一下今年的收获：
1. 对以下知识点的掌握和理解加深：
i. 委托
ii. Lambda表达式
2. 代码质量有所提高（ 其中包含对代码的组织、少数设计模式的运用）
3. 对团队建设与管理有了些自己的体会和想法
4. 对架构方面也有了些自己的想法。
5. 以维护性、扩展性、灵活性为首要目的的功能开发。 包括页面架构、JS代码、C#代码、解决方案，都会以这些目的来考量。
6. 思维更加开阔和灵活，触类旁通、举一反三的能力自我感觉已经比较强了。
今年想做而没做的事：
1. 自动化工具， 针对各个问题的自动化工具，包括自动生成页面文件、自动升级等
2. 学习python和其他新技术。 pythin只学了一点点，所以也算没做的事。
3. github上的个人小项目，如puzzle.js
工作中我的主要问题：
1. 自制力较差
2. 工作效率较低
用列表的形式进行总结原来可以这么简短。 那接下来还是加点文字的总结吧，不然总感觉这一年就这么简单的就过了。
这一年可以分为2个阶段。 第一阶段主要围绕开发，第二阶段主要围绕管理。
-- 第一阶段 --
在这一年的前九个月，主要是挣扎在CRM的开发任务中，比较忙碌 ，加上个人的私事，真是有点忙的喘不过气的感觉。 上班时要加班， 下班后还有事情要操心。 这段时间也是对代码质量的要求在不断提高的过程。 在开发任务中，大胆的采用了一些我个人的想法进行开发，这些想法没有借鉴公司其他人。包括：
1. C#中使用委托来实现类似JS中回调函数的做法
2. 将页面的内容组件化，拆分成一个个小的用户控件或页面（我称其为信息块），目的是让各个“组件”相对独立，尽量高内聚地偶尔， 让每个组件都尽量能被公用。
3. C#中使用更多的Lambda表达式和匿名函数。
通过这段时间的高强度、有目的性的开发和设计，我的开发、设计、架构、解决问题的能力都有明显的提高。
在这里，我想吐槽一下，在编码时，如果注重可维护性和可扩展性， 自然而然的就会用上一些面向对象的思想或设计模式， 即使我根本背不出这些思想和模式。 我认为现在很多人，把会不会面向对象思想和设计模式作为能力是否达到一定水平的评判标准，实在是有些过了。 我的主张是， 学习面向对象思想和设计模式没有坏处，但是不要神化他们。
-- 第二阶段 --
从9月底开始，我把关注的重点从技术转向管理。 在前9个月中，我能明显感觉到我们团队缺乏凝聚力。虽然我们团队的人均个人水平是比较高的，但是并没有像一个团队一样运作，完全是一盘散沙。而且由于之前一直是在赶工，所以代码质量也差强人意。接下来的2个多月中，我把精力集中在如何提高凝聚力和代码质量上。 这两点，我觉得是相辅相成的，最根本的是团队凝聚力。
先说说团队凝聚力，首先，这光靠我个人的努力是无法解决的，更需要大家的理解和配合。
首先，我通过向其他组学习和自己做功课，明确要做的事情有哪些。我发现我们团队内的沟通很少也很不畅。
所以第一步，我让大家对之前的开发写一些自己的总结，我知道大家一定有很多不满和抱怨，因为我也有很多；
同时通过讨论，定下了一些会议的制度（每周一开周会，每次会议要写会议纪要）和会议的纪律，以求保证团队内有充足沟通途径的同时，不因为会议占用过多工作时间。由于我们的系统在9月底已经完成开发和测试，所以工作相对比较轻松，这也为我做这些事情提供了好的前提。
在此之后，我发现虽然有效果，但依然不算太好，经过一番思索和向别人求教后，我听到一个说法： 当一个人表现出低积极性或凝聚力较差时，很可能是他的需求没有得到满足。
我一想，有道理。 我想，开发人员最主要的需求莫过于两点： 1. 薪水， 2. 个人成长。
薪水，我是无能为力了，至少当时是，只能在年末的时候，建议公司为其涨薪， 那我只能尽量在个人成长上满足他们的需求。而我也认为个人成长比一时的薪水更加重要。 我相信他们的看法也是如此。
于是我在日常聊天或单独面谈的方式，获知了大家对技术兴趣或个人发展的想法，并以此进行总结，整理到了文件中，其中包含各人的特点、兴趣、擅长等，也有我个人觉得能给予他们的帮助和支持。
其中我觉得面谈的效果很好， 因为之前忙于开发， 我也不负责管理， 所以我和其他组员之间，其实还是有隔阂的， 在经过单独的面谈后， 互相加深了了解， 隔阂自然就减少了。 也便于日后的合作和管理工作的开展。
那如何能帮助大家得到成长呢？ 我认为成长不是一蹴而就的事情，要持续的进行， 而我个人的水平其实和其他高工差不多，所以不可能靠我个人的单方面传授来让所有人达到成长的目的。 这时我采用的办法是：“三人行必有我师”。 也就是培养团队中分享的意识和习惯， 因为虽然我们平均水平差不多，但是每个人有其擅长的方面，所以通过分享，能让大家横向成长。 而分享的人，在分享前必须深入研究要分享的技术，进行纵向深入，达到某一技术的纵向提高。 如果能持续运作，那么我们的团队就能自发的不断提高。 即时没有外部人员和知识的引入， 也能实现组内成员单人能力越来越高的目的。 在不断的分享、提高的过程中，团队成员间的互相认可度也会越来越高，那么团队凝聚力也会越来越强。
当然，这些一切事情，都需要有人开头， 而我当然就顺理成章的开了这个头，做了前2次的知识分享。
好了，那么来总结一下如何提高团队凝聚力吧， 我觉得是有先后步骤的：
1. 团队成员需要认可其他成员，包括管理者
2. 团队成员需要认可他们的工作，不会认为那是无意义的浪费时间，觉得从中会有收获。
3. 为团队成员之间打通沟通的桥梁，不要让他们闭门造车。 例会是一个不错的方法。 但是要警惕会议泛滥和会议时间失控。 否则会议变成走过场，或占用太多时间影响工作的话，就很可能会有反效果。
4. 根据他们的需求， 给他们提供适当的支持，让其多参与感兴趣的工作， 尽量让他们根据自己的兴趣得到提高。
5. 针对经验较浅的成员， 给予适当的指导，主要是学习方法和解决问题的方法上的， 而不是帮其解决具体问题。 在遇到问题时， 可以尽量放手让他们独立解决。在其解决问题后，要给予肯定。
6. 针对经验比较丰富的成员， 给予更大自由度， 委派更有难度或更重要的任务， 让其体现价值。 对乐于帮助新人的， 让他适当辅导新人。 多让其进行技术分享。当然，也不能太放纵，否则误了他们，也误了团队。这个度只能自己把握。
说完团队凝聚力，说说代码质量， 要提高代码质量，其实方法还是挺简单的，就是代码审查。 这里有个前提，就是团队成员要互相认可，否则参与代码审查的积极性不高，一切白搭。
在不忙时，我们定了每周四下午4点进行代码审查，忙的话两周一次。有其他事情则改成周五早上。 在进行了多次代码审查之后， 大家对代码好坏的看法变得更加一致，同时更清楚代码质量的重要性。 我认为这对以后的开发、维护、功能扩展都有很大帮助。
代码审查时的讨论，提高了组内平均编码水平和团队凝聚力，也能纠正组内成员对一些小知识点的错误认知。
----------------------------------------------------------------------------------------------------------------
好了， 到这里算是总结完了。 对于2014年的计划，或者叫愿景， 另外写一个博客吧。
多谢观看。
写于： 2014/01/06-2014/01/07
