技术
这一年里个人的技术感觉进步不是那么大。一方面技术之外的事情多了起来，另一方面由于工作原因接触的技术也较为杂乱，没有机会专注。技术的提升还是得靠业余时间。
系统分析设计
学了些RUP的方法，对规范化的系统分析设计算是有了一定认识。但这个东西在实践的过程中往往较难运用，好的方法学还是得看项目的实际情况而定。
单元测试软件
基于clang重写了公司的一个测试软件。因为之前有过一定的编译原理实践，本身我对编程语言也有一定认识，所以带领团队实现这个项目的时候也较容易。倒是对clang的研究，一直没有深入的机会。
浏览器前端
这一年里工作原因，对浏览器前端的一些技术有了更深的接触。后来还参与了部分编码，使用AngularJS和Bootstrap写了些代码。到目前为止对Javascrpt以及前端框架理念只能算有了个初步认识。也是希望能在这一块有一定深入的机会。自己写一个前端框架应该不难。
Erlang
基于之前做的dhtcrawler2，对Erlang有了一定的实践经验。使用函数式语言编写应用非常爽。主要体现在对集合的方便操作，以及lambda的应用。但Erlang的基础API确实不优美，接口的命名风格都存在一定的不统一。Erlang的进程模型非常酷，用来写服务器程序非常自然。进程相关的API比起同样是actor模型的akka好用太多。Erlang调优依然是服务器编程中无法回避的问题，虽然OTP提供了很多辅助这一过程的接口。
dhtcrawler2也存在很多问题，可惜后来实在太忙，已经没有时间顾及这种业余项目。
Scala
Scala到目前为止也是一门我比较喜欢的语言。它综合了面向对象和函数式语言的特性，基于JVM可以无代价地使用任何一个Java库，使得该语言在实际应用中没有什么阻碍。Scala的语法集很大，能被写出难以阅读的代码。
11月份的时候接了一个外包，我就直接选用了Scala来做，总算有了实践机会。在实际使用中越是发现Scala的强大。但对语言本身还深入的很不够，也希望在未来有更多的实践机会。
团队管理
适量的制度和信任
有那么一段时间很多很细的事情我都亲历亲为，对于整个项目的细节都掌握得比较清楚，对于每个技术实现方案也都是自己在做，后来发现这样太累，没有精力做更高层面的工作。所以，后来我就在这个度上做了些调整。仅做技术方案的大体制定，将分析设计的细化交给能够胜任的人。通过一份好的文档来做几次高效率的沟通，从而节省了我的时间。此外，这种方式也有利于培养团队成员编码之外的能力，对于成员本身应该也是大有益处的。
对于团队成员的信任，应该是一个逐渐累积的过程。这个过程中存在一定的磨合期，这个磨合期我觉得应该建立一些制度，用于实现沟通的有效性、工作的明确性以及部分工作的指导。这个制度应该保持轻量，尽量维持在不限制程序员的创造性以及造成厌恶情绪的程度。
团队氛围的营造
团队氛围我觉得是非常重要的，它可以与公司的氛围不一样。良好的氛围可以较大程度地提升团队成员的工作积极性，提高团队的战斗力。团队的氛围肯定是需要与团队成员契合的，这涉及到人员招聘的问题。
我希望我的团队应该充满技术氛围。程序员处在这个团队中，不仅仅是为公司工作，在项目中能够把解决掉的某个问题作为茶余饭后的谈资。成员之间应该可以在任何时候任何地点激情地讨论技术问题。程序员留在这个团队不仅仅是因为公司提供的待遇，团队本身的引力应该占到足够的比重。
要营造以上的氛围，我觉得Leader要做很多工作。可以包括：
- 适当且有效的技术交流，这其实也很难
- 一定频率的技术比赛，要适合每个成员的参与，也比较困难
- 技术热情的散播，Leader可以随时随地发起话题
- 项目问题的讨论
- 项目经验的总结及散播
此外，除了以上需要尽量做到的事情之外，我觉得有些事情是应该避免做的，包括：
- 工作时间与项目关系不太直接的纯技术学习。这其实本身是件好事，但其实反映了一个管理问题：某个成员的工作安排不够饱和。而一旦出现这样的情况，Leader不应该立即制止，而是分析项目情况以及成员的工作安排，通过及时安排工作来中断该行为。纯技术的学习，可以作为某个技术点交流会议的准备。
- 浏览技术之外的网页或其他甚至和自身技术提升不沾边的行为。我一般不明确制止该行为，但会同上一点一样从其他方面终止该行为。
我觉得，一个团队成员的不良行为，往往不仅仅是影响到他自己，这种现象通常会进行传播。
人员招聘
基于我喜欢的团队氛围目标，我会在程序员招聘时就进行严格的筛选。我一般不喜欢包含以下特征的程序员：
- 基础不好。我希望我团队中的每个成员都能成长为牛人，拥有较快上升特征的程序员也会给团队注入活力。而不管你是从事什么类型开发的程序员，我相信扎实的计算机基础才是成长的基石。当然，出于公司或项目原因，这个条件可以放宽。
- 浮夸。我喜欢踏实的程序员，会就是会，不会就是不会，不熟就是不熟，忘了就是忘了。实力可以从很多方面体现出来，但肯定不是每一项技术细节你都了解。当然，那种招聘5年C++程序员却嫌你不熟MFC的面试官本身就是一个问题，除非他明确地招聘一个MFC程序员。浮夸的特征不一定很明显，但是我觉得如果遇到一个能说会道的人，那就得小心点。
- 说话太冲。这个主要是担心以后难以管理，与其他人合作会有问题。在面试的时候我尽量表现的随意，希望面试者将面试过程当作一次平等的技术交流。但是，我觉得对面试官的基本尊重必须有。可能有些技术问题无法达成共识，但没必要在面试的过程中追根究底面红耳赤。我在面试过程中有几次坦白自己不太确定某个技术，也曾很自信地告诉对方可以私下验证一下我的结论。我的组员中还确实有人在入职的时候告诉我，某某问题我错了。我都能欣然接受，反而能增加我的好感。
由于我处在一个小公司，所以我不会对性格做过多的考察。我觉得，对于这样的公司，只要这个程序员不是内向到沟通比较困难，不是太自我为中心，就成。
人员招聘是一件需要很谨慎的事情。我可能在看人上还很欠缺经验，所以在过去面试的几十个人里（应该在50以下），我花费的平均面试时间大概在2小时左右。为了提高这2小时的有效率，通过有效合理的笔试题和简历研究来进行筛选是必不可少的手段。
适当的职责提升
这个同给予成员信任差不多。一个人得到别人的信任才能把事情做得更好，对项目本身也会有归属感。在项目的某些时期，明确地提升某个成员的职责，意义也在于此。当然这涉及到人员的挑选，我觉得有足够的责任心以及技术实力，就可以胜任这个角色。再往上的话，当然得需要一定的协调能力，能够协调一定数量的人员将项目的某一部分良好地完成。
项目管理
由于几个项目规模都较小，一个月的时间4个程序员就可以获得一个雏形。所以我感觉这些项目的管理方式更偏重于敏捷。在项目中有些活动是必须的。
项目计划
说法上我们称一自然周为一个迭代周期。在项目做完初步的分析设计之后，我会根据当时对项目的把握情况做出尽可能久尽可能详细的迭代计划。这份迭代计划会描述未来几次迭代周期应该完成的内容。项目里程碑在哪个时间点。
在项目开始的时候，每一次迭代开始我会更新这份迭代计划，尽可能细化当前迭代的内容。迭代的内容里主要包含开发内容，但也会包含需求沟通、分析设计、测试类工作。
项目总结
在每一次迭代快完的时候，我会及时总结当前迭代所完成的内容。这些内容一般都会与计划有些微的出入，有时候由于需求的介入、客户方的要求等等，实际完成的内容可能会非常不同。
除了在迭代结束的时候总结当前完成情况之外，在迭代中我也可能进行总结分析。其目的并不在于形成一种规范，而在于真真实实地辅助对项目进展的把控。
另一方面，当项目进度不再特别紧的时候，我觉得团队主要人员应该对整个项目的技术进行分析总结，一方面起到促进沟通交流的作用，另一方面也可以为团队沉淀技术实力和业务知识。
例会/周报/管理系统
在公司里做事往往需要对上对下。这么多感触，基本上都是对下的经验。公司高层虽然不需要像项目经理一样对项目做细致地把控，但也不能完全隔离项目的实际情况。有些规章制度总是需要的。这些制度对于程序员而言可能是一种干扰，但对管理层而言却也是必不可少的。
一套好用的项目管理系统，可以尽可能方便地让项目参与人员录入信息，也尽可能方便地管理层看到项目的大致进展情况，看到项目成员的工作情况。这也是目前我觉得我们做得不好的地方。
关于周报，我觉得在项目较空闲的时候是完全没有必要的。这个同某个成员在某个时间段较空闲的理由一样，这完全是管理层的问题，却要把这个问题转换为程序员编造工作周报的烦恼。但在项目较紧的时候，则是很有必要的。
工作例会，同很多沟通活动一样，我主张效率至上。在我能控制范围内，尽可能少地进行形式化的活动。例会的内容通常用于团队成员彼此之间工作内容的交流，让每个人知道其他人大概做的事情。同时，例会也是维持团队工作激情的一种简单方式。
总结
2013年下半年开始就一直很忙。最差的情况是：加班，加完班回去接着做外包，完了就睡觉。在项目里偶尔充当打杂的角色，哪块技术缺人就去补位。有时候又不放心别人的工作，又要去参合一下。公司里偶尔也有些杂物事。招聘人也费了不少时间，接触得多了发现来面试的群体都差不多，对自身的提高也失去了作用。
工作上偶尔觉得有压力。眼看快而立之年，技术没什么特别强的建树，钱也没挣到，生活也不免有了压力。
有时候想回去游戏行业，觉得专注一个领域才有长足的发展。但又没有特别吸引人的团队和公司。不太喜欢和国企的人打交道，虚来虚去，时间浪费不少。
越来越相信选择有时候特别重要。
希望2014年，自己还是能把眼前的事踏实做好。无论是技术还是管理还是个人收入，都能真正地上一个台阶。