手游游戏服务器逻辑框架

1 背景

首先,要回答一个问题:

我们为什么要专门为手机游戏专门定制设计一个游戏服务器逻辑框架?

坦白地说,公司自研游戏做了这么多年,事实上互娱已经沉淀了一批相当成熟的组件,如:解决底层网络通信的Tconnd、解决进程间通信Tbus、解决协议加解包的Tdr等等,但我们发现,这些组件绝大多数都是与业务无关的基础组件、服务和库。而与游戏业务紧密相关的逻辑框架,可能每个项目组都有自己的一套,这一方面源于,不同游戏业务,的确需求本身有较大的差别,很难用一套可复用性很强的逻辑框架包打天下;另一方面,也可能受限于项目本身的开发进度压力,端游有相对充裕的开发时间,但由于游戏系统繁多,平摊下来,每个系统的开发时间也不多,而页游和手游的开发进度就更紧一些,逻辑框架这块也没太多时间来作整理了。

2 现状

以stan经历过的工作室里三款游戏为例:微连、微胖和微塔。

三款游戏在业务逻辑处理上,均各自使用不同的一套框架,风格迥异。如果要说相同点,则是均使用C/C++来作业务逻辑的实现。微连和微胖均以tapp作基础来搭建框架,而微塔则是完全自行做的一套后台框架。

考虑到手游开发周期短,迭代速度快,发布频率高等特点,如果延用目前的逻辑框架,无论是上述三款游戏的哪一种,均难以解决如下几个问题:

(1)开发复杂度较高

这里的复杂度包括语言本身的复杂度、开发效率、代码可读/可维护性等。

(2)运维部署代价较高

从代码编译到上线部署,整个周期都比较长,虽然目前的逻辑框架基本上都采用了共享内存保存玩家核心数据,以便于进程重启后数据即时恢复的机制,用来实现“热更新”的效果,但这实际上是以牺牲开发复杂度来作代价的。

(3)系统可靠性

实事求是地说,要写出可靠性的代码,根本上还是取决于写代码的“人”。但由于C/C++本身是属于偏底层的语言,对开发者的要求客观上要更高一些。但即使经验丰富的开发者,也难免不犯内存越界、内存泄漏、堆栈溢出等诸多令人抓狂的错误。

有鉴于此,结合业内同行朋友成熟项目的经验,我们选择用Lua与C/C++混合编程的方式来实现游戏业务逻辑。

3 新的解决方案

新改进的逻辑框架基本可以解决上述提到的三个问题,至于为什么选择用Lua,这个业内基本上已有了一些共识,可以看这里,互娱魔方工作室也有项目已经在应用 ,看这里。故这个问题在此不再赘述。

接下来,我们探讨一下解决方案的具体实现方法。

3.1 边界

混合编程面临的一个问题是:如何界定不同语言之间的处理边界。对于我们来说就是,Lua能干什么,该干什么?C/C++需要做什么?

为此,我们在实现需要遵行的一些原则有:

  • 网络消息的收发、加解包、DB读写、日志读写、玩家对象池管理等涉及到有一定CPU开销或底层处理的操作均由C/C++来承担;
  • 有复杂交互流程的逻辑,由Lua来实现,如:一个业务协议流程涉及到多个SS交互;
  • 有单一重复逻辑的需求,由Lua来实现,如:任务、关卡、副本等;
  • 系统配置文件由Lua来实现;
  • 其它比较模糊的业务系统,我们会根据如下几个因素来综合权衡:开发效率、性能、两种语言的交互调用频率等;

3.2 框架外貌

(1)GAMESVR加载Lua配置文件进行进程参数以及业务逻辑参数配置;

(2)GAMESVR加载Lua逻辑脚本,根据CS请求,运行不同的逻辑脚本;

(3)GAMESVR可以通过修改Lua逻辑脚本进行热更新;

3.3 框架处理流程

手游框架处理流程

3.4 Lua配置文件处理思路

Lua的一种重要用途是作为配置语言

XML层次分明,写起来太复杂;ini配置不够灵活;其他配置需要自己开发

Lua作为配置文件编写起来简单,解析也方便,更重要的是在Lua协程框架中,很多情况是Lua协程读取配置文件,而不需要其他接口便可直接读取,天然的结合,使用起来非常方便。

遇到的问题:

(1)一份配置文件,C++中需要调用并且Lua业务逻辑脚本中也需要调用如何处理?

在GAMESVR中,建立一个ConfModule,ConfModule加载Lua配置文件到本模块中的Lua虚拟机,并把配置文件需要的字段解析到本模块的成员变量中,对外提供GET接口进行访问,对于LuaTaskMgrModule也同样加载该lua配置文件,方便Lua业务逻辑脚本中的调用。

 

(2)lua配置文件便捷的解析方式

采用lua_dostring方式,将需要的参数按lua语句方式复制给一个变量,然后通过lua_tostring、lua_tointeger、lua_tonumber将其解析出来,lua_dostring方式速度较慢,但该模块只是在GAMESVR初始化时候解析一次,并将解析出来的数据存入模块的成员变量中,后续数据访问通过提供的GET接口,解析完后关闭lua虚拟机,我们认为该方式在解析速度上可接收。

 

3.5 C++网络收发包处理思路

目前GAMESVR中存在三个异步回调点:

  • TBUS
  • TCAPLUS
  • LIBCURL
  • lua协程框架需要将task_id存入异步交互数据中,并且需要在响应包中能够原封不动的带回该task_id;
  • TBUS可以将task_id放入包头的seq_id字段;
  • TCAPLUS可以通过TcaplusService::TcaplusServiceRequest中的SetAsyncID将task_id存入,并在响应包时,通过TcaplusService::TcaplusServiceResponse的GetAsynID获取task_id

LIBCURL需要封装,使得CurlClient支持缓存task_id的机制;

4 写在后面的话

目前用新的逻辑框架,重写了好友关系链Server和GameSvr账号登录验证模块,可以用微塔老客户端完成账号登录全流程。

虽然新设计的逻辑框架还有诸多可完善的地方,但初次尝试应用,我们已感受到它带来的变化,比如:重写的好友关系链Server代码量比原来缩减了近三分之一,代码量减少的很明显的好处就是:代码更简洁,可读性更高(客观说,微塔原来的代码也写得不错,可读性也比较好)。

在后续项目的开发实践过程中,我们还需不断优化、完善新设计的逻辑框架,让其可用性更高、可复用性更强,相信经历咱们新项目的洗礼,新的逻辑框架能成为咱们产品中心游戏服务器开发的一把利器。

每月自评之七:2013年7月

(一)我读

     (1)《程序开发心理学
          推荐指数:四星
          推荐理由:温伯格的经典之一,其实这本书几年前有看过,这次是重温经典。无需多言,此类经典,常看常新!
(二)我看
     (1)《预言 Premonition
          推荐指数:三星半
          推荐理由:首先说,我推荐第一理由是被这个故事的开头所感动,尤其是女主角听到警察上门,告知丈夫发生车祸时,莫名地被啥东西给扎了一下。女主角也演得不错,house wife的感觉演绎得都比较到位。但,硬要把此片列为悬疑片,那越来后面,故事就比较诡异了。女主角,明明可以用先知改变历史,但脑残的导演硬是没让女主角这么干。如果说,这一切都是宿命,那又何来预言?
     (2)《罗拉快跑 Lola rennt
          推荐指数:四星
          推荐理由:这片子是蛮老的了,记得上学那会看过,但记得不太清了,于是在接老婆的列车途中,再次翻出来。刚看这部电影时,很多人可能会拿它与《蝴蝶效应》相比。但其实,它与《蝴蝶效应》看似相似的故事结构,但题材和观看的感觉完全不一样。这部电影的题材更加鲜明,罗拉是一位可爱至极的女孩,火红的头发,藏着一颗火红的心。三个故事,三种结局,三种不同的人生,被数个偶然的事件影响着,这里面似乎蕴含着某种哲学的启示。但给我印象最深的还是,罗拉那头火红的头发,青春无敌,爱情无敌!
     (3)《惊天危机 White House Down
          推荐指数:四星
          推荐理由:诚如老婆所说,这电影是真心好看!帅哥负责冒险、总结负责搞笑、最大反派角色最后才浮出水面,还有一个天真无邪而如英雄般的可爱女孩!好莱坞各种元素充满其中,是一部好看的片子!
     (4)《盲探
          推荐指数:三星
          推荐理由:曾经的铁三角,时隔多年再重聚。不是严格意义上的悬疑,却也有让人惊喜的地方。当然,最惊奇的莫于看这片子,是我和老婆是“包场”看这部片子,因为整电影院除我们俩外,空无一人!也算是挺特别的一次观影经历!
(三)我听
     (1)【东吴相对论】
          再听两个老男人如老朋友们聊天,又增添不少收获!
(四)我用
    (1)【禅道】
           在Linux下搭建整套环境,还是费了不少时间,里面还是有不少坑的。不过,对于一套开源的项目管理系统,其提供的功能还是挺强大,包括需求管理、Bug管理、路线图等等,一般的软件项目都能cover到。
(五)我藏
     本月摘录收藏的各类帖子和文章:
     (1)技术:4篇
     (2)产品:1篇
          1. 内部资料
     (3)行业:1篇
     (4)学习资源:2篇
(六)我做
          项目开始对外内测,处理各种新需求,解决各种Bug!
(七)我玩
     (1)【Candy Crush Saga】
          岂今为止,玩过最痴迷的PVE类过关三消休闲游戏,关卡设计的太棒了!
     (2)【笑傲江湖】
          完美今年最重磅的大作,在端游市场走向低迷之际,这款游戏再次引起业内关注。当然,对于自称武侠迷的俺,这款游戏也是我期待已久的。鉴于空余时间严重不足,目前还在漫长的升级途中!
(八)我思
       本月依然是忙于处理项目内的各种需求,项目也经历了正式的对外内测。
       虽然本次内测只是小规模的测试,主要是验证基础功能和核心玩法。但毕竟是进入了正式的运营期,项目的运作方式都有相应的变化,首先,在版本管理上就多了一些要求。一般的做法是,将主要版本分为开发线和运营线,开发线是在主干上做新功能的开发;运营线则是单独针对当前运营的版本单独开辟的一条分支,主要是作线上bug的修订或紧急功能的开发。
       上述做法,对于端游和页游项目,一般情况下是能满足需求的。但对于咱们现在做的跨平台手游项目,还稍显不足。我们遇到的其中一个主要麻烦的问题是:ios版本和android版本的发布可能会不同步。这主要是因为,ios版本在发布前,需要提交apple审核,而审核的周期快则3天,慢则一周多。而有时为了运营的需要,android版本需要先发,这样就需要单独为android新开一个分支了。
       内测已经开始,期待项目早日公测!

每月自评之六:2013年6月

(一)我读

     本月忙于各类杂事,尚未读完一本书籍,当然,这个不是借口,需要自我批评一下!

(二)我看
     本月看过的电影:
          推荐指数:四星
          推荐理由:一定要看iMax,剧情与前作有关联,但也不影响观看。整个观影过程没有特别的惊喜,但也绝无失望之情,老婆看到各种高空坠落镜头时,紧紧抓住我的手臂,这也说明,电影特效还是对影片增色不少!
     (2)《兄弟出头天 Stand Up Guys
          推荐指数:四星半
          推荐理由:客观一点说,这部电影是给不了这么高分的,但这四星半是给帕爷的!电影剧情其实不算出彩,毫无疑问,这三个老头都已修成戏骨,表演技艺已是炉火纯青。我最喜爱的阿尔.帕西洛在其中是扮演了一个老年浪子的角色。这电影与其说是在描述那有些久远的黑帮故事,不如说是在制造一种怀旧的伤感,目睹垂垂老已的三个老流氓,可以无限畅想,这仨当年是如何的牛B哄哄,不可一世!只是世间已多变幻,再也不复当年气派。可心中那股勇气和不甘尚存,所以,最后,那场枪战的镜头,才会让人如此唏嘘不已!
          推荐指数:四星半
          推荐理由:超越第一、第二季,喜爱的龙女终于开始崛起!悲凉、悲苦、悲催的Stark家族,再次被摧残,虽然这是意料之中的事情,但婚宴上的屠杀,还是让人对Stark产生无限同情。而小恶魔的表现再次给我惊喜,坚持自己的操守和底线,让我再次侧目!John Snow终于逃回来了,而可怜的爱人却被抛弃在野人丛中!很期待第四季,可尼玛还要等上一年 … …
     (4)《断线人生 Kai Po Che!
          推荐指数:四星
          推荐理由:最开始是冲着它是三傻原著作者的另一部作品改编的,看完了,的确没让人失望!印度电影再次征服了俺!
(三)我听
          无
(四)我用
    (1)【CocoStudio】
           这阵子版本更新比较快,已到0.20,我使用的是之前0.16,主要用了一下其中的UI编辑器,小Bug虽然还是很多,但基本的控件都有了,界面简单,操作直观。感谢开发团队给Cocos2d-x家族带了极其实用的周边工具:UI编辑器、地图编辑器、动作编辑器、数据编辑器四合一套装。
(五)我藏
     本月摘录收藏的各类帖子和文章:
     (1)技术:8篇
     (2)产品:2篇
          1. 内部资料
     (3)行业:1篇
     (4)项目管理:1篇
(六)我做
          帮朋友做一个小的app应用,刚好这阵子在学习Cocos2d-x,顺便拿它来练练手。用到了CocoStudio作UI编辑,正如前面所说,这工具虽然还有许多小Bug,但整个设计理念无疑是很好的。后面会持续关注中 …
