然后就是等其他同事快速复用或者是移植之前积累的系统模块. 当然准备工作要足够细.随时测试随时发现问题.

没有用户空想最浪费时间. 很快又要面临bigworld的那些烦心事了..

http://itunes.apple.com/cn/app/secret-kingdoms-mobile/id520175604?mt=8  神骑世界IOS 版发布

内容提要

为神秘王国的人类而战
准备好你的座骑,抵御魔族侵略者,保卫神秘国度
使用武器和盔甲定制你的座骑,经历30场战斗,穿越3个区域

SKM将会把SKO这款来自构思科技的全新奇幻MMO的动感新世界带到您面前

通过简单的挥击与轻敲战斗机制,与魔族的疯狂恶魔们战斗
挥击敌人进行攻击
轻敲屏幕招架敌人的攻击
使用重击打破敌人的格挡
独特的技能将会带来新的小游戏帮助你完成你的任务,抵御魔族的入侵
每个策略都会为你赚到更多的金币!使用你的金币购买宝石,药水,武器和盔甲
使用不同的道具定制你的兽人座骑。你的座骑是个海盗吗?还是一个忍者呢?都有可能哦!

Globex Studios 网站Secret Kingdoms Mobile 支持

屏幕截图

iPhone iPad

Todo: Track refactor project . think more about unit test.

https://github.com/mikechambers/as3corelib/issues/171

If you’re using as3corelib like I’ve been using for quite some time now, you will notice this error. To fix it you simply need to remove the following import (it may vary based on your project structure):

import com.adobe.serialization.json.JSON;

and then you’ll need to modify your code to replace:

JSON.decode(myString);
and
JSON.encode(myObject);

to:

JSON.parse(myString);
and
JSON.stringify(myObject);

You can find the full details of the new implementation of the native JSON support in AS3 on Adobe’s Reference Site

解决办法是移除那个 import 然后把对应的函数名改掉.

一 ,  考虑的是如何调整结构?  还是考虑调整的目标.

我只能说一下子就去考虑很多细节, 不大可能把握整体. 即便是认同需要调整, 每个人的出发点也是不同的, 相对想改进的部分也是不相同的. 但大多是从自身所熟悉的部分提出.  正确的顺序应该是搜集需求,整理排优先级. 确定阶段性目标.
避免遗漏.

二， 如果上司不告诉下属完整的计划, 下属怎么知道要提一些什么建议呢?
看到什么再跑去说,恐怕就来不及了.

三, 切忌大手术. 要坚持微创.  当所有系统都在变更时,实在是没有办法衡量何为好,何为坏.

四, 与其讨论该怎么做, 不如先做一些技术测试. 坚持随时测试评估.  通常 没有办法说服别人的时候, 只能先搁置. 或者拿出数据来, 我更建议还是先做一些核心瓶颈的工作.

五, 已经没有足够的资源支持正常的开发工作, 怎么办?

以上 的一些问题需要有人考虑, 但不能人人都去考虑. 这一点,明显感觉不如之前做的周全了. 人员减少了, 但是职责空缺没有补齐. 组织结构变得残缺了, 然而关键的人却没有意识到这一点. 而我只能意识到有缺失, 缺失的部分我也不知道全部,因为是缺失的人带走的,这是问题的关键.
组织结构变更以后, 现有的人员会像流水一样流动,弥补空缺, 弥补得好 整个团队还是那么大, 弥补不好的话, 就会缩小,或者成海绵状. 有洞.

不能把单元测试的目标的界定范围扩大, 比如应该只是测试一个函数A,  而不是去测试调用此函数的一个函数 B，在只测试B的用例里也同样会忽略A.  单元测试的方式一般分两种, 一是验证输入输出的结果, 一种是验证call order  或者是否某个函数被调用到.

