整理硬盘翻出来这篇年度总结，感觉那时的自己还是雄心勃勃的，行百里者半九十，无论怎样，贴出此文，一是避免遗失，放在博客上靠谱一些；另外一个，温故而知新，年终总结在2012年过了一半的时候看一看，也还是很有意义的一件事情。
正文开始：
2011年一年，flowSIM开发团队从4月份开始全身心投入开发，经过大半年的辛勤工作，在计划时间内（原计划是农历年底，即2012年2月，实际提前2个月）提前完成了公司下达的任务，这比我预想的要提前，这归功于一个好团队。
好的队友能够替你考虑设计方案，为你指出方案的缺陷从而避免了更大的灾难；好的队友写好每个接口函数的注释，让你调用起来很清晰，很放心；好的队友默默的把不规范的命名，混乱的逻辑梳理一遍，只是为了维护项目整体风格的统一；FLinker-FNode-FConnector-FLane的复杂关系，FCommand的莫名奇妙的错误，诡异的换道和跟车逻辑，复杂的侧边栏界面，难以理解的坐标变换……，这些困难的克服，都是队友们坚持努力的结果，首先要谢谢你们。
同时，在这一年的工作中也发现了自己身上经验与知识的不足。以前，工作中自己的角色更多的是一名工程师的角色。拿到一个项目，首先想到的是通过什么方法能够完成项目的开发工作，尽快交付。今年，由于队友们都比较能干，给了我更多的时间进行设计的工作，深刻感受到设计工作的重要性，好的设计可以给后期的编码工作带来“核裂变”效果的效率提升，目前看来fentityobject设计，composite模式，command模式，fview的设计基本上是设计模式在项目中比较成功的运用。而treeitem的设计，忽略了以唯一ID访问树形结构子项这一基本需求，给后期的编码工作和客户程序员带来了很多困扰，是需要重构的内容。
另外，如何防止随着开发工作不断深入，编码过程中，对原来设计方案的破坏和蔓延，以至于项目个别模块后期很复杂，除了构建这个模块的工程师自己，其他人无法维护，也是一个问题。这个问题的原因有两个方面：首先是设计方案本身具有缺陷，导致程序员在开发过程中不得不破坏原有约定以便达成既定目标；其次是工程师由于经验和编程风格的原因，没能写出和整体项目风格一致的代码。前一个原因需要更好的软件设计方案，后一种原因只能靠程序员不断积累经验。
对软件生命周期设计阶段和需求分析阶段的轻视，在国内软件行业普遍存在的，在flowSIM3.0的开发过程中，经过与国外同类优秀软件的对比，我深感差距最大的不是在技术上，而是在设计上，国外软件的一些设计思路可谓让人有拨云见日，四两拨千斤的感觉。而国内软件企业则过于急于求成，我想，这也是我们国产软件缺乏创新，只能跟着外国人鼻子走仿制路线的一个原因吧。
总之，感到对设计工作的投入是非常值得的，能够减少后期开发很多风险，这是我2012年工作中需要加强的。新的一年里，要加强设计方面的理论学习，包括设计模式、软件工程中的方法理论，同时，在开发团队内部积极推进软件工程的实践工作，提高项目整体质量水平，知行合一。
另外，就是沟通的问题，有句话说得好：“自己费尽心思表达自己的所思所想，最终别人能够听进去的最多20%”，可见沟通成本之高。在我实际工作的过程中发现，实际情况确实是这样的。你费尽心思想让对方理解的，别人能理解的其实很少，能够理解了完全照着你的想法去做，那更是很难。翻过来说，我也深感有时候想听懂一个程序员对我描述他工作中具体的问题成本之高，以至于我以很大的耐心听完他所说之后，有种听绕口令不知所云的感觉。
沟通问题的解决一方面要靠组内成员配合的默契随时间而增长，另一方面需要靠文档和项目管理工具。目前为止，应用最成功的项目管理工具是SVN，不但解决了多人协作代码同步，而且对配置管理，甚至是通过代码对比理解他人代码，都是很有帮助的，2012年准备在SVN的基础上实践TRAC，主推bug trace和内部wiki的功能。