(七)我玩
     (1)【疯狂猜图】
          最近热火朝天的一款SNS手游,通过微信病毒式传播,在业内已引起很大反响,微信作为游戏平台的潜质已提前被印证。
     (2)【傲世西游】
          公司兄弟部门出的一款西游题材的卡牌手游,这款游戏的品质还是不错的,但能不能在已是最热的卡牌游戏丛中杀出一条血路,将拭目以待。
     (3)【轩辕剑之汉之云】
          轩辕剑是我最喜爱的国产单机系列游戏之一,当年的《轩辕剑三外传天之痕》,给我留下了极深的印象,其动人的故事情节、悦耳的背景音乐,在我心中可以接近《仙剑一》。这次再次重温这部,是以三国为背景,水墨画风的作品。虽然无法企及《天之痕》,但也算是整个系列的一个优秀作品。
(八)我思
       本月绝大部分时间花在新项目的承接上,所以,都没时间看书充电了。上海出差过来的同事levone在新项目承接上帮了不少忙,跟这家伙也蛮挺缘的,在这里悄悄地感谢了!
       从业务逻辑上来说,新项目其实比较简单,底层框架代码也比较清楚,所以,review代码的时候倒也没有遇到特别大的挑战。但看和做其实是两回事,看的时候觉得没问题的地方,真正做的时候,可能会有许多细节没有顾及到。况且,咱这游戏涉及到的外部接口比较多,多个平台的关系链交互、交付交互、分享交互等等,旁枝杂叶比较多,因此,开始动手做的时候没有想像中的顺利。还好,在与同事的细致沟通下,都逐渐一一克服。
       新项目有几个做得比较好的一个地方,这里也可以总结一下,以便在后续的项目中继续发扬:
     (1)CI实践
          CI(持续集成)虽然被业内大牛推崇倍至,但真正在项目实践中有效实施,又是另外一回事。新项目在这方面做得还是挺不错的,而且的确大大提高了构建和部署的效率。目前项目能做到自动编译和自动部署,并且根据不同用途,划分了多个不同的版本和对应的服务器环境。如:用于开发人员的环境、用于测试人员的环境、用于策划人员的环境、apple审核环境等等。也正因为环境比较多,如果人工来管理,一定会产生许多人为造成的版本不一致的问题。现在通过hudson的脚本,构建人员只要在web页面轻松一键构建和部署。
          当然,如果说要还有什么不足,那就是缺少一个自动测试的环节,加上才形成传统意义上完整的CI流程。但由于开发测试用例是需要一定代价的,而且后续维护用例也是一笔不小的开销,这块就要根据项目实际来决定了。
     (2)丰富的小工具
          我非常赞同levone提出的多开发小工具来替代人工的观点,事实上,新项目也做到了这一点。这些小工具的用途各异,有检查代码风格的,有做跨平台文件同步的,有检查系统运行业务指标的等等。后面我也会继续丰富这些工具,尽量把重复、繁琐的事情工具化、脚本化。

每月自评之五:2013年5月

(一)我读

     本月阅读过的书籍:

     (1)《Cocos2D-x权威指南
          1)推荐指数:三星
          2)简评:鉴于cocos2d-x的中文书籍比较少,这本算是马马虎虎的一本入门书籍吧!
     (2)《代码之道
          1)推荐指数:四星
          2)简评:微软资深PM的经验之谈,虽然自己身在的互联网企业与传统软件企业的开发模式上有许多不同,但软件工程的本质是一致,读读也有不少启发!
(二)我看
     本月看过的电影:
     (1)《疯狂原始人 The Croods
          推荐指数:四星半
          推荐理由:近几年难得动画片佳作,虽然题材依然很“好莱坞”,但动画制作水平让人眼前一亮,再加上情节的展开也很到位,算是梦工厂王者归来的佳作。
     (2)《致我们终将逝去的青春
          推荐指数:三星半
          推荐理由:如果要苛求电影本身,那可能还算不上三星,情节处理上的各种突兀,让看了小说的老婆各种吐血。还好,我没看小说^_^。但说赵薇同学初次担任导演,加上非常成功的市场营销,让“致青春”这个话题,迅速在城市小白领阶段流传开来。微博、微信上各种“致青春”版本层出不穷。以致于, 我们公司的总办领导也坐不住了,整出一张张童年时的黑白相片,在公司大厦的电梯视频里不间断的连播,配上罗大佑同志的《光阴的故事》作背景音乐,来了一出集体“致青春”,而且还在儿童节来临前放出,很有爱,呵呵!
(三)我听
     (1)【马云卸任阿里CEO演讲】
               前有老史话别江湖,老马紧接着步其后尘。功成名就了,退下来享受生活,享受人生,何尝不是另一种以退进。看看人家盖茨,基金会搞得多起劲啊。
(四)我用
    (1)【cmake】
          新项目组用cmake作编译构建工具,用起来还是挺不错的。个人感觉比GNU make的构建速度更快一些,而且支持跨平台,对于那些习惯用VS作编辑器,但又要构建最终Linux版本的同学,跨平台交叉很方便。
(五)我藏
     本月摘录收藏的各类帖子和文章:
     (1)技术:16篇
     (2)产品:2篇
     (3)行业:2篇
(六)我做
          学习cocos2d-x,搭建了android开发环境。听了作者之一的王哲的演讲,看了一些资料,喜欢它层次清晰的架构,初步看代码,设计得也比较优雅。得多抽时间学习、学习!
(七)我玩
     (1)【蛙蛙斗地主/酷蛙斗地主】
          很难想像这样简单的棋牌游戏,通过强大渠道的运作,月流入能达到千万以上
     (2)【女巫之战】
          kakao上很火爆的puzzle类休闲小游戏,玩法简单直接,强PVP对战交互,体验不错,竟然上瘾了…
     (3)【各种休闲手游】
(八)我思
       月初转岗至新工作室,新项目组的氛围不错,在这里你能感觉到“基情”四射,呵呵。
       刚调回总部,利用午间,忙着和之前的老同事,老朋友见面、吃饭。时间真是一把杀猪刀,才两年不见,一同事便增肥30余斤,之前的小清新模样,已成胖大叔。身体是咱自己,我也庆幸自己体重控制得还好,感慨之余,计划每天早晨起来,加练几十个仰卧起坐:)
       调回后,最大的变化莫过于,与家人相处的时间增加了。不过,每天加班还是比较晚,虽然,现在刚到新项目组,没有承接什么实质性的工作,但熟悉已有项目的代码是必修功课。当然,另外,还有一些自己感兴趣的技术要学习,事情自然也就比较多。每天最开心的事情,莫过于早上起来抱着儿子逗乐。(晚上,老婆带着他睡,让我到另外—个卧室休息,就是怕儿子打扰我休息,体贴的好老婆)儿子晚上睡得老不安稳,弄得老婆总是休息不好。我也只好早早起来,把儿子抱到客厅玩耍,也趁机让老婆安静地休息一下。
       这一年多来,老婆怀孕临产,也没有时间和机会出去逛个街,购过物什么的。我调回后,抽着两个周末,带老婆去电影院稍稍放松了一下,看的几场电影都还能给点惊喜,把我们从琐细的生活中剥离开来,让我们的身心得到片刻温存。

手游对战设计方案

1       术语

1.1    术语和定义

术语 解释
硬直时间 客户端连续作移动消除时的累积时间
   

2       需求说明

2.1    实时对战

下面论述以《女巫之战》为例进行。

