使用工具可以帮助你高效的完成工作,这里推荐和scrum流程完美匹配的JIRA,以及几个辅助开发和部署的工具。 JIRA & WIKI
JIRA几乎成了敏捷开发的标配工具,你的公司不使用JIRA进行项目管理你都不好意思和人打招呼。无论是任务分配、项目追踪还是Bug汇报,都和Scrum结合的天衣无缝。加上Confluence做wiki,基本上软件开发周期中需要追踪和文档化的东西都齐活了。
Gmail & Gtalk & Google Doc
Google的这三个套件并不是必须的,完全可以找到对应的替代品。但当你基于它们进行团队的沟通和信息交流时,你会发现十分的好用,特别是对游戏开发团队。无论邮件,内部的IM,PPT、Word文档的共享,一个链接就能搞定一切,省去了传来传去且版本变化后不一致的问题。墙裂推荐这套工具作为公司的信息交互平台,当然前提是需要科学上网。
程序开发人员技能树
预演环境(Staging):一个在架构上和线上环境完全一致的环境,唯一的不同就是集群规模、机器性能、数据量等。线上的架构都是分布式的,而Dev这样的环境因为便捷性的考虑都是一个all in one的模式,很多在分布式系统中存在的问题没法在Dev环境下测试出来。Staging是上线流程中最后的一环,相当于守门员,不可或缺。
数据可以说是互联网产品最宝贵的资产,特别是用户产生的数据(UGC)。抛开黑客攻击这种问题不谈,我们只讲如何避免操作失误造成的数据丢失问题。
给大家讲一个真实的例子。2010年左右我还在某SNS网站做社交游戏,我们当时有一款品质非常好的农场类游戏,几千万用户,百万级别的DAU,各方面数据都很稳定。有一次有个新来不久的同事为了做一些验证测试,打算把自己线上的用户金币数进行调整,于是他在mysql终端中写下了这样的代码:
update user set money = 10000;不知道是疏忽了还是当时迷糊了,在没有加where条件的情况下就回车执行了。对于一个千万量级的表来说这样的更新操作是很慢的,由于经验不足他也没有对半天都没响应的情况深究,转头去忙别的事。最终的结果,所有的玩家金币被更新成了一样的数量,游戏的经济系统和生态完全崩溃。更倒霉的是数据库的备份是按周而不是按天,只能回滚到一周前的数据。对于这种数据级的游戏,一周时间在数据上的gap是巨大的。整个团队没合眼花了三天两夜通过log等各种方式进行数据修复,但结果并不理想。从此之后这款游戏的各项数据指标一路下滑,提早的结束了生命周期。
这样严重的事故告诉我们,需要在以下几个方面建立完善的制度和流程: