rest, reset, ready for a new generation.
十一好好休息了一下，并回顾了一下最近一段时间的工作，感觉到自己的戾气越来越重了，前几篇文章写的就有点火药味，愤怒来自于压力，来自于恐惧，大抵是没有错的，如此十足的火力，是不是也同样地预示着自己的心虚呢？
心虚是有原因的，觉得这半年在公司的表现非常不好，力主做了4个系统，各有各的问题：
1、UI部分的数据绑定机制。
其实当时是刚赶上一个版本，分配的任务是两周内完成UI地图系统，就是WOW那种地图。这个纯属自己逞能，觉得能搞定就光膀子上了，结果完事完成了，产生了两个大问题：一个是编辑器一直以来不太好用（加了三天班赶出来的，各种硬编码），一个是整个数据绑定核心机制做在Flash层次，性能有问题（废话）。
14天的时间，其实要完成的东西哪个都不是善茬：客户端原本不支持的Reflection、数据绑定核心、熟悉原来不熟的Scaleform、Flash完成UI地图控件和标记（虽然基于数据绑定但总得调试吧）、以及为了方便编辑而制作的WPF地图编辑器，并且完成了跟Cry引擎的数据交互。回顾一下，想在14天内把这些都做好，我简直太TMD把自己当回事儿了。
现在，有些坑交出去了，比如数据绑定和Flash那些，但是地图编辑器这个大坑还自己留着，如果有个评语的话，应该就是活该吧。
2、Reflection系统。版本完毕后，安排的任务是两个月内完成技能系统改造，而新的技能系统我挑选的方案也是11年、12年轻车熟路的方案——基于类Kismet的方式来完成。但是，不幸的是，Cry没有像UE那样优秀的编辑器可扩展性，因此基于Cry Flowgraph的构建方案一开始就否决了。所以，为了完成整套节点图的编辑，一个底层的系统就被提到了很重要的位置来做，就是Reflection反射系统。
当时本意是希望将客户端、服务器使用一套Reflection机制来做的，但整个服务器的Reflection完成的东西太多了，于是服务器部分现在是还在两套Reflection下进行着，一套跑图，一套跑原有结构。而且，这是现在的成绩单，而当时，两个月的结束是6月底，那时的Reflection的使用几乎可以以惨不忍睹来形容，因为本来的目的就不是做Reflection做到6月底，而是做技能，所以稍微弄了个框架就着急忙慌去做其他东西了。
3、客户端、服务器通用的Sequence/Kismet/Flowgraph系统。这个也是一个问题，编辑器本身倒还好，但是如何扩展节点弄得很麻烦，C++要写、CLR代码会自动生成、然后C#要写编辑器相关的东西，这套坑爹玩意儿，虽然已经简化到基本只要写C++和C#，但到现在为止都还只有一两个人能掌握。对比之UE扩展一个节点的轻松，这简直是天上和地下的区别。而且，因为进度够紧，底层放了不少假设在里面，随着东西越来越大，不断地在重构，直到现在都还算是坑。——而且，Debugger还没做，核心机制最重要的一环不全啊……
4、技能系统，一开始重点放在了Reflection和Sequence上，原来的技能流程没太关注，本身的技能确实是有不少问题的，一个本意想超越魔兽的游戏，使用的同步方式却居然是魔兽世界的同步方式，而且是基于TCP的，即便是两年以后上线的游戏，也太高估中国的网络环境了吧。所以当时本着从底层重来的思路开工了，但是，整个技能流程相关的东西太多了，不愧是从已有的项目继承过来的，把之前数人数年写的东西，一个人花了三个月左右改成新的机制，能改成什么样呢？……
如此多对自己不满的地方，一方面，虽然总是嚷嚷着进度太紧了，需要时间来好好做好好设计，一方面，自己难道一点问题都没有吗？明知道进度紧，明知道团队的进度不可能跟着个人的来，还要用这么火爆的方案，这不是自作孽嘛？
感觉，还是没有设定好自己的位置，2011年末的时候，参与一个创业项目，接触到了不少自认为算是先进的理念，11年到12年、非技术方面的成长还是比较大的，也学着用自己的想法和眼睛去看待这个行业，以及开发这个过程的改进了，基本的思路其实一直都没有变，就是用更先进、成熟的软件流程管理方式去进行游戏软件制作，避免由于设计者水平不足导致的迭代式开发的种种问题。但是12年末的种种原因，又重新地成为了一名普通的职员。
但是，13年直到现在的心态，更多地还是留在了12年末的时候，认为游戏的开发过程需要有所变化，并力主和推进这个变化的过程。但是，现在所处的环境已经变了啊。
毕竟，自己只是一个职员了，对于团队而言，按进度按质量完成工作不是更重要的么？
明明大前提变了，却仍然要做一些革命性的东西，可问题是，真到做的时候，又为了赶进度，没有真正地“革”起来。真要好好搞，两周？对不起，我搞这个东西得俩月，等不起就别让我来——真要这样的话，也不至于留这么多坑了。
新的公司，新的团队，并不是需要一个方法的实验者，而是需要一个成熟的实现者，这一点永远没有变。
如果说程序员需要立足于需求，那么这个需求的需求方并不是自己，而是团队整体，所以，团队整体既然采取了某种方案，也就注定了作为团队客体的程序员必须要按照相应的流程去调整。或许这就是项目参与者的客观现实，怨不得天，由不得人。
哪怕这个方案，个人认为是错误的，但是，既然它是团队挑选的方案，自己既然没有反对、或者来不及反对，自然就只能选择做下去。
团队并未限定如何去实现一个结果，但是这种实现一定要取得一种平衡。就是实现的结果和成本的平衡，一个设计思路很不错，但从外表上却看不出来，但要改却要花个半年一年，那确实是一个比较大的问题。
对于个人而言，一个正确的道路比一个正确的结果自然要重要，因为这是一个人职业生命的选择，40年左右的职业生涯，并不容许我有那么多时间去试错，去明明知道一个错误的道路还要去走。
但是对于团队而言，一个正确的结果却往往优于一个正确的道路，因为团队有各种压力，公司的催更、Boss的指挥、团队内部的氛围——并不是正确的道路就能解决所有的问题。即便团队的一切都按照自认为的正确方向发展了，Boss是正确的吗？公司是正确的吗？团队的其他成员会认为是正确的吗？
说到底，还是那个矛盾：个人的需求和团队需求的矛盾。团队是各个不同理念、不同阶级、不同价值观的人们组成的集团，不可能也没必要用自己的价值观去推进他人。
种种原因，无论如何，团队没有采取的一些思路，过来以后，既然想推进，就需要达到平衡，用时间成本和结果同时能够达到最大公约的机制。
或者，说句玩笑话，真要觉得自己够狠，也可以狠到来一次“下克上”，我就没按进度完成了，怎么着吧，但前提是真的按自己的方法把事情给做到极致了。可自己做到极致了吗？显然没有。两周你真给拖了两个月，真不见得领导会生气，只要你的结果导致的是之后所有类似工作，本来一周的一天就完。任何领导都会支持这种技术革新的。
所以，或许是这种哪个方面都没达成的心虚感才让自己的戾气开始重起来了吧，但是又有什么用呢？
真正解决问题的，还是把事情给做好，做到自己都觉得满意，跟其他什么的都没关系。
十一后好好地把问题处理一下吧，少点火气，少点抱怨，要么，按团队的节奏来，要么，按自己的节奏来，总之，摆正自己的位置。要做一个普通员工，就真把自己当个普通员工，要做一个革新者，就把自己真的当个革新者。进度不会随着抱怨而变得正常，资源也不会随着抱怨而变得更多，自己是团队的一份子，好好做好自己的，团队的气氛自然就好一些。