系统从当前在线玩家中,匹配出合适对手来。当进入挑战场景时,对战两方玩家在同一屏显示,双方的每一次游戏操作带来的变化,如:消除效果,都能实时同步到屏幕上。

如下图:来自《女巫之战》截图,即游戏对战界面会显示两个棋盘,左边为玩家自己的,右上角为对手的,游戏过程中,会同步显示血条和棋盘的变化。

2.2    离线对战

离线对战模式,在SNS游戏中是比较常见的一种PVP玩法。玩家可以随时对自己的关系链好友发起挑战,即玩家A可以对好友玩家B发起的挑战,不关心其玩家B是否在线。挑战完成后,若玩家B在线,则即时通知其被挑战的信息,若玩家B离线,则待其上线时,再通知被挑战详细信息。

2.3    半实时对战

同实时对战类似,系统也是先从当前在线玩家中,匹配出合适对手来。但是当进入挑战场景时,屏幕只显示玩家自己,不显示对手游戏界面。待这局游戏结束后,在结算界面一起显示对战结果。

还有另一个版本是,对战双方都是带角色的,游戏过程中可以显示对手玩家的角色Icon,对战过程中发生的变化,如:分数等,是实时广播给双方的。

 

3       设计实现

3.1    实时对战

实时对战的设计实现,总的来说,可分为两类,一类是服务器强同步,一类是服务器弱同步,下面详细描述之。

3.1.1     服务器强同步方案

在这个方案中,游戏逻辑的判定均放在服务端进行,无论是棋盘的初始化操作,还是游戏过程中的消除、新棋子生成等逻辑均由服务器运算,即将消除的算法放在服务器端,客户端主要作相应消除效果的表现。

进一步分析,该方案分为两种情况:

  • 阻塞同步

阻塞同步的特征是:玩家每次移动棋子作消除操作时,需要等本次操作产生的效果全部完成后(如:播放消除特效、已有棋子下落,新棋子填充等),才能作下一次移动棋子的操作。基本流程如下图所示:

 

图1  阻塞同步序列图

 

(0)客户端发起PVP匹配,服务器根据相关规则,在同一台gamesvr上匹配出对手玩家,并向两者广播一致的初始化棋盘信息;

  • 客户端A和B分别发起棋子移动请求,在收到服务器的响应包之前,客户端阻塞不允许移动;
  • 服务器分别判定两者的移动是否合法,若非法,客户端收到移动失败响应包后,让棋子置位;若合法,先响应客户端移动成功消息。然后,服务器进一步计算本次移动影响的待下落棋子和新生成待填充的棋子,以及新生成棋子中可能引发的combo棋子,计算完毕后,则一起打包分别向客户端A与B广播棋子下落消息,同时处理业务对应的逻辑,如:扣对手玩家的HP、累加自己的分数等;
  • 客户端收到服务器的响应移动结果包后,若检查通过,则处理棋子移动,并播放棋子消除特效等,若不通过,则重置棋子归位;
  • 客户端收到服务器的棋子下落和新棋子填充广播包后,分别处理A和B两个棋盘的棋子下落效果;
  • 进入下一轮棋子请求处理;

 

  • 帧同步

帧同步允许玩家在一定时间内(硬直时间),即时移动消除,即时反馈移动消除结果。当硬直时间到达时,客户端A和客户端B分别提交其在硬直时间内累积的所有移动请求,同时锁定棋盘,并等待服务器的处理结果。这种情况下,客户端和服务器都需要作消除逻辑的计算,并且两者的算法要保持一致。基本流程图如下所示:

图2  帧同步序列图

 

(0)客户端发起PVP匹配,服务器根据相关规则,在同一台gamesvr上匹配出对手玩家,并向两者广播一致的初始化棋盘信息;

  • 在硬直时间内,客户端A和B各自处理玩家的移动消除操作,此时只处理移动效果和消除爆炸效果,而棋子下落和新棋子填充不处理。硬直时间到达时,分别向服务器提前期间所有的请求移动信息;
  • 服务器分别判定两者的移动是否合法,若非法,客户端收到移动失败响应包后,让棋子置位;若合法,先响应客户端移动成功消息。然后,服务器进一步计算本次移动影响的待下落棋子和新生成待填充的棋子,以及新生成棋子中可能引发的combo棋子,计算完毕后,则一起打包分别向客户端A与B广播棋子下落消息,同时处理业务对应的逻辑,如:扣对手玩家的HP、累加自己的分数等;
  • 客户端收到服务器的棋子下落和新棋子填充广播包后,分别处理A和B两个棋盘的棋子下落效果;
  • 进入下一轮处理;

 

3.1.2     服务器弱同步方案

在该方案中,游戏消除逻辑主要放在客户端进行,即棋盘初始生成算法、消除检查算法、棋子下落与新棋子生成算法等均由客户端来控制,而服务器主要作消息转发与一些简单的判定,如:对局结束的条件等,基本流程图如下所示:

图3  弱同步序列图

 

(0)客户端发起PVP匹配,服务器根据相关规则,在同一台gamesvr上匹配出对手玩家,并向两者广播约定的对局开始时间,如:播放开场动画(3s)后开始;

  • 客户端各自判定玩家的移动棋子操作,判定能过,则表现相应的消除效果、棋子下落与新棋子填充过程,同时将本次消除信息打包发至服务器;
  • 服务器收到客户端的消除信息后,分别转发至其对应的玩家,同时处理业务对应的逻辑,如:扣对手玩家的HP、累加自己的分数等;
  • 客户端收到对手玩家转发来的消除信息后,在其对手棋盘上表现相应的消除过程与效果;
  • 如此循环往复,直至对局条件达到,如:某一方玩家HP<=0,或游戏对局时间到等;

3.1.3     小结

对比以上两类实时对战的实现方案,可以得出如下结论:

  • 强同步方案一般适用于需要服务器作严格检查判定的场合,即游戏业务上,需要严防玩家作弊的情形。其中,阻塞同步方案在MMORPG中应用较多,如:战斗技能系统等;帧同步方案在ACT中经常使用,如:双人格斗游戏中的动作同步等;
  • 与强同步方案有所不同,弱同步方案所应用的游戏,往往更关心玩家的单机体验手感,而不是数值本身,因此,对于数据校验的要求也会低一些,如:Puzzle类休闲游戏;
  • 强同步方案的实现成本一般要高于弱同步方案,并且,由于强同步方案往往需要服务器实现比较复杂的逻辑运算,因此,其服务器的性能开销要较弱同步方案的大一些,相应地,服务器的承载能力就会较弱同步方案的低;

3.2    离线对战

离线对战在实现层面需要关注点是多点数据的修改问题。即同一时刻,某个玩家可能会被他的多个好友同时发起挑战,而在挑战过程中,可能会同时修改对战双方的玩家数据。

多点数据的修改问题,目前都有比较成熟的解决方案,具体方案需要根据业务需求实际来选择:

  • 全局逻辑锁方案

