MMO之禅（一）开论
MMO之禅（一）开论
--由Begin()End()出发，接口抽象，功能模块化
Zephyr 201303
以前初学DirectX的时候，
对渲染帧开始结束的时候调用Begin和End函数曾有点感到困惑过，
Why ？How？当时一知半解，
后来也没太在意这个问题。
前几日写了一个本地化数据的二进制导出器，
一开始由于自己用的是连续内存地址的数据，
所以就简单设定了传入数据指针和数据包大小的接口，
在模块内判断数据有效性后就直接开始序列化I/O操作，
而后，
由于一些同事所用的非连续数据（List，Tree）之类的数据也想用我的现成接口，
问题就出现了，
该如何导出？
有两个法子，
第一，把我的导出器代码简单地拷一份出去，然后由其自行改动实现；
得二，改进接口，使之通用化；
一方面，MMO，进度自然压得紧，节点时间在即，
另一方面，调试人手、时间都不充足，节点要求也高，不容有错，
该如何定夺？
还没定下，
正好自己检查的时候无意发现了一定时序下，I/O句柄会无法关闭，
导致整个导出器和对应的数据读取失效，
这是个隐蔽的Bug，发现也实属巧合，
暗想，同事那边手头活也多，如果代码直接拷过去，
到时候Bug的帐，我是也逃不过的，
痛定思痛，立马决定重构接口，
泡杯茶楼道里走了两步，
正好想到VB IB等Buffer常用的Lock Unlock函数，
我这个不也是可以这样么？忽然灵光一闪，
这也不就是DX里的Begin，End接口么？！
DX的指令提交，Buffer的写入，还有我的Binary数据导出，，
不都是一回事么？！
心中一万头草泥马呼啸而过，直骂自己太蠢，
简单总结
"为了应对复杂非连续的数据导出，
可以先行传入要导出的目标类型给Begin()，
然后由导出器模块暴露出如UE的一个Archive指针，
对Archive进行自由操作完成后.
再由导出器模块的End()函数完成Flush，
统一的接口，自由地操作."
临近周五下班，整个人也处在兴奋状态，
敲定接口，编码，调试，
结果整个过程也就50分钟左右，也并没有花太多时间，
远比预计的要少。
东西很简单，方法更是简单，
周末静下时间开始后知后觉地感到不安了，
可如果不是同事提，不是自己发现了bug，
那么这个模块还是会一直保持原样么？
答案很可能是会一直是。。。
工作工作时间也不短了，
项目的烦杂，薪资的可怜，
让自己的热情越来越冷淡，
巧劲，hack，为任务而任务，
常常一知半解，得过且过，
这样下去，自知难以成长，绝不可取，
那就得总结改进，
从问题的根源开始，
是由于一开始的抵触心理，
药方并非“要勇敢地重构，推倒再来”或者”No ugly code anymore“那么简单，
还好念书时养成的一个癖好，
平时所思所想习惯性地记下来，
工作后也有一堆大本子搁着了，
正好静下来好好仔细消化总结一下，
废话半日，赧颜书文MMO之禅，
不言其然或所以然
只谈为何使然，
望能给予后来者以帮助。
首先，MMO，是一个完整的软件工程项目，
计划，编码，检查，改进，
各司其职，密不可分，
作为一个码农来讲，首先重要的是一个全局观
首先抄书：
”
软件工程，阶段
内涵
软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下四个方面：
利益的最大化，
如何达到？
答案人人皆知，开源节流。
在研的项目，除了提升自身品质外，自然无法开源，
那就是节流，节流绝非只有死抠研发成本，
更好的一路是提升效率，
回归本质，就个人到现在体会到项目上常常造成的效率瓶颈常常有：
架构成本，
交互成本，
调试成本，
沟通成本
。。。
严格控制粒度，防止耦合度过高，
就可以很好地防止以上成本对项目的无谓耗费，
具体在实际中，
就是接口思想，重用思维，
在实际编码的过程中，
优先整体架构，规划，
不断抽象，求精，
首富大人Gates曾说过真正优秀的人才，是聪明的懒人，
聪明的懒人拥有极致主义精神，
会力争”一劳永逸“的解决方案
因为他们的效率而节约下来的时间，
远大于后头测试，Debug的时间。
故而，
我们需要不断地总结，思考，
提高效率，
找出可以减少错误，有效偷懒的好路子~
@Todo
后边的还有好多，思路慢慢整理，
协作，配合，
架构，数据结构与算法，
本着只谈为何使然的原则，
准备将这些都大言过一遍，
。。。