单元测试之后,可以考虑一些集system测试,无论白盒还是黑盒,那是下一个阶段的事了.  单元测试原理不复杂,但是在实践起来也是件不容易的事(实践的细节才是最宝贵的财富 ), 因为需要组织足够多的测试用例,方能保证经过了测试的系统是ok的 .如果测试用例不够, 比如考虑的情况不足有遗漏, 即使表面上测试通过了 , 系统仍然是有问题的 .  所以我个人理解, 单元测试的意义在于构建一个可以控制的结构, 这个结构是需要不断完善的, 很符合Web 2.0 产品一直是beta 的理念. 但是随着时间的推移, 必然是可以提高效率的 , 因为可以消除一部分已知的问题重复发生。 不管这个导致bug的比例是多少, 都是有意义的, 比人为的去判断和手工的验证要快速的多.

无论怎么样,先把能搞的先得搞起来.  一个项目是否是可以进行自动测试 应该是这个项目是否能持续成功的一个标尺.  (持续的意思就是排除偶然的成功)

update: 单元测试另外一个意义是可以持续检查. 虽然是依赖于测试用例的. 但如果测试用例组织的合理, 只是某些功能性函数的修改必然会导致某些旧的测试变成不通过(依赖的功能部分错了).  似乎多了很多额外的工作,就是写完程序还需要写测试数据. 但这部分最合理的是谁修改程序谁修改测试用例。 还有就是测试数据最好是指定获取的方式,而不是写死的数据. 因为从实际系统中获取的数据才是真实需要测试的.
update1: 单元测试势必需要花更多的精力.改动函数自然就需要改动测试用例.如果需要的话. 但是也是为了确保功能和设计目标一致.不然更多衍生的调用都会发生错误的.至少某个函数被修改以后,可能就不再适合被其他场合使用了.
果然,很是有阻力.毕竟不是都清楚引入了单元测试之后需要做什么. 所以需要花时间准备实施的细则. (太多事情了…)

Q1: 测试用例如何组织。

需要根据某函数被引用的所有的context来设计. 如果是操作对象实体的,需要指定获取数据的方法,而不是简单静态数据. 这样好处是可以测试对象的数据定义变更时,是否可以测试通过. 测试用例的覆盖率,的确是100% 比较难.但是可以逐步完善完整.

Q2: 如果不大改动代码,怎么支持测试呢?

要进行自动测试的前提是代码是可以测试的.比如:代码是模块独立的,显然比处处调用的好测试. 将环境依赖的代码剥离.要么做预处理,要么写Dummpy class. 要保证,输入输出不变. 辅助的函数估计还是要加的,不影响运行,但是为了收集验证数据的. 代码天生就可以切换运行环境 会更方便进行自动测试.更容易构造运行环境. 但的确也有风险,性能问题等.

Q3: 运行环境和模拟的差异

在完成模拟的自动单元测试之后,在真实环境中需要配合bots来进行黑盒测试.(优先做这个吧) 但是单元测试如果没有的话,估计这部分就会很多问题了,所谓书到用时方恨少了.
#bots 需要模拟真正的玩家交互.而不是写太多的cheat方法.这样测试的结果才会更加真实.
#bots 还要做的是支持 groups test.
#bots 还要支持测试数据的载入.
（this can be implemented based on our customized gateway )

controlable test framework. plugined component framework. (!!!)

later i find the reason, because  i mounted local file to centos .  finally, after  i copy all files to centos , and compile successfully.

interesting. 

http://hi.baidu.com/marbleant/blog/item/619e58170f3dbd4320a4e9f4.html ,  share with you.  i like this article.

只能送给bw一句话: 关键时刻真的不给力啊…  够坑爹的.  莫不成,我们就不应该用来做mmorpg吗.

”

… middleware is the right way to go if you want to focus your team on doing games instead of tech. And there is always enough tech to develop in addition to the middleware anyway.

Getting to know [your middleware] will cost a lot of time, but it is time you have to spend or you will very likely regret it at some point.

But when things get complicated and you need to know exactly how a system behaves, there is no better place to look then the source code.”

如果不能把文档做足 做细, 就请让我们看到源码…    引自: http://www.gamasutra.com/view/news/37304/Opinion_Know_Your_Middleware_Source_Code_Please.php

魔兽世界的服务器硬件需求批露.

http://server.51cto.com/News-194644_3.htm

2200台啊..多少米.这可不是用纸糊的.