实现要点是用一个单独的locksvr来保持数据修改时的同步。即玩家A发起对玩家B挑战,gamesvr在get玩家A和玩家B数据的同时,会lock这两者的数据。此时,若还有其他玩家需要get这两个玩家数据时,就会get失败,即锁冲突。这样就保证了,每次修改只会有一个玩家在操作。

该方案的优点:

  • 好处在于单独的locksvr可以设计得比较通用,多个项目可以复用,一定程度上可以提高开发效率;
  • locksvr逻辑上比较清晰,部署也比较方便。目前微连等项目就是采用的架构组提供的locksvr组件;

不足的地方:

  • 当交互比较频繁时,locksvr的机制可能会导致比较多的冲突,从而会影响玩家的游戏体验。这个问题在webgame中,玩家可能不会太敏感,这跟玩家的操作习惯有关,当冲突发生时,玩家一般刷新一下页面操作即可恢复正常。而在手机游戏中,需要根据具体游戏业务来评估;

 

  • 增量修改方案

实现要点是gamesvr修改玩家数据时,只提交修改的相对值,各个gamesvr的修改数据请求汇总至一台中心服务器(热点服务器)进行,因为只有一个地方修改,故修改数据自然会保持队列同步。

该方案的优点:

  • 最大的好处是不会产生修改引发的冲突问题;
  • Gamesvr为无状态服务器,逻辑会比较简单;

不足的地方:

  • 要求修改的数据结构比较简单且单一,否则会导致中心服务器的逻辑处理复杂度成倍增加;
  • 由于所有数据的修改均在中心服务器进行,故其有单点风险;

 

(三)Compare And Swap

实现要点保证每次提交的操作,只有一个是成功的。即gamesvr修改玩家数据前,先获取该玩家的cas值,并在修改数据时把cas值带上。数据到达DBSvr时,会检查cas值的合法性,检查通过,则允许修改数据,同时将当前cas值加1。此时,若有其它gamesvr提交同一玩家的修改请求时,会发现cas值与当前的不匹配,则拒绝此次修改,同时,返回一个错误给这个gamesvr的请求。

该方案的优点:

  • 它其实是前两种方案的一个折衷方案,相对于全局锁的强锁定(get数据就会锁定),它只会在set数据时判定数据是否冲突,即有玩家A修改玩家B数据时,玩家C依然可以get玩家B或玩家A的数据,不会引发冲突问题;
  • 该方案同样可以做到通用;

不足的地方:

  • 依然有强交互时,可能有比较多的冲突问题;
  • 需要有DBsvr支持该CAS机制;

注:目前公司的CMem组件支持CAS机制;

 

3.3    半实时对战

半实时对战本质上还是在线玩家之间的PK,只是客户端在表现手法上,与实时对战有所区别。以《女巫之战》为例,若换成半实时对战,则对战开始后,对战界面只显示玩家自己一个人的棋盘,对手玩家只显示一个Avatar Icon和血条。

半实时对战的实现方案可参考实时对战中的弱同步方案。

4       我们的选择

上面讨论了三类对战需求,在实现层面上,可供选择的设计方案。并且分析了每种设计方案的优缺点和适用场合。咱们微项目具体选择哪种实现方案,需要根据特定的业务需求来决定。选择原则是:方案满足需求,实现代价最小

每月自评之四:2013年4月

(一)我读

     本月阅读过的书籍:

     (1)《OpenGL超级宝典
          1)推荐指数:四星半
          2)简评:学习OpenGL最佳入门读物,并且书中刚开始的两章,对计算机图形学的基础知识也作了非常简要地介绍,对于想要夯实游戏编程的基础知识的同学来说,此书的确是一本佳作!
          1)推荐指数:五星
          2)简评:不愧为amazon五星推荐书籍。无论是学习Unity入门知识,还是再想全面了解Unity基础知识,本书都是非常好的选择。阅读过程中,最好是下载好配套的asset资源,这样在边看边练习,效果更佳!
(二)我看
     本月看过的电影:
     (1)《国家公敌 Enemy of the State
          推荐指数:四星半
          推荐理由:故事题材与演技俱佳
     (2)《成事在人 Invictus
          推荐指数:四星
          推荐理由:故事虽然有主旋律的嫌疑,但的确是真实的史实。而且,由两位super star来主演(两位恰好是俺最喜欢的好莱坞演员:Morgan Freeman和Matt Damon),为影片增色不少,虽然也有人说,摩根与曼德拉不像,但这都是小小瑕疵,无伤大雅!
     (3)《登堂入室 Dans la maison
          推荐指数:四星
          推荐理由:不错的剧本,值得反复多看几遍!
          推荐指数:三星半
          推荐理由:这是一部带有暗喻性质的典型主流恐怖片,收获的不是影片本身,而是其所讽刺对象带来的启示。
          推荐指数:三星
          推荐理由:三星是给凯奇的。
(三)我听
     (1)【东吴相对论
               依然订阅podcast,依然占据我吃饭、走路、排队等零碎时间…
     (2)【Black Cat】系列之《King Arthur and his Knights》
               被亚瑟王的传奇经历所吸引,发现自己慢慢喜欢上西方魔幻故事了
     (3)【Black Cat】系列之《Oliver Twist
               可怜又幸运的Oliver,不朽的名著。
(四)我用
    (1)【vs2012】
          本周用vs2012替换了之前用的vs2010,刚开始使用,发现vs系列至此版本已然修成神器,不但编译速度比之前版本快很多,各种提升开发效率的辅助功能也增强很多,可以抛弃vc助手等工具了
     (2)【Win7桌面小工具】
          用win7这么久了,还是第一次用这东东,说来也惭愧。在本本上增加了日历、时钟、天气预报等工具,既美观又实用
(五)我藏
     本月摘录收藏的各类帖子和文章:
     (1)技术:12篇
     (2)产品:7篇
     (3)行业:4篇
(六)我做
          用U3D做一个FPS小demo,还未完工,但很有趣!
(七)我玩
     (1)【大掌门】
          玩至20级,刚开始玩时,第一印象不错,但玩到这个阶段觉得整个游戏的系统设计方面还不是特别丰富。只是接下来过关成长,必须要花money才能进行下去了,连每日任务都木有。客户端快速更新的设计对玩家很友好(即每次更新无需到appstore下载)。
     (2)【王者之剑】
          蓝港在移动平台的首作,传闻在ios和android月流水均过千万。玩过之后,感觉的确不错。无论是玩法内容,还是游戏本身的品质,个人感觉都排在目前手游市场的前列。游戏是用U3D开发,难怪能这么快在这两个平台均同时推出。目前感觉唯一不足的是,客户端不太稳定,我在iPad1上玩,基本上10左右就会崩掉一次,或许是我的Pad out了吧,有朋友有iPhone4上玩,说crash的问题倒没那么严重。
     (3)【刺客信条3】
          传说中的3A大作,终于利用小长假的时间体验了一把。玩了三章内容,整体感觉很好。每个场景、背景音乐、主角/Npc动作、战斗体验、音效等待、都是精心设计,能将你完全带入至游戏世界中。加上这期的游戏背景也是我感兴趣的美国独立战争期间,因此,这款大作的确值得游戏爱好者好好体验!
     (4)【足球经理2013】
          作为近十年的Fmer,一直在玩盗版,说起来真是惭愧之至。本月终于决定入手正版,看各种推荐,还是选定淘宝上Steam的一个代理商,卖家服务很热情,付完款后,就给了Steam的SN,然后去Steam下载安装,花了一个半小时左右,终于可以玩了。虽然花了RMB240多银子,但绝对物超所值。这一代的FM比之前的数据更加真实,AI更加合理。3D比赛面面的改进虽然不如官方宣传的那样好,但还是可以看有改进的地方。用一句来概括就是:更加真实!我想,这是任何模拟经营类游戏最重要的core play!
