代码重构是个很好听的名义，基本上是道德制高点、正义之举的级别，所以每次当重构成为选项之一的时候，我都极其倾向于重度重构，甚至推倒重练。
不过现在我参与的工程规模越来越大，重构难度越来越大，不能随便就搞大重构了，但我还是在尽量寻找机会整理眼前的代码，别人的代码，我的守备范围内的各种代码。代码洁癖已经养成，看到复制粘贴的混乱代码就手痒，真希望我未来媳妇整理房间的热情能有我整理代码热情的至少一半吧（笑）。
不过话说回来，重构真的很花时间，对工作进程影响略大。这个月我在做的一个工作就是这样。
这个月我看我们游戏项目的2D界面至今没有一个UI框架，每次都重新写各种基础逻辑，尤其那种点击一下就消失的半透明蒙版啊、四方形按钮什么的，看着它们被一次又一次的重新实现，我整个人都不好了。
把散乱在一个类中各处的UI逻辑整理成可复用的各种UI组件，这看起来是正确无误的判断吧，于是我就跟着感觉重构下去了。结果越做越开心，基本把自己平时写游戏时用的那套简单的UI基础框架都挪到游戏项目里来了。
动作太大影响范围就会大嘛，所以到框架大概成型后的调错过程就很枯燥，很漫长。
其实公司自己有一套和2D显示相关的框架的，但那个是单个显示单位的框架，比如一个图，一个2D动画过程什么的，属于比UI组件小的单位。那个既有框架里功能还挺多的，但我写自己的框架已经来了兴致，跟没没兴趣去了解那个只有公司内的这一个游戏在用的私有框架。结果我大概了解了一下它的创建读取和释放，显示非显示，位置设定和优先级设定之后，就拿着这东西去拼我的UI组建了。
昨天写道23点多，身边仅剩的几个人已经进入聊天状态，我也累了，就上前炫耀了一下我的战果，说原来那个框架功能不足啊你看我给补上了哈哈哈哈。结果原2D负责人现在我直属上司突然情绪亢奋，凑上来问我哪里功能不足，我说了几个部分，他表示这个有稍微曲折一点但是用既有代码也可以做到的解决方案。我想那套既有代码里有他贡献的一部分代码，说老代码的坏话他肯定不高兴的。不过知道我重复实现了一些已有的功能对我还是有很大打击。回家的路上，我开始想，这次为什么做得不对。
重构是大义，应该做的。这次的问题是出在写出了兴致，开始过度设计了。在我把自己的框架移植过来的时候，其实我已经不是为了解决，而是为了写一个漂亮的框架而在写代码。这对自己学习来说也许有点意义，但是在公司做这种事就比较理亏了。
以后注意吧。在工作领域，快速完成工作是第一优先。
不过这样也无法阻止我继续在工作中寻找提升自己技能的机会的！
在公司里提重构基本上都是费力不讨好的事情。
举个例子，之前在某外企实习，所有人都知道支付那块的代码写的超级烂，好几个项目经理跃跃欲试的想动它，但是谁都没能动得了，为什么？ 既有代码虽然烂，但是能用，能赚钱，你重构带来的风险谁担？万一不能用了，你大半年人力打水漂？
重构需慎重，编码要小心
外企！小宝他们那个外企吧。外企啊～>_<
支付部分肯定尽量不让人碰的，就像在线游戏项目的存档部分，非常非常重要，绝对不允许碰坏，碰就要担负巨大的责任。
小游戏公司爽的地方在于，没有特别强势管理我们写代码风格的人，能用即可。
重构这个事儿我也觉得动以前的代码是不太负责任的行为，毕竟我们是开发公司，要为客户负责。
不过今后的新UI，我就可以一点点的用自己的代码替换掉了。现在这个项目组里负责2DUI的人算上我也就两个，虽然我属于辅助位… 不过有工作进来我都尽量争取写新UI的工作，这样我就可以用我的UI了，不然如果是现有UI的添加修改工作，我就不方便做得太过火。
说起来，不怎么面向对象的代码看多了，也有点找到感觉了，知道应该在哪里添加代码以后修改起来也算快，只要不是遗留BUG都不成问题……就怕遗留BUG，幸好至今我还没遇到。
现在的理想是，把我的UI的初始化部分弄弄好，注释写得再翔实一点，让后人不至于太费力。我现在的异步初始化做法问题非常大，也就我能凑活用用，根本不能推广。不过工作进度压力来了，容不得我慢慢想。嗯，还是月初最爽，尝试各种设计思路，可以一天都没有实际进展，就是扩充UI基础组件，哈哈。
要超越原有UI，达到让公司注意到的程度，我觉得这套UI至少需要一个配套编辑器。可以用编辑器在游戏外拼装好UI，然后生成个xml之类的文件，程序读一下这个xml就可以在游戏内创建对应UI。其实这事儿应该让美工做我觉得= =，不过我们公司现在用的一个美工程序太诡异，不方便。美工把UI各处坐标都比划好了以后，我们不能直接用UI，只能得到图和那些坐标，然后我们还要在程序里拿那些图和坐标重新拼一遍UI。多费一遍劲不说，出了问题都不能立刻搞清楚是程序的问题还是美术的问题。 我最讨厌做无意义的工作了，这种重复工作就是无意义的工作嘛！
不过那个美工工具我们没有源代码，真想做的话只能从它的导出文件下手。我们程序里有解析那个导出文件的代码，可以把那里读一读，搞懂那些导出文件各个bit位的意义以后从那里取值直接生成UI。不过这也需要和美工约定，比如哪几个坐标是给哪几个图用的，哪几个地方的小图标的全套替换组件要以什么格式或者什么约定名称来命名，省得我真对每个美术资源都写处理程序。目的就是自动化，省掉一个步骤！
嗯，目前是想法很多，行动不够多。我平均每个工作日的代码产量150行左右，公司还是那种喜欢给两个大括号都单独一行的代码风格，所以我来公司以后代码行产量凭空增加14%……
你看我左边博客链接第一个那位笃志同志，他入行之后的公司之外的代码行产量已经达到至少每年10w行了，而且他还是在公司加班到很晚的那种类型，真不是到这种代码产量是怎么做到的，佩服orz
我在公司还兼任游戏的一些过场动画的编辑工作。这边的过场动画都是纯代码写的，貌似客户不许我们用脚本语言，我震惊了！后来我花了两个礼拜时间写了一个过场动画类，硬是把数据库表格给做成了脚本语言，虽然指令有限，创建变量很困难，但是创建函数呀，函数内部调用函数什么的都实现了（估计递归也可以）。后来把ifelse语句也给做出来了，当时各种成就感啊～
最近客户说希望可以在数据库里直接修改数值来微调过场动画。客户那边只有美术设计和策划，动数据库的是策划，我给他看脚本化了的数据库他很难改…… 我也觉得现在的系统表达能力够强但编辑这种过场动画还不是足够方便，另外毫秒时间和帧数之间的累积误差问题也没有解决，现在客户修改也不方便，看来不得不承认是设计失败了。数据库脚本化可能只是为了满足我自己的成就感，是代价很大的过度设计。不过也好，推倒之后再设计一个全新的吧！这次希望能做个GUI编辑器，不再是在游戏内凑活着改，时不时还得重新编译运行了。因为公司的渲染流程似乎挺复杂，完全另外实现一个几乎不可能，所以我想在外面另做一个GUI编辑器，但是不显示游戏画面，而是通过和游戏通信，给游戏发送命令，控制游戏的画面当作我编辑器的显示区，编辑器自己的显示区就显示一些辅助线啊辅助轨迹什么的可拖拽物体即可。重要的是，编辑器应该有自己的项目文件，而不是游戏的那个数据库了。这次希望做一个可以自由拖动进度条查看效果，摄影机可以用鼠标流畅控制的。因为过场动画中还需要控制一些效果啊音效啊物体或人物的位移和动作播放等等，只有摄像机控制是不够的。但是给那些动作也添加可以接受我编辑器网络通信命令的代码恐怕会被批评…这次就……嗯，都由我的过场动画类来代理调用吧。
这次还有一个想法，就是解耦合。因为难得做一个，只用在一个游戏上就太可惜了。编辑器需要和游戏互动的部分是对摄影机参数的控制，和对画面内物体的控制，物体可调用函数的控制。给这些必须的控制一个接口，所有实现这个接口的代码都可以和我的编辑器互动，这样就NB了！接口可以是拟定一个网络协议，编辑器可以查询所有可交互物体的列表，然后进一步查询各个可交互物体的所有可使用的函数。嗯嗯，这个可行！不过网络协议我老写错，debug得怕死了……
给游戏内的可操作物体写代理函数这部分，有点想用lua脚本（反正是开发期用，发售版里不包含脚本就可以了吧，再不行我只在自己本地代码里用，不commit到SVN里总可以了吧！）。隐约觉得这里用lua会让开发轻松很多。我去公司一个用虚幻3引擎开发游戏的项目组串门的时候看到虚幻三测试执行的时候可以直接在画面最下面的对话框里输入脚本命令直接和当前正在运行的游戏世界交互！小到函数调用大到代变量赋值都可以！太NB了吧！这个我也想要啊！！！！
嗯，你看，YY就是这样，越想越宏大，结果多半无法完成。古语有云，理想很丰满，显示很骨感嘛。不过我还是（毫无根据的）相信自己是有改变世界的潜力的。以前我都很讲道理，不过现在越来越不相信理性了。Get Things Done的不是周详的计划，是执行计划的热情啊！啊啊啊啊！燃烧吧！我的小宇宙！
嗯，我相信，有热情，事竟成。你看我热烈盼望有个好女盆友这么多年，一定也会实现的，对吧！对吧！？なぁ！！！