(八)我思
       本月经历了转岗这件大事,前后几个月的纠结终于也划上了句号。
       皮皮的出生,是促使我下决心转岗的很重要的原因。这近两年来,长期与老婆分隔两地,真是委屈她了!无论是怀孕期间的她张罗着装修房子,还是皮皮出生后,她细心呵护着小Baby,都是她独自一人在承担,我却没有为她分担什么,心中愧疚有加!
       幸运的是,转岗过程还算比较顺利,两边部门的领导都给予了理解和支持,在此,也再次感谢了!
       新项目,新同事,新挑战!
       为自己加油!

听《陌陌移动开发技术分享》有感

听陌陌CTO李志威同学讲陌陌的技术发展历程,有一些启发和思考以记之。

(1)前期技术选型时,尽量用业界已有的通用和成熟技术,以避免自己闭门创车和重复发明轮子,这对于一个创业团队尤为重要!
(2)Redis+MongoDB的存储系统,为后续灵活扩容和性能支撑提供保障;
(3)选用“云”主机,可以避免前期没有专业运维人员和DBA的烦恼;
(4)用扛住,后优化的思维;
(5)衡量代码质量的中心指标是代码的可读性和可维护性,以及设计是否够简单;
(6)自动监控和报警是运维必不可少的环节;
(7)一键部署与持续集成工具的运用;
(8)移动化的运维,即用手机要查看服务器的各种监控信息,如:Redis队列,各类用户统计数据等等,个人认为这是运维工作的一个很好创新;
(9)应用supervisor来管理所有服务器后台进程;
(10)用“重启”这种看似偷懒的做法,来解决部分实际中遇到的问题;
(11)使用Ganglia来监控服务器集群的各项性能指标,如:cpu 、mem、硬盘利用率, I/O负载、网络流量等;
(12)使用fabric来管理批处理任务,以方便自动化部署;
(13)使用puppet自动化配置和部署系统;
(14)一台新服务器自动上架和部署的全过程如下:
     1)供应商送到机房,按我们的布线方案上架
     2)使用远程装机,10分钟
     3)使用Puppet自动同步一切配置
     4)使用yum安装自定义配置打包的服务
     5)使用Supervisor管理所有服务进程
     6)加入到Nagios、Ganglia、自定义监控
(15)工程师移动运维时所做的工作如下:
     1)无聊时查看最新的用户注册情况、系统状态
     2)手机上线代码
     3)上线服务后通过手机查看数据、队列、服务器负载是否正常
     4)户外用手机重启服务

每月自评之三:2013年3月

(一)我读

     本月阅读过的书籍:

     (1)《说,就真来不及了
          1)推荐指数:四星
          2)简评:很薄的一册子,却能从另一个维度,给人生活的真谛!
     (2)《持续交付
          1)推荐指数:四星
          2)简评:被习惯性忽略了的重要软件工程实践,在这里娓娓道来,当然,最重要的还是在实践中应用这些原则,要活用,不能套用!
(二)我看
     本月看过的电影:
     (1)《劫案迷云 Stolen
          推荐指数:三星
     (2)《逃离德黑兰 Argo
          推荐指数:四星
          推荐指数:四星
(三)我听
     (1)【东吴相对论】
               继续在podcast下载,然后放在iPod上,在上、下班的路途听,两个老男人,谈笑间,给人新的启迪。
     (2)【Cocos2d-X跨平台之路
               来自cocos2d-x核心开发者杨丰盛同学的分享,可以了解cocos-x的基本架构和周边辅助开发工具等内容
(四)我用
    (1)【staruml】
          开源轻量级的UML作图工具,容易上手,可以作程序设计或阅读代码时的辅助工具
(五)我藏
     本月摘录收藏的各类帖子和文章:【14篇】
     (1)服务器技术:3篇
     (2)行业观察:4篇
     (3)产品:10篇
     (4)U3D:8篇
     (5)通用编程:10篇
     (6)计算机图形学:10篇
(六)我做
          做各种奶爸必须要做的事情!
(七)我玩
     (1)【大掌门】
          月流水上2500w的手游,卡牌+武侠+more and more
(八)我思
       本月有一半以上的时间在家休陪产假,经历了小皮皮出生时的喜悦,也经历了陪伴老婆“坐月子”的全过程。老婆“坐月子”期间也颇为不顺,首先,是晚上起来要给皮皮喂奶,导致没有休息好,没有休息好的一个悲催后果是:不幸感冒了!感冒后,先是吃中成药,没啥效果,不得已,只好打点滴,而且是连打了四天,才有所好转。本来坐月子期间就不宜外出,可怜我亲爱的老婆,为此来去好几次医院。真要求神保佑,不要出啥子月子病。不然,即使我内疚一辈子,也于事无补!真后悔没有请月嫂或者去月子中心,家里即使有两个老人照顾,也不靠谱啊!
       在此期间,给小Baby办理入户,各种证件的琐事就不一一足道了,总之,跟天朝各部门打交道,你总是会狠狠牙,然后,各种愤怒吞在肚子里。
       有鉴于国内奶粉的种种问题,吃国内商场卖的奶粉已是引火自焚的事情。哪怕是那些国外的品牌的,也不能省心,因为,即使大公司如:雅培、美赞臣等,他们在不同国家的卖的品牌系列和生产标准都不一样的。还好庆幸的是,深圳毗邻香港,可以去香港买到相对放心一点的奶粉,即使坑爹的每人只能限买两罐的脑残政策在3月1号出来实施后,你也不能嫌麻烦的!
       最后,谢谢各路来看望皮皮的朋友!

每月自评之二:2013年2月

 现把为数不多的时间里作的学习,小结如下:
(一)我读

     本月阅读过的书籍:

     (1)《高效程序员的45个习惯
          1)推荐指数:四星半
          2)简评:极具实践性的敏捷开发行动指南!
     (2)《程序员的思维修炼
          1)推荐指数:四星
          2)简评:跳出惯性思维,从另一个维度解读我们的思维方法论,读一遍不够!
(二)我看
     本月看过的电影:
     (1)《一代宗师 一代宗師
          推荐指数:三星半
     (2)《风语战士 Windtalkers
          推荐指数:三星半
     (3)《哥斯拉 Godzilla
          推荐指数:三星
(三)我听
          无
(四)我用
          微软提供的免费visual studio插件工具
(五)我藏
     本月摘录收藏的各类帖子和文章:【14篇】
     (1)敏捷开发:7篇
     (2)行业观察:4篇
     (3)产品:3篇
(六)我做
     (1)在google code上创建个人文档和代码项目,也可以作为另外一个云备份。
(七)我玩
     (1)COC
          火是有道理的!我也入迷了好一阵子。
(八)我思
       这个月对于普通人来说,核心主题是回家过新年。临近春节,许多人的工作效率恐怕也要打开折扣了,呵呵。不过,对于我来说,还有一个很大的事情,就是小Baby:皮皮来到我们身边!老婆辛苦怀胎十月,终于于2013年2月19日凌晨7点9分,顺产生下小皮皮,重7斤7两。这是2013年我们全家最大的事情!

       这个月来,小皮皮却没少波折。老婆出院后不久,小皮皮却因黄疸过高,又住进医院,作全封闭式治疗,家属也不能陪护。这对我们来说,是一件很残忍的事情,尤其是老婆和老妈,不舍、牵挂、难过各种情绪交织在一起。小皮皮不在家里,少了哭闹,也少了欢喜!
       这个月虽然请了陪产假,呆在家里。理论上可支配的时间比工作的时候多了许多。但需要照顾老婆和小皮皮,根本无暇再读书和coding,当然,这何尝不是另外一种学习呢?学习育人之道,依然长路漫漫!
【声明:若有摘录,请注明来自:http://gameislife.info/archives/153】

《高效程序员的45个习惯》读书笔记【思维导图】

《高效程序员的45个习惯》这是一本好书,书中的观点直白、朴素,极富实践性!当然最重要的,还是要在实际项目中身体力行!

下面摘取书中要点,花了大半天时间做成思维导图,以方便随时查阅。

高效程序员的45个习惯

1 宣言

1.1 个体和交互胜过过程和工具

1.2 可工作的软件胜过面面俱到的文档

1.3 客户协作胜过合同谈判

1.4 响应变化胜过遵循计划

2 原则

2.1 (一)态度决定一切

2.1.1  做事

1)指责不会修复Bug,把矛头对准问题的解决办法,而不是人

2)一个重大的错误应该被当作是一次学习而不是指责他人的机会

2.1.2  欲速则不达

1)不要坠入快速的简单修复之中,要投入时间和精力保持代码的整洁

2)不要让开发人员孤立的编写代码

3)阅读代码的频率越高越好

4)代码复审不仅助于代码更好理解,也是发现Bug最有效的方法之一

5)防止代码难懂的重要技术就是单元测试

6)所有大型系统都非常复杂,没有一个人能完全明白所有代码,除了深入 了解所负责的那部分代码,需要从更高层面来了解大部分代码,理解系统 各个功能块之间是如何交互的

7)实际工作中,可以先快速修复问题,即为了应对紧急情况,但事后一定好细致分析

2.1.3  对事不对人

1)询问你的队友,并提出你的顾虑

2)礼貌待人,负面的评论和态度会扼杀创新

3)必须把重点放在解决问题上,而不是极力证明谁的主意更好

4)能容纳自己并不接受的想法,表明你的头脑足够有学识

5)设计充满了妥协,工作中不感情用事是需要克制力,展现成熟大度来

6)团队能公正地讨论一些方案的优点和缺点

2.1.4  排队万难,奋勇向前

1)动手去做比光抱怨好得多

2)当发现问题时,不要试图掩盖问题,要诚实、勇敢说出实情,并与团队一起寻求好的解决办法

2.2 (二)学无止境

2.2.1  跟踪变化

1)迭代增量式的学习:每天计划用一段时间来学习新技术

2)了解最新行情:阅读博客、maillist等

3)参加线下技术活动

4)参加研讨会议

5)阅读好书

6)不需要精通所有技术,但要清楚知道行业的动向

7)明白为什么需要这项新技术,它试图解决什么样的问题?它可以被用在什么地方?

2.2.2  对团队投资

1)一个学习型的团队才是好的团队

2)每周要求团队中的一个人主持讲座,介绍新技术、工具或者书籍

3)坚持有计划有规律地举行讲座:持续、小步前进才是敏捷

2.2.3  懂得丢弃

1)学习新技术时,多问问自己,是否还在沿用旧的态度和方法

2)新技术会让人感到一点恐惧,但你的确需要学习它

2.2.4  打破砂锅问到底

1)为了解决问题,你需要知道许多可能的影响因素

2)当找人询问任何相关的问题时,让他们耐心地回答你的问题

3)不能只满足于别人告诉你的表面现象,要不停地提问直到你明白问题的根源

2.2.5  把握开发节奏

1)许多不成功的项目中,基本上都是随意安排工作计划,没有任何的规律

2)敏捷项目会有一个节奏和循环,让开发更加轻松

3)最大的节拍就是迭代时间,一般是1-4周,确保每个迭代周期的时间相同很重要

4)项目开发需要有一致和稳定的节奏

5)在每天结束的时候,测试代码,提交代码,没有残留代码

6)不要搞得经常加班

2.3 (三)交付用户想要的软件

2.3.1  让客户做决定

1)开发者需要知道哪些是自己决定不了的

2)具体到游戏行业,客户分两类,一类是项目策划,他们是需求的提出者 故在设计开发前,需要与之作深入的沟通,明确他们的意图;一类是玩家, 他们是最终使用者,开发者可以站在玩家角度去分析策划案的价值和作用

2.3.2  让设计指导而不是操纵开发

1)时刻谨记,此阶段提出的设计只是基于你目前对需求的理解 而已,一旦开始了编码,一切都会改变

2)敏捷开发中,少用文字,多用图表来表达设计意图,常用序列图和类图

3)设计满足实现即可,不要过于详细

4)好的设计就是能适应变化的需要

5)先设计类的职责,再设计其方法和数据类型

1.类名

2.职责:应该做什么

3.协作者:要完成工作它要与其他们什么对象工作

6)白板、草图、便利贴都是好的设计工具,复杂的建模工具只会让你分散精力

2.3.3  合理的使用技术

1)这个技术框架真能解决问题吗

2)你将会被它拴住吗

3)维护成本是多少

4)不要开发你能下载到 东西

5)首先决定什么是你需要的,接着为这些具体的问题评估使用技术

2.3.4  保持可以发布

1)提交代码流程

1.确保自己编写的代码通过单元测试

2.检出最新代码,并再次运行测试

3.提交代码至版本管理服务器

2)持续集成系统就是在后台不停地检出、构建和测试代码的应用

3)保证你的系统随时可以编译、运行、测试并立即部署

4)如果不得不让系统长期不可以发布,则需要做一个分支版本

2.3.5  提早集成,频繁集成

1)决不要做大爆炸式的集成

2)代码集成是主要的风险来源,提早集成,持续面有规律地进行集成则可避免

3)集成和独立不是互相矛盾的,可以边进行集成,边进行独立开发

2.3.6  提早实现自动化部署

1)一开始就实现自动化部署应用

2)在不同的机器上用不同的配置文件测试依赖的问题

2.3.7  使用演示获得频繁反馈

1)每隔一周或两周,邀请所有客户,给他们演示最新完成的功能,积极获得他们的反馈

2)用Bug系统记录跟踪所有系统Bug

3)在游戏项目里,每完成一个迭代版本,尽早给策划同事及制作人演示,甚至在整个项目组测试演示 ,并收集大家反馈的Bug和建议

2.3.8  使用短迭代,增量发布

1)迭代开发是在小且重复的周期里,完成各种开发任务:分析、设计、实现、测试和获得反馈

2)游戏项目中,迭代时间最好是以一周为单位

2.3.9  固定的价格就意味着背叛承诺

1)需要根据业务复杂度、团队成员的能力水平、市场环境就诸多因素来评估项目的开发周期 这是一件很考验管理者(包括开发者)的经验与技术水平

2.4 (四)敏捷反馈

2.4.1  守护天使

1)敏捷就是管理变化的,而代码则是变化最频繁的东西

2)所谓守护天使即自动化的单元测试+后台自动构建

2.4.2  先用它再实现它

1)编程之前,先写测试

2)先写测试可以站在用户的角度来思考,并有利于消除过度复杂的设计

3)使用TDD作为设计工具

2.4.3  不同环境,就不同问题

1)在各种支持的平台和环境中运行测试用例

2.4.4  自动验收测试

1)为核心业务创建验收测试用例,这不同于单元测试

2)在游戏项目中,要分别为客户端和服务器创建验收用例,客户端侧重于表现效果验收, 服务器侧重于业务逻辑验收

2.4.5  度量真实的进度

1)每个工作日,团队成员要重新评估完成一个任务还需要多少小时

2)我的做法是每天在上班的路上想好当天要做的事情,在正式开工前,用google日历列出一天的任务列表, 列表的条目是具体可操作的工作,粒度的划分需要一定的经验,评估完工时间的单位是小时

2.4.6  倾听用户的声音

1)没有愚蠢的用户,只有自大的开发人员

2)每一个抱怨的背后都隐藏一个事实:找出真相,修复真正的问题

2.5 (五)敏捷编码

2.5.1  代码要清晰地表达意图

1)代码清晰程度的优先级应排在执行效率之前

2)编写清晰的而不是讨巧的代码

2.5.2  用代码沟通

1)不要用注释包裹你的代码

2)注释包含的信息:目的、输入、输出、异常,使用RDoc、javadoc、ndoc工具规范化注释

3)注释要说明为什么写代码,而不是解释代码做了什么

2.5.3  动态评估取舍

1)考虑性能、便利性、生产力、成本和上市时间,如果性能足够,则将注意力放在其他因素上

2)过早的优化是万恶之源

2.5.4  增量式编程

1)如果不对自己编写的代码进行测试,保证没问题,就不要连续几小时编程

2)写了几行代码之后,可以进行一次构建/测试循环,在没有得到反馈前,不要走太远

2.5.5  保持简单

1)除非有不可辩驳的原因,否则不使用模式、原则和高难度技术之类的东西

2)简单的解决方案必须要满足功能需求,不要过分简单

2.5.6  编写内聚的代码

1)要避免创建很大的类或组件

2)考虑实现一个简单的功能变化需要变更多少代码

2.5.7  告知,不要询问

1)开发人员绝对不应该基于被调用对象的状态做出任何决策,更不能去改变该对象的状态, 这样的逻辑应该是被调用对象的责任,而不是你的,即符合依赖倒置原则

2)要将功能和方法分为“命令”和“查询”两类

3)用发送消息或事件来代替调用函数

2.5.8  根据契约进行替换

1)通过替换遵循接中契约的类,来添加并改进功能特性

2)多使用委托而不是继承

2.6 (六)敏捷调试

2.6.1  记录问题解决日志

1)维护一个保存曾遇到的问题以及对应解决方案的日志

2)记录发生问题时应用程序、应用框架或平台的特定版本

2.6.2  警告就是错误

1)找到一种方式让编译器将警告作为错误提示出来

2)解释性语言通常也有标志,相用相关标志,然后捕获输出

2.6.3  对问题各个击破

1)不要试图马上了解系统所有细节,要想认真调试,就必须将有问题的组件或模块与其他代码分离出来

2)用原型进行分离

2.6.4  报告所有异常

1)处理或是向上传播所有的异常

2)不是所有的问题都应该抛出异常

3)报告的异常应该在代码的上下文中有实际意义

4)记录运行日志

2.6.5  提供有用的错误信息

1)提供详细的运行日志,记录运行状态

2)区分错误类型:程序缺陷、环境问题、用户错误

2.7 (七)敏捷协作

2.7.1  定期安排会面时间

1)立会:大家到公司的30-60分钟进行

1.昨天有什么收获

2.今天计划要做哪些工作

3. 面临着哪些困难

2)立会时,只能给予每个参与者很少的时间发言,如:两分钟

3)采取立会的形式需要管理层的承诺和参与

4)立会时间不要超过30分钟,10-15分钟比较理想

5)立会时,要注意报告的细节,只给出具体的进度,但不要陷入细节之中

2.7.2  架构师必须写代码

1)作为设计人员,不能理解系统具体细节,就不可能作出有效的设计

2)只通过一些高度概括的、粗略的设计图无法很好地理解系统

3)鼓励程序员参与设计,优秀的设计从积极的程序员那里开始演化

2.7.3  实现代码集体所有制

1)在团队中实行任务轮换制,让每个成员都可以接触到不同部分的代码

2)注意有些场合是不能采用代码集体所有制的,这时候,人多了反而容易误事

2.7.4  成为指导者

1)教学相长

2)分享自己的知识、经验和体会

2.7.5  允许大家自己有办法

1)作为指导者,应该鼓励、引领大家思考如何解决问题

2)用问题来回答问题,可以引导提问的人走上正确的道路

2.7.6  准备好后再共享代码

1)绝不要提交尚未完成的代码

2)完成一项任务后,应该马上提交代码

3)保证所有代码通过单元测试

4)使用持续集成是保证源代码控制系统没有问题的一种良好方式

2.7.7  做代码复查

1)代码刚完成时,是寻找问题的最佳时机

2)让不同的开发人员在每个任务完成后复查代码

3)运用静态代码检查工具,如:Similarity Analyzer、Jester

4)注意每次复查的代码量不宜过大,保持每次在1k Line以下

5)代码复查内容

1.代码能否被读懂和理解

2.是否有任何明显的错误

3.代码是否会对应用的其他部分产生不良影响

4.是否存在重复代码

5.是否存在可以改进或重构的部分

2.7.8  及时通报进展与问题

1)发布进展状态、新的想法和目前正在关注的主题,不要等别人来问题项目状态如何

2)每日立会让每个人都能明确了解最新进展和形势

3)可以作日报和周报来反馈项目进度

3 工具

3.1 Wiki

3.2 版本控制

3.3 单元测试

3.4 自动构建

4 宗旨

4.1 以人为本

4.2 团队合作

4.3 快速响应变化

4.4 可工作软件

5 核心:Just Do It!!!

【声明:若有摘录,请注明来自http://gameislife.info/archives/133】