念宏的胡言乱语

Facebook股权结构设计

李谭伟 — Sat, 04 Feb 2012 14:06:12 +0000

许多情况下，互联网公司完成第一轮或者第二轮融资后，公司的创始人就不再能够完全掌握公司的控制权了。不管是2名创始人＋2VC+1独立成员组成的董事会还是1创始人＋1VC+1独立成员组成的董事会，创始人都不占优势。而经过10多次重大的融资后，扎克伯格以28％的股权还能掌握公司的控制权是一件非常令人震惊的事情。事实上，这样的效果就是通过Sean Parker借鉴其他互联网公司设计的天才股权结构所产生的。

(点击图片查看大图)

律师Raymond Wang在知乎上对Facebook A:B＝1：10的投票权这样进行了解释：

扎克伯格本人只拥有不到30%的股份，但其持有的B系列股的投票权是A系列股的10倍，所以拥有大于持股比例的投票权。这种设置其实并不是Sean Parker本人的天才设计（其作为“连环创业者”对此确实非常重视），在科技公司中并不罕见。比如Google公司，也是双层结构（Dual Class Structure，或叫“超级投票权”“牛卡计划”），对外部投资者发行的A股有1票投票权，管理层持有的B股则有10票，佩奇和布林在2010年售股前拥有5770万Google B股——约等于18%的Google流通股本和59%的投票权，售股后跌至48%的投票权，从理论上丧失了绝对控制权。百度也是这种10：1的双层结构，而Zynga更牛，设了三层结构，投票权之比是70：7：1！不过双层结构在纳斯达克以外的很多交易所（包括大陆和香港证交所）都不被允许，因为被认为可能会伤害公众投资者利益。

一些股东和扎克伯格达成了投票协议（voting agreements），同意扎克伯格代表他们的股份投票。这使扎克伯格拥有Facebook股份56.9%的投票权。

由于上市前会不断引入风险投资者，大部分科技公司创始人的持股比例都不超过50%，有的甚至低于10%。即便使用了双层结构，也不能保证控制权是“绝对的”“永久的”，因为创始人本人很难说一辈子都不再出售手中的股票或者引入比较大的股东（反而是国有控股企业和家族企业经常这么干）。假设扎克伯格将来为了做慈善卖掉一部分股票，也是有可能丧失理论上的绝对控制权的。而且外部投资者愿意接受投票权悬殊的“不平等条约”，完全是因为该公司比同类公司增长更快更赚钱，如果哪天公司业绩变差，投资者纷纷抛售，这种双层结构是否还能维持也是值得怀疑的。

企业创始人往往拥有远大于持股比例的控制力，毕竟是他把企业做大的，员工都是跟着他打天下的，股东的回报都是他带来的。乔布斯和马云对公司的有力控制都不是因为他们的投票权高，而是业绩出色加上个人感召力。反之，一些企业的创始人尽管从持股上牢牢控制公司，但由于不愿引进外部投资者，也不给员工股权作为激励，企业始终无法长大。

事实上，扎克伯格此前一直对Facebook上市持保守态度的主要原因也就在于控制权的问题。因为一旦上市，也就意味着其需要更好的在股东利益和控制权之间进行权衡。扎克伯格的长期计划可能与股东之间的短期利益诉求格格不入，从而导致公司内部出现问题。如今上市已经不可避免，那么正如该律师所言扎克伯格如果希望能继续保持自己对公司的控制，那么他要能够不断的创造出色的业绩，否则其暂时的投票权协议也不一定能完全确保其仍然很好的把持Facebook。

或许这些文章您也喜欢：

阿里巴巴存在的隐患 (0)

阿里巴巴存在的隐患(0)

Android 4.0设计规范（附全文翻译pdf）

李谭伟 — Fri, 03 Feb 2012 03:34:05 +0000

在拜读和翻译了Android design设计指导后，对比Android 4.0与Android2.3及之前版本的app设计指导，总结了Android 4.0设计的10大改变：

1. 导航栏 (详见模式PATTERNS>导航Navigation)
由之前的物理按键导航（返回、菜单、搜索、主页）变成了嵌入屏幕的虚拟按键（返回、主页、最近任务）。

左侧为早期有4个物理按键的手机，右侧为新版只有3个虚拟按钮的手机

把菜单项和搜索项从导航栏去掉，把之前通过长按主页键才出现的最近任务直接展示在导航栏中。

最近任务的界面
把菜单收起的同时，在软件界面的操作栏上增加了“更多操作”（action overflow），如下图中的黄色圆点所示。

黄色圈部分为“更多操作”（action overflow）的位置和点击后内容的展示方式

2. 操作栏 (详见模式PATTERNS>操作栏Action bar)
操作栏从之前的app图标＋操作，变成如下图所示：
1向上＋2 Spinner＋3 重要操作＋4 更多操作。
其中，向上按钮，点击后是去到当前界面的上一个层级，非第一层级界面有此按钮，第一层级界面则无向上按钮；Spinner 是用于展示内容的下拉菜单，其内容包括视图的快速切换和显示相关内容的完整信息；更多操作（action overflow）是集合操作栏中不常用的和非重要操作的地方。

操作栏可以拆分成下图中的1主操作栏、2顶部栏和3底部栏。如果需要，顶部栏可以承载选项卡tabs，底部栏可以承载主要操作和被收起的更多操作（action overflow）。

在空间足够的横向屏幕展示界面时，被拆分的操作栏，可以灵活合并在一起。如下图中的手机端横竖屏操作栏所示。

3. 多面板布局 (详见模式PATTERNS>多面板布局Multi-pane layouts)
多面板布局更多的是针对平板电脑，把手机端的目录视图和详情视图两个层级的界面，甚至更多的页面，复合展示在同一个界面中，有效地利用平板电脑的屏幕空间，扁平化层级结构，简化导航。这点在iPad上已经运用得相当娴熟了。

4. 选择 (详见模式PATTERNS>选择Selection)
Android4.0中的长按与Android2.3及更早期的版本有很大的不同。早期版本长按操作后，是出现情境菜单的浮出层。在Android4.0中，长按后在操作栏的位置会覆盖一个临时的情境操作栏，不再弹出情境菜单浮出层。在临时情境操作栏的环境下，当前界面的内容项允许被单个处理，也允许被批量处理。

长按Android2.3及更早期系统版本的内容项时，出现情境菜单的浮出层。

长按Android4.0系统版本的内容项时，情境菜单栏覆盖在操作栏上。

在情境菜单环境下，支持批量操作。

5. 返回和向上 (详见模式PATTERNS>返回和向上Navigation with Back and Up)
返回按键用在手机全局的虚拟导航栏中，基于用户最近查看的界面历史，采用时间倒序的方式，连接界面间的关系。向上按钮用在操作栏的左侧，基于层级结构，点击后是去到当前界面的上一个层级，若当前界面已经是最高一级，则没有向上按钮。

黄色部分为点击向上按钮后的页面路径，红色部分为点击返回按钮后的页面路径

6. 主题样式 (详见风格STYLE>主题样式Themes)
推出三套默认主题：Holo浅色主题、Holo深色主题、Holo浅色底+深色操作栏主题。主推app在这三套默认主题的基础上做设计，以加快app研发效率，但只是建议使用，并没有完全强制。视觉设计师们可以重点看下STYLE和BUILDING BLOCKS这两章。

7. Widgets (详见开始吧GET STARTED>UI概览UI Overview)
在原apps页里，用选项卡tabs的方式增加了widgets内容。一改用隐晦方式添加widget的操作和把widgets零散放在桌面呈现的方式。在app设计中，应该提高对widget设计的重视程度。

8. 兼容性 (详见模式PATTERNS>兼容性Compatibility)
向后兼容，考虑到物理导航按键手机如何兼容Android 4.0系统和虚拟导航手机如何兼容Android2.3和更早期版本的apps。

在物理导航按键手机上安装android4.0系统，点击物理按键，在屏幕下方出现action overflow的内容。

在新的虚拟导航手机上安装为android2.3及更早版本系统设计的app，会在屏幕下方的虚拟导航的右侧出现action overflow按钮（如上图的黄色部分）。

在新的虚拟导航手机上安装android4.0，点击action overflow后的展示状态如上图。

9. 强调纯粹的Android应用设计 (详见模式PATTERNS>纯粹的Android)
在Android4.0 app设计准则中，特别强调为Android设计纯粹的Android app，切勿使用其他平台特定元素的注意事项，有以下5个方面：
（1）强调视觉元素的样式要符合android系统；
（2）不用其它平台特有的图标；
（3）不在界面的下方使用选项卡tabs；
（4）区分向上和返回，不在操作栏上使用返回样式的按钮；
（5）不在内容列表里使用向右箭头。

Android系统里，选项卡（tabs）会固定放在屏幕上方，不会放在下方。这点与ios系统不同。

10. 其它细节
增加许多新的交互细节、信息展示和视觉样式等规范，详细见翻译。其中，有几点在此强调下：
（1）新增了横滑移除内容的交互手势。在部分模块中，支持向左或向右横滑移除内容的操作，如最近任务和消息通知抽屉。

（2）视觉的平面化，栅格风正在4.0中上演。
（3）在writing style中明确指出写wording时，要直接使用第二人称“你”。

原文见http://developer.android.com/design/index.html
快速查阅，Android Design全文翻译下载地址：http://cdc.tencent.com/?download=Android-Design-4.0

Android Design全文翻译由CDC D3多媒体小组（江宁、张云）出品。
感谢您的阅读！

(本文出自腾讯CDC博客: http://cdc.tencent.com/?p=5082)

随机推荐阅读：

敏捷开发思想谈

李谭伟 — Fri, 03 Feb 2012 03:30:01 +0000

敏捷的原则

敏捷开发其实并没有标准型的流程。SCRUM也只是众多衍生体中的一个。实际上就算是SCRUM的实际使用也情况千差万别。所以首先，请大家有这么个概念：
敏捷开发绝对不是一套一成不变的标准化流程。而更多的是一种自适应，自我优化的流程优化理念。

并没有一定的流程，而是需要大家有对任何自己觉得不对的，不正确的，效率低下的事情的警觉性，和将之提出来并进一步改正的行动力。其次，敏捷之于游戏开发，则更要体现人对游戏本身品质的把握，而非对各种文档的审核，这就是和传统软件开发区别最大的地方。所以，没有最好的流程，只要是合适并且能够持续优化的流程就是好的。

所以：

l 不一样的项目经理会有不一样的流程

l 一样的项目经理，不一样的团队，也会有不一样的流程

l 一样的项目经理，一样的团队，每隔一段时间，都还会有不一样的流程。

迭代想与得

为什么我们要迭代？

进行游戏开发，首先请大家对此铭记于心：

l 我们的设计不一定是我们真正想要的

l 文档内容在我们想象中和实际体验版本时的感受不相等

l 我们没法100%的思考到所有需要思考的角落

同样，要理解为什么要使用迭代，我们需要明白迭代开发从何而来。最初，软件开发行业中，一般都由需求方提需求，开发方拿到需求开始分析设计，一次性开发成型交付。随着行业的发展，软件复杂度的增大，需求变化的增加，大家发现一次成型的版本往往无法满足需求方的需要，于是返工。当这样的情况多了之后，返工就成了一种标准化的流程，系统化的返工其实就是我们所谓的迭代了。当然这是一种比较民间的解释，但是在游戏产业中，这也说明了：

l 迭代的目的是为了应付需求的变化。

这里的需求变化需要我们的额外注意：

l 游戏产业中的需求变化，并非只是指策划或需求方在中途站出来说自己的想法有变。更多的时候，是自己在进行游戏开发的过程中，出于对开发的游戏的认知的加深产生的需求设计的变化。一般来说游戏的需求来源于设计，但是我们的设计却往往并不是我们真实的需求。或者说，我们的设计往往不能满足我们真实的需求。

例如，我们需要一个激烈爽快的单体攻击技能，那么我们的设计可能会涉及到，这个技能的功能，伤害，消耗，动画播放等。这个设计还会涉及到表现：比如技能的动作如何，特效如何，播放速度如何，镜头如何。当我们看到这些设计，我们是否就能确定这些设计能够满足我们的需求？进一步，就算我们看到设计之后，认为能够满足了我们的需求了，但是否在游戏版本中我们实际体验的时候，实际效果能100%符合我们的预期？

当我们清醒地认识到：

l 无论我们在设计上花多少时间，我们都无法完全消除设计的实际效果和预期的差距。甚至在超过某种程度之后，我们花在设计上的时间将会形成浪费（这就是所谓的OVER-DESIGN）。

我们就应该开始考虑，什么时候设计应该停止，什么时候我们就应该开始先做，然后预留足够的时间，把那些可能出现的，和必然出现的问题，留给我们后续的迭代来发现和解决。而不是把这些问题试图在一开始全部解决掉，第一，不现实，第二，不科学。

旋转上升

什么是迭代

那么，迭代究竟是什么？

首先要申明一点是，其实我们现在谈论的迭代并不是纯粹的迭代，而是迭代加增量开发。纯粹的迭代是指没有新需求的加入，第一个版本实现的内容就已经完整，之后的版本只是之前内容的优化。而增量，则指下一个版本是在上一个版本基础上增加内容的开发形式。

那么，迭代加增量开发的意思就显而易见了，而我们需要的开发模式就是这种：

l 在不断以版本为基础的增量功能开发的基础上，不断对已经有的功能进行完善和优化。这就是狭义的迭代

进一步来讲，广义的迭代，则不仅限于我们的功能开发。而且还要对于我们本身的流程，工具，工作方式，方法，习惯等等所有可以改变，可以优化的地方进行优化，进行修改。最终的目的就是通过一个个版本迭代开发，不只功能品质在变好，团队效率，团队流程等各个方面都会变得越来越好。最终形成一个真的具有战斗力的团队。

周期总结会议，以及一系列的问题改正，优化提高事项，以及平时提倡的交流，对于变化的拥抱等等，都是为了这个目标而发生的。所以，

l 敏捷开发是一种精神，而不是一种固定的形式。我们需要有一切都是可以改变的心态和准备，并且真的可以着手去改变任何我们觉得有问题的东西，这样才能真正发挥敏捷迭代开发的优势。

陀螺的转动

如何迭代

迭代的漩涡

首先，我们抽象一下，以便大家能简单的明白迭代的形式。迭代就像是一个漩涡，从漩涡中心开始旋转，越转越大。而处于迭代最中心，所有的东西都围绕它来转动的那个核心，就是我们的产品订单（故事清单）。

而那条旋转的线，就是我们的版本。版本永远围绕着我们的故事清单来开发，（故事清单，抽取于我们的游戏的设计），版本总是由故事清单里寻找需要完成的功能，再将根据实际版本得到的反馈，并更新故事清单。于是功能清单的功能越发的有价值，而版本本身也会越来越有价值。

迭代的步骤

那么，我们的版本该如何围绕我们的功能清单来画这个漩涡？

首先，漩涡是一个环绕的圈，所以我们先确定圈的长度：

l 一个迭代的长度

在这段固定长度中，它其实是一条单向封闭线性的线段，有始有终。有始有终的过程才能被量化和计划。在线段开始时我们从产品清单中取得信息，在结尾会释放一个版本并向产品订单反馈信息。

再进一步深入：

在这线段的开头，我们要从产品订单中取得什么？故事。什么样的故事？价值（优先级）总和最大，且大小（故事点）不超过我们一个周期工作量的故事。仅仅如此么？当然不是，首先，有一个重要的概念：

l 系统

也许有几个故事隶属于同一个系统下，它们共同组成了这个系统，它们全部完成，或者至少关键部分完成。这个系统才是完整的。当系统不完整的时候，这些功能的乐趣根本无法体现。

那么，有可能当我们选择这个周期开发某个高价值功能时，没有开发相应的属于一个系统的其他低价值功能。于是周期末的版本我们发现，由于系统的不完整，这个功能乐趣甚微。如果对这种涉及系统的问题没有认识，那么我们很可能就会对这个高价值功能有错误的认识。（关于系统理论的知识，请参见WIKI系统学一词）

如何避免这个问题？这个时候人的作用就体现出来了。当然我们可以在故事列表上增加一列系统属性，提醒我们。但根本的方法还是一个或者多个对整个故事列表有着足够把握能力的人来进行掌控。

我们需要有人能够全面的了解设计意图，并且对我们的故事列表进行把关，对我们周期开始的需求选取进行主导。有一点大家应该明白，规则和标准都是人制定的，那么我们究竟是依靠标准和规则来更好的控制结果，还是依靠人本身？是完善更好的标准，还是培养出更能把握质量的人？

接下来，线段中的开发过程，本质上其实就是分析需求，制定计划，开始开发。或许会周期内分为更细小的周期进行迭代。但是这些小迭代其实依然是瀑布式开发，这点毫无疑问。区别只是在于，这样的小周期内，我们开发的思想和方针是以敏捷开发的思想为指导的，我们更注重版本，更注重交流，更注重结果。而不是预定义式的开发流程（pre-defined)。

在线段的结尾，一个周期结束了，我们需要做两件事情，第一是将我们体验版本之后的反馈，反馈回故事清单中。或许我们体验某个功能之后会觉得加上另一个功能会更好玩，于是我们提升这个功能的优先级。或许我们会觉得这个功能很无聊，于是我们把同类型的功能优先级都降低。再或者我们添加，甚至删除一些全新的故事（不推荐）。

迭代的节奏

在迭代中，我们还需要注意我们迭代的节奏，什么时候该松，什么时候该紧。什么时候我们允许大家的发散和更多的思考。什么时候我们应该专注于我们的目标并且忽略其他的一切以得到我们最终的版本。这些都是有所讲究的。

这节奏包括各个方面。那么究竟这样的节奏应该如何来走呢？

在一个迭代之内，我们的节奏应该是先松后紧。当然不是说迭代开始时我们的效率可以放缓。这里的先松，是指在一开始时我们可以有更多的想法和思路，更多的探讨和研究。本来我们的迭代工作就是从粗到细，从模糊到精确的进行。在迭代中，我们也如此一步步明确我们的工作。

一旦目标明确，那么迭代周期SPRINT的名称的含义就出来了：我们向着我们的目标冲刺而去。到了这个阶段，我们需要收缩我们的讨论和想象，一切以最后的版本和质量为前提。以尽可能快的速度来开发我们的功能，提高我们游戏的质量，得到我们需要的结果。至于具体的迭代方式，各有不同，我的方式大家可以参加之前发出的那个VISIO图表。某些细节接下来还会讲到。

版本持续统一的意志

为什么需要版本

验证乐趣

我们的设计在我们的脑海里，很可能和在别人脑海里得到的认识是不一样的。

或许大家都能有幸得到统一的认识，但是做出来实际体验的时候又不一定能够符合我们的预期。

就算符合了我们的预期，也许我们玩的时候会发现一些新的点子可以很容易的加入到游戏，并且大幅度的提高游戏性。

所以，多个迭代版本的目的，首先就是为了：验证我们的功能是否符合我们的设计预期。因为:

l 没有实际玩到之前，永远不要相信自己的设计是OK的。

我想强调的是，这里的设计预期不仅仅涉及到我们的功能，事实上作为游戏开发，功能开发永远只占其中的一小部分，还有大部分的时间我们需要用来调整，优化，修改，以达到我们的真实预期。

换一种说法，这里的预期除了功能以外，还有我们对它的感受，也就是这个功能到底好不好玩。而我们关注的重点，也是在好不好玩上。如果只是关注于功能是否完善，那么我们的版本就还离成品有一大段路要走。

所以迭代版本应该是计划功能均可玩，并且没有会阻止我们体验所有需要体验内容的BUG的游戏版本。它是我们评判一切的依据，因为一切功能，一切资源，一切玩法，在进入版本可以被我们体验之前，都存在不确定性，只有最后经过版本的体验，这一切的不确定性才能消除。

持续集成

其次，敏捷开发的要求是快速迭代。但是这里的快速迭代其实远比大家想象的还要快速。或许大家觉得正确的快速迭代就是每一个周期，或2周，或一个月就需要一个版本出来。迭代速度比起传统开发确实快了许多，版本也多了许多。但是事实上的快速迭代远比一个周期要短的多。理想的快速迭代，应该是：

l 每个功能，每个改动完成之后都有一个版本能够立即对功能进行验证，进行体验。

让我们对游戏的改变把握得更直接和高效。让大部分对游戏方向的修正都发生在开发当中而不仅仅发生在周期的开头或者末尾。原因就如我所说，每一个功能从完成，到有乐趣，都需要有一个打磨的过程。在打磨之前，很有可能这个功能根本没有乐趣。所以实际上，我们一周要开发一个功能，很可能我们前4天就需要把功能开发完毕，周四出一个版本进行体验。然后周五针对周四的反馈进行一些BUG修正和反馈修改。之后乐趣才出的来。

是的，如果是理想情况的话，每一个功能无论大小都应该是这样的一个流程。哪怕是一个只有半天开发周期的功能，我们在3个小时开发后也需要出一个版本对功能进行验证，并提出反馈改进（如果有的话）。之后优化到大家觉得这个功能合格或者有存在的价值之后，我们才会继续下一个功能。

这样的过程当然过于理想化，每一个功能我们都可以几乎无限的优化下去。所以我们也需要对优化的程度进行取舍。这样取舍的标准还是最终会基于我们开发者自己的个人能力和标准上。更重要的是，我们需要建立每一个功能和变动都需要一个版本进行验证的意识。进而才能追求我们的版本质量和效率。

冲刺的艺术

效率

敏捷开发绝对不是牺牲效率追求品质的开发模式。

相反，在每一个迭代当中：

l 效率才是需要追求的第一位。

唯有在尽可能快地发布版本之后，我们才能根据版本的反馈，进行修正。进而得到更好的版本质量。大部分时候，我们需要的仅仅是以最快的速度得到我们需要的原型。验证我们的设计。为此我们需要尽可能的追求效率。

那么，如何得到我们需要的效率？

范围

首先，永远不要做多余的事情。一旦目标明确，那么我们的目标就是所有我们要做的，在目标范围内的质量优化，必要的代码改善，必要的体验优化，都是可以做的。但是离开了我们目标范围的事情，一件都不要做。

这里的范围，则是一个度量。而这个度量的划分，则又一次，需要依据我们这些人来判断。它需要我们深刻的理解到，我们制定这些目标的意义，我们要实现的究竟是什么，我们应该优化到什么程度？

我们有多少时间，那么我们就只能设计到什么程度，做到什么程度。而更多的次要的需求，我们有时间再考虑，更多的兼容性想法我们可以想，前提是我们这个版本还有时间。我们需要画一条基准线，在有限的时间里，我们能做多少内容，该做哪些内容？一切行动都需要以我们的目标为准则。当然，我们还需要考虑量产和下个阶段的准备工作等等（然则，这些其实如果规划的好，应该可以算作这个周期内的目标之一）。但这些都需要服从于当前版本的开发。全力开发我们需要的内容。

因此我们需要避免过度设计，过度开发，以及过度优化。我们需要将效率作为我们开发的准则。

人员

永远只涉及必要的人。为什么我们要进行小组化开发？因为人员牵扯一旦扩大，唯一的结果就是效率降低。各种意见难以统一，管理变得困难，计划难以统筹，任务分配变得困难等等。所以最佳的小组规模应该在7人前后。

仅仅如此么？当然不是，我们不但要确定小组规模并且将小组开发与外界的干扰屏蔽开。我们还要确定我们项目开发的流程中，每一个步骤所要参与的人员，哪些是真正必须的，哪些是不必参加的。确定人员的职责范围，首先他们需要专心于负责的部分，之后才涉及力所能及的部分。

在这里，需要解释的一点就是，敏捷开发并不是所有的决定和步骤都要大家来参与，以增进组员责任心和归属感的。为了最大化效率，我们永远只让必要的人来做必要的事情。比如故事分解为任务，只需要小组成员，和相应的主程主美主策。比如故事本身的优先级划分，只需要核心组成员（更加通常的情况是只有PO）参与即可，小组成员没有必要参与。再来，版本体验会，我们需要的是真正的指导性的意见和重要的人的声音，如果需要专门组织一个会来听小组成员对版本的反馈，我觉得那小组成员平时就不知道是干什么去了。我们需要在组织每一场会议的时候都考虑到，是不是每一个到会议的人都是必须到的，因为我们找他来开会的时间，都本来应该是他开发和工作的时间，而那才是我们的重点。

高效会议

最后，我们需要有一个清醒的认识，过多的会议永远都是高效率的开发的大敌。一个会议10个人，一小时，意味着我们会损失10个人时的工作时间。而实际上一周的工作中，我们一个人时都是损失不起的。当然，这并不是意味着我们不要开会。而是我们需要意识到我们的会议究竟是否有必要，如果有，那么会议效率是否足够？我们是否有足够的会议准备和计划，能够保证我们会议的效率？还有我们是否有相应的会议章程，会议时限？这些都是我们需要考虑的，用以高效化会议，减少时间浪费的重要方法。

所以，当我们思考效率的时候，不妨真的来看看我们现在的开发，分析一下一周的工作中，究竟开发的时间有多少？其他的时间又有多少。看看到底是什么在影响着我们的开发，是否有方法，或者措施，能减弱这些影响。最终进一步加快我们的开发？

开发的脉络

交流

非正式沟通

交流，在敏捷开发中，是永远都谈不够的东西。也是永远会存在问题的地方。在敏捷开发中，我们会重视交流而轻文档。原因？只是因为交流永远比文档更高效。

并非我们就此放弃文档，文档最终会变成记录我们讨论交流结果的工具，便于未来查阅。高效的原因是，在交流的过程中，我们就可以共同修正分歧，修正个人的错误，并且将信息传达给对方。当然，一切都还仅仅是基础的东西。

进一步的是，究竟如何能让我们的交流高效？首先，必须明确一点，会议并非是高效率交流的良好方式。更好的交流，应该更多来自于更频繁的，更多的非正式的沟通。把所有人拉到一起，强迫他们发言，或者收听，并非能很好的传递信息或者进行讨论。而鼓励他们进行自发的讨论、交流、在每天，在所有的闲暇，都可以进行一些思想，一些想法的发散、讨论。这才是最好的情况。

我们当然也可以就此进行推动。更多的不是人为的设置一些刚性讨论需求，而是制造一种推崇各自讨论的氛围。

邮件

其次，是我们交流的方法。我们有没有真正考虑过，哪些内容我们应该放到正规会议上进行宣讲？哪些内容我们只需要发一封邮件，并收集回信的反馈？哪些内容，我们只需要找到相关的人，非正式地谈论一下就可以得到解决？这些分类一旦清晰，能够为我们的团队节约多少时间？

从另一方面来说，有多少内容我们甚至连邮件都没有发出，完全变成了个人的地下行为？在这里，我想强调一下关于邮件的作用，在原来的公司，我们被要求尽量少使用邮件，因为某个时期，员工们甚至把所有需要面谈的内容都用邮件来代替了。距离5米的两个人甚至一周几百封邮件却没有一次谈话。

而在现在的环境中，邮件却变得相对冷落，很多应该有邮件作为记录，或者应该由邮件发出的内容都借由其他的方式或者没有以任何方式发出。比如现在很多的策划文档，每一次更新，只有一定几率会有邮件通知到大家。比如会议纪要，当然这都还是表现的比较好了。再比如不太重要的设计文档，这些都可以借由邮件发送来让需要知道的人了解，并且相比专门的宣讲会，节约很多的时间。大家只需要看完之后，把反馈意见用邮件发回就可以了。所以，我们可以考虑是否完善我们对于邮件的使用？更重要的是，是否我们可以进一步提高我们对于邮件使用的意识？我相信，这会是一个很漫长的过程，但是必然能够极大提高我们办公的效率。

其实终究，还是我们考虑问题的方式，我们是否能够意识到我们现在的交流方面的不足，是否能够开始改进？这将是我们是否能够继续成长的关键。

项目的基石

人

谈到人，其实就是谈到整个流程和过程中最关键的地方，最关键的元素，也是决定一切事情成败的根本。无论多好的制度，流程，如果没有相应的，合格的人来执行，也只会是失败的结局。那么，在敏捷开发中，或者说在游戏业的敏捷开发中，我们需要什么样的人，我们需要什么样的素质和要求，才能更好的运作这个模式，更好的做，并且做出更好的游戏呢？

迭代的意识

首先，是改进的意识。永远记住，没有完美的东西。我们需要保持清醒的认识，认识到我们的项目；我们的流程；我们的文档；我们的游戏等等，都还有可以改进的地方，都还有很多可以改进的地方。改进是没有终点的，我们需要能够找到这些可以改进的地方，我们还需要可以找到改进的方法，并且切实的推行下去。这样，我们才能在一次次迭代中，得到更好的项目，更好的版本，更好的团队，等等。意识到我们有问题，我们才能够改正这些问题。从某种意义上来说，其实这也是迭代的意识。

效率的意识

其次，我们需要效率的意识，我们要明白，最终，我们是在开发商品。我们是在进行商业运作，所以效率是我们需要真正关心的。而效率的重点并不是每天在公司里花了超过8小时，而是我们的时间是否都真正被有效利用起来了。我们是不是真的在需要的时间内，给出了需要的成品。是否这些成品能够合格。每天做的事情是否有意义，是否能够给予我们的工作和项目帮助？我们是否能够抓住我们工作的重点？而不是浪费在无关痛痒的地方。我们需要考虑我们的工作是否是向着目标前进的，是否足够，是否有效率。要做到效率，我们就需要首先明确我们的目标，其次清醒的意识到我们在做的事情，最后再反省是否有无效或者被浪费的地方。是否我们能做的都做了，是否我们把不需要做的也做了？

理解游戏

再次，我们需要有对游戏的把握。毕竟，我们做的是游戏，如果做的人都不知道什么是游戏，那么如何能保证我们做出来的游戏能被人喜爱？甚至，我们如何能保证我们做出来的游戏，是游戏，而不仅仅是一个选择播放的技能地图预览器？所以，首先，我们大家都需要了解游戏，了解什么是游戏，游戏包含了什么；游戏性是什么；核心玩法是什么；主要模式是什么；画面表现是什么；音效是什么；故事是什么，它们是如何结合的，是如何组合成一个游戏的。不同的游戏类型里，这些要素又以什么比例组合，哪一个更加重要。这些都是游戏开发者所需要了解的基本。进而，开发者才能明白，我们现在的游戏已经有了哪些元素，还差哪些元素，已经有的元素是否足够，是否还有所欠缺。这时，合格的游戏开发者们，才有能力说出，我们的开发方向在哪里，应该补充什么元素，有什么欠缺的地方。这样，我们才有能力，做出一个至少完整的游戏。

开发者的野心

进一步，我们如果还有野心，并非只是做一个完整的，良好的游戏，我们还想要有创新，想要做一款让人眼前一亮的游戏。那么我们就不只要了解什么是游戏，我们还需要对游戏有自己的理解和想法，我们需要有自己对这个游戏的未来的想象，并且时常将之拿出来讨论，碰撞，最后留下那些可行的，优秀的方案来实现。我们每个人都需要对我们的游戏有所希望，并且这些希望都是需要时常在我们的大脑里酝酿的。这才是游戏开发最有趣的地方，我们总是可以实现我们脑海中大胆的想法，我们总是可以把我们有趣的意见，点子说出来，如果能够得到大家的赞同，就可以实现到游戏里去。做游戏应该是有趣的，而不是每天重复枯燥无聊的劳动。所以，我们需要思考，并且说出我们的想法。

快乐地制造快乐

用心制造快乐，是不够的，还需快乐地制造快乐。让我们并不仅仅是麻木的工作着，而是真的有趣的去做有趣的事。这才是做游戏的本意，这才是大部分人最早加入游戏公司制作游戏的本意。如果我们做的东西连我们自己都无法说服自己，“那是有趣的。”那做出来的真的能有趣么？我们在做游戏，之后才是工作。如果整个游戏，都没有一点自己的心思在里面，那我们就真的只是在勤劳的上下班了。

而且也只有相互间的思想，想法在碰撞，才会做出有意思的游戏。游戏的设计并不仅仅是策划的事情，游戏的需求也不仅仅是由策划提出。只有大家每个人都可以针对游戏的缺陷，乐趣，玩法能有自己的见解，每天争的面红耳赤，那才是真正做好游戏的取胜之道。在游戏性的讨论上，根本没有策划美术程序之分。

对游戏工业化开发的把握

最后，我们还需要有对游戏开发的把握，对整体的把握。我们是否知道我们现在处于游戏开发的哪个阶段？这个阶段应该重视那些东西？应该注意那些东西？这个阶段我们应该完成那些东西？对于这些我们是否有清醒的认识，清醒的计划？

我们是否有对我们项目的整体规划？知道我们现在要做什么，知道我们下一步还要做什么，这才能让我们明白我们现在做的是否有意义，是否有效率，是否正确。我们的目的，绝对不是过GR1，2,3,4,5.这一点大家应该明白，我们始终都是在做游戏，如果我们的方法正确，计划正确，那么这些评审对我们产生不了任何影响，那么既然我们每次都需要针对这些评审改变我们的流程计划，那么是不是也意味着我们本身的计划也存在一些问题？这个问题大家也许可以思考一下。不要让问题找到我们，而是我们去寻找问题。

故事WHY ME? WHY STORY?

为什么要使用故事？

我们为什么要使用故事？要理解这个问题，首先要理解故事的作用。那么故事的作用是什么？

消除理解误差。

早期软件开发的需求方往往不懂任何技术，开发者的功能清单却往往难以让需求方有直观的对最后成品的认识。比如，或许一个功能描述是，“战斗场景分为5层可以根据摄像机的移动而相对运动”，但对于非专业人士来说，他们可能无法理解这样的描述意味着什么。于是故事开始发挥了它的作用：以一种大家都认可的方式让所有人对我们要做的功能目标有清楚的认识。

所以：

l 只要能够让全体人充分意识到我们功能开发的目标以及内容，那么它就是一个很好的故事。

对我们来说，这样的共识需要在策划，美术，程序等人员之间达成，所以我们的故事也需要以一种大家都能理解的方式来表达。而更重要的，不是故事的方式，而是确实所有人都能够完全理解。具体怎么写，其实真的怎么写方便都可以。

整体统筹估计和管理。

由于故事是从系统和结构的层面，以一定的高度来描述我们整个项目的框架功能，所以我们可以以较快的速度全面了解我们的功能点，而对于这些功能点，我们还可以进一步快速的给出粗略的估算。进而得出整个项目的大概工期或者每个迭代我们可以完成的故事数量。这里的估算往往是由不准确慢慢到准确的。

l 每一个周期，每一个项目的历史数据都可以让我们之后的估计更加精确。

而且这样划分的工作，可以更好的交付给不同的小组完成。小组内部进一步自行组织计划，使得我们的管理工作可以分散到小组，降低管理难度。

创意管理

本质上，游戏就是已有的同类游戏的完整功能点，加上我们独特的创意。完备的前者能让我们的游戏成为一款合格的游戏，而后者的加入则让我们的游戏变得独特。引入故事后，我们可以总是在一个层面，对功能开发和创意尝试的投入进行平衡，相互以取舍。我们可以总是以功能和创意的价值来判断真正对我们有价值的开发顺序。

故事在讲什么？

什么是故事?

首先，故事本质上依然是功能点，依然是从需求中抽取出的一个个系统功能。只是以一种所有人都能理解的形式进行描述。所以，为了能够让所有人能够理解，故事仅仅只从实现功能的目的来描述这个功能：

l 故事是对功能的目的的描述

同时，故事是在讲述这个功能究竟是发挥什么样的作用。所以它本身价值只是简单描述和给予一定参考。

l 它不是，不能也不需要详细的描述这个功能的所有细节和玩家对此的感受。

因为前者有相应的策划文档，后者难以文档化以标准衡量。

所以，当我们要验收某个故事的时候，并不是我们比照着一个个故事，来体验游戏。看一个个故事是否在游戏中完整的实现了。

正确的故事验收，应该是在这个故事在组内达成统一之，所有人就应该知道要做成什么样子之后。将单个功能的验收在周期内

就实时完成。而在最后版本发布之时，对功能进行检验，检测这个功能的最终效果是好还是坏。

我们的目的不只是要看是不是功能A,B,C,D已经完成了，我们应该再深入一步：

l 关注于功能是否得到了很好的效果，符合了我们的预期

l 在游戏开发中，则是，是否有了乐趣

l 是否有其他想法，能够让这个游戏更有趣

因为仅仅是功能的集合，并不能成为合格的游戏。

因此，我们也需要改变我们对于设计目的的定义：

l 我们的目的并非仅仅是完成某个功能，而是功能能否达到我们需要的乐趣。

带着这样的思路，我们才能真正的在版本回顾的时候，给予能够指导我们开发方向的反馈，而非仅仅是针对我们功能开发的完整与否，发表意见。

作为核心组成员，或者，作为整个游戏项目的一员：

l 我们不应该仅仅关心于完成情况，各种细小的错误。我们应该看得更远，思考的更远，给予我们的开发真正能提升最终质量的帮助。

最后，故事包含对它大小的估计，我们可以使用这个估计来对将来的工作和计划进行评估；对它本身价值的估计，让我们在选择他们时可以参考。简单的来说，就是另一些附加的功能。

用好你的武器

如何使用故事

故事的来源

第一，从已有的游戏设计文档或者框架中抽取的，比如，我们已经知道我们要做的是一个回合制战斗的游戏，那么我们就可以抽取出，基础战斗指令，回合制战斗流程之类的故事。

第二，新出现的创意性质的内容，比如，今天我突然想到在回合制战斗中加入行动顺序条或许是个很有趣的点子，我告诉大家，大家也觉得这个东西很好，于是我把它加入到清单中。

第三，当我玩到某个游戏的版本的时候，发现，某个功能给我的反馈不是很好，或者我觉得可以如何改进，能够让这功能变得更好，那么也可以放进到故事清单中。

故事的使用

首先，我们有一个用来维护故事的列表，术语叫做产品订单，里面罗列了所有我们已经完成或者没有完成，重要的或者不重要的故事。我们可以在里面清楚的看到：

l 故事的描述

l 故事点（大小）

l 优先级（价值）

l 当前状态

于是，在每个迭代开始的时候，我们都将故事从大到小排列起来，依据上个版本我们能完成的故事量（以故事点来衡量）来选取我们这个版本需要完成的故事内容。

故事选取完成后，下一步，则是让整个小组对故事的内容达成统一。也可能只是统一目标，而某些细节在完成的过程中确定。这过程的形式，依然并不固定。

当大家对故事的内容都有所了解之后，我们可以开始对故事进行分解。得到相应的详细的任务。任务又成了计划，在对计划进行评估和检验之后，每个周期的工作内容就如此确定。

故事的作用就基本到此结束，剩下的内容是当单个故事完成的时候，对版本中功能进行体验，如果通过，则这个故事就此完成，最后进行归档之类的收尾工作。

当然，在故事的具体使用中还有一些细微操作，比如如果一个故事在一个周期中制作时发现比估计的大很多要放到两个周期来做才能完成。那么我们还需要对故事进行拆分之类的操作。这些细微操作还是需要在针对不同的情况进行不同的处理。

版本体验会

当我们一个周期的开发内容完成，每个版本功能都已经在周期内得到了验证，并且已经有了一定的优化。为什么我们还要有一个版本体验会呢？

首先，我们每个人负责的领域不同，我们有的人对于美术质量很关注，有的人对于代码质量很关注，有的人对于设计文档很关注。也许我们中的一些人参与了一些功能的开发，但是我们并不能对于这个周期的所有功能，所有的改动有所了解。就算对此有所了解，我们也许也不明白每一个功能的设计用意。最后，为了让所有人对最终结果达成统一的认识，我们需要一个正式的展示会议，向核心组或者高层进行我们这个阶段的成果展示。在展示我们的版本新增功能和内容的同时，核心组也会对这个版本的各个细节和内容进行考察和审核，确定这样的改变是否符合对于游戏性和乐趣的追求，是否符合我们对我们游戏的希望，这样的发展方向是否是正确的。

而在这样的会议中，最重要的是，我们需要得到来自各个方面的反馈。作为开发者，这可能本身就局限了我们对于我们的版本的认知和看法。我们对于我们的版本过于熟悉，有可能自动的忽略掉了一些很重要的问题，或者会错误的认为一些难以被接受的游戏性具有很大的乐趣。而这样的会议，则是指正我们类似问题的恰当时机。针对这些反馈，我们可以更好的修正我们的工作思路和计划。给予我们下一个阶段更好的目标。

所以，在这里，核心组需要给出的，更多，更重要的，还是对于我们游戏的方向性的，涉及到我们目前开发功能的游戏性和表现上的改进意见或者反馈和一些指导性的意见。因此，我们需要要求我们核心组本身更了解游戏，更明白游戏性，并且自己对于我们要开发什么样的游戏，有清醒的认识和思考。

周期总结会

自适应，自我优化的流程，需要有两个要素才能真正的进行自我改进。首先最重要的是其中的人要有对流程中的问题，需要优化的地方，甚至是对优化本身有清醒的认识和意愿。其次，就是这样的人推动的一个优化行动。而周期总结会，就是SCRUM中设立的一种针对流程自身优化而进行的一种行为。

项目总结是游戏业的一个普遍工作习惯，在每一个游戏项目结束的时候，会进行一次全项目级别的总结会议，对于整个项目过程当中，做的好，有典范价值的事物，或者在过程当中发生的有范例价值的问题，甚至是还没有解决的问题进行系统的总结和提炼。之后将之发表，可以成为团队，甚至其他团队将来工作时的依据和帮助。

而每一个周期一次的周期总结，则是将这一行为加快，频率加高，在项目进行中不断反复。以此达到更快速的寻找总结目前我们的优缺点，针对我们目前的缺点问题寻找解决的办法，并且开始行动。总的来说，就是以更快的频率不只是迭代我们的版本，将我们的版本改进的更好。同时也是迭代我们的行为，优化和让我们自己更加的进步。

其实设立一个这样的会议并不难，每一个周期我们都会有这样的总结会。而会议也总会有这样那样的缺陷和需要优化修改的结果。难的是我们需要切实的推行那些问题的修正措施，难的是我们需要能够直面我们的不足，并且将其提出。我们要能对或许难以开口的问题更直白。鲁迅先生有云，真正的猛士，敢于直面惨淡的死生。我们必须承认我们的工作都是不完善的，都是需要优化的。但是这些问题都不是阻止我们开始修正和改革的借口。敏捷开发的意义也就在于，知道一开始的我们不足以成功，甚至肯定会出现问题，会有失误。但是正是在一次次快速迭代中，我们快速的磨合，快速的修正，最后在一次次的改正与进步中，我们才会得到一个完善的团队，一个良好的流程以及一系列适合我们的方法。

这也才是周期开发的意义所在。所以，敏捷开发，并不是一个需要在一开始就有完全的准备的过程，并不是一个需要完整规划，好好考虑的过程。我们只需要有一定的东西可以开个头，哪怕还不算成熟，但是我们依然可以在接下来的过程中，对我们的目标愈发的清醒，越发的明确，并且我们本身也会越发的成熟，最终共同达到目标。

一开始，游戏功能不明确？没问题，我们可以先从知道一定会做的开始做，然后开始探讨我们最后要做的目标，再根据每一个迭代的版本反馈修正我们的目标。

一开始，我们开发团队磨合不够？没问题，我们可以先让他们从开发简单的底层功能做起，并且同时进行磨合，将磨合过程中需要解决的问题一一提出并改正，最终优化得到一个完善的团队。

一开始，我们的工具不够？没问题，我们可以先用最快的方式开发原型，同时分析原型制作的方式和需求，进行工具制作。并且在工具可以使用之后，再根据使用者的反馈和项目的进展进一步的优化和改进。

… …

我们可以做的东西很多，而那些还没有做的，也同样不能成为我们开始做的障碍。

原文地址：http://djt.open.qq.com/portal.php?mod=view&aid=115

或许这些文章您也喜欢：

苹果产品开发的绝密工作流程

李谭伟 — Wed, 01 Feb 2012 06:14:13 +0000

长期以来苹果产品开发流程在很多方面都笼罩着一层神秘的面纱，而在Adam Lashinsky新发行的《Inside Apple: How America’s Most Admired–and Secretive–Company Really Works》一书中对这些流程有所涉及。这本书同时谈论了苹果公司各个不同的方面，包括其理念、招聘流程以及传说中的秘密等等。

苹果始终坚持同一产品开发流程，这也是其多年魅力不减的原因所在。在接下来的这些要点中，有些可能是我们已在其它地方见过的，而有些却是新的。以下为任何苹果产品在开发时都需遵从的框架：

设计驱动产品

在苹果，设计师就是上帝，所有的产品都需符合他们的要求。这一点可能在其他公司恰好相反。与其他公司中设计依附于生产部门不同的是，财务和生产部门都要满足以Jony Ive为首的设计部门的要求。

苹果的设计师就单纯的只管设计，无需与财务部门打交道或考虑成本问题，也不用考虑设计所使用材料在生产时怎样使用。苹果所有产品都孕育自工业设计工作室。它们在那里诞生时，仅有包括Jonathan Ive在内的少数苹果员工能接触到。

构建公司内部的“start-up”

在新产品得到确认后，整个团队的成员都会被组织起来签订保密协议，有时甚至可能从物理上进行隔离。为了给负责这个敏感新项目的团队腾出空间，部分办公区域会被封锁或警戒。这就在公司内部有效的建立起一个仅由执行团队负责的“start-up”，并使其从整个公司的组织结构中独立出来。

执行苹果新产品进程（ANPP，Apple New Product Process）

一旦开始产品设计，ANPP便进入执行阶段。这是一个详细描述新产品开发进程中每一步的执行文档。虽不是独创的苹果理念，但首次应用到企业却是在苹果进行Macintosh开发时。它详细筹划了开发的各个阶段，例如，谁负责完成；各自在每个阶段负责什么内容，以及在什么时候完成等。

每周一次产品评估

公司高层会在每周一仔细检查进入开发流程的每个产品。因为苹果在任何时候都只有少数产品在生产，所以这是可以做到的。不会让任何一个评估延后到下次。这意味着产品的关键性决定没有一个会在超过两周的时间内做出。

EPM绝对控制生产

在产品生产时，需要一个工程项目经理（EPM，Engineering Program Manager）和一个全球采购经理（GSM，Global Supply Manager）负责管理，直至完成。前者在产品生产过程中拥有绝对的控制权。因其权力很大，所以也被称为“EPM黑帮”。这两个职位一般都由公司高层担任，且其大部分时间都是在监督中国工厂的生产流程。采购经理和项目经理会相互合作，也会经常因决择“什么最适合产品”，而备感压力。

反复设计、生产和测试

事实证明，在苹果制作好产品原型后，将再次进行设计，然后再将其投入生产。这也解释了为什么有时在我们看到一些泄漏版本的产品后，却始终不见其发布。而这个过程大概会持续4-6周。

EPM会带着测试版设备返回总部接受测试和评估，然后再返回工厂监督下一个产品。这意味着很多版本的产品实际都已经“完成”，只不过是部分的原型。这是一种极其昂贵的新产品开发方式，但在苹果这就是标准模式。

独立的包装设计区域

在营销大楼里还有一片完全专注于设备包装设计的区域，其安全性与专注新产品和设计的专用区域相当。在某新款iPod发布前的一段时间，曾经有一员工在数月里每天花费数小时打开了数百个包装原型，以此提炼打开包装这一过程的用户体验。

绝密的产品发布计划

产品发布行动计划被称作“the Rules of the Road”。这是一个高度机密的文档，上面列出了产品从开发到最终发布过程中所有的重大阶段目标，且每一个阶段目标都注释有主管该目标达成的直接负责人（DRI，Directly Responsible Individual）。丢失或泄漏这个文件的人将被立即解雇。

如你所见，苹果为了追求产品的卓越，经常会做一些增加成本和降低效率的决定。也有许多公司做事太过复杂，或过于墨守成规，并试图把苹果的流程完全照搬。尽管如此，苹果的责任制方案仍可简单地归纳为：致力于好的产品才是第一位。当然这也是造就苹果十余年财富神话的原因。

上述产品开发流程仅是Lashinsky书中的部分，想了解更多的话可以考虑仔细阅读一下这本书。

Via TNW

或许这些文章您也喜欢：

godaddy抢注域名流程

李谭伟 — Sat, 14 Jan 2012 14:31:22 +0000

前天我在GoDaddy提交了一个域名抢注，具体域名我就不透露了，这里主要讨论一下最新的GoDaddy域名抢注提交过程。我的英语不太好，不过看看GoDaddy.com上的问题不大，所以我是边操作边载图的，应该说会写得很详细，让从来没有接触过的人也能看懂操作。

先简单介绍一下国内外的域名抢注商。国外三大最厉害最有名的抢注商是www.pool.com、www.namejet.com和www.snapname.com。有价值的基本被他们消灭，当然价也格不低，最低的起步价也要59美元，而且都要信用卡注册支付。接下来就是比较实惠的两家godaddy.com和name.com，价格都是20美元左右，虽然比不上上面三大抢注商，但传说经常也会有意外之喜。如果不是特别重要特别在乎的域名，我推荐用Godaddy。再说说国内的，主要是金米网（jinmi.com）和拍米网（paimi.com）。如果你在国内抢注商抢注，成功率一般低于国外的。

下面详细介绍一下GoDaddy抢注域名的方法。

一、注册GoDaddy。这一步不多介绍了，就像平常在网站注册会员一样，应该没什么问题。

二、抢注域名。注册后登陆用户，然后点主菜单“Domains”下面的“Domain Backordering”，

看到左边的“Domain Backorders $20.99 /each”，Select Quantity即选择数量，我就只抢注一个域名，所以写上1，Backorder type是两种：Public Registration和 Private Registration。前者是会公开你的域名抢注信息，后者是帮你保密的，当然后者是要加钱的。

然后点“ADD TO CART”，接下来有两个页面都是Godaddy向你推销的另外的产品，我们只是要抢注域名，所以你只要点两次“No Thanks”就OK了。

这里看到右边“Order Summary”，下面可以输入Godaddy的优惠码，这里我提供两个吧！gdbbe994优惠30%，前天亲测可用！gdz183q这个是早上刚收到的，优惠27%，大家自己试吧。看到图片没有？原本20.99美元，现在只要14.69美元，乘以6.3折合人民币93块多，这其中已经包含了一年的域名注册费，很便宜吧！

接下来的就是付钱了。付款方式有很多，Godaddy支持支付宝，我当然选它了，国产的嘛！简单方便呵呵～

点“PLACE ORDER NOW”就跳到支付宝的页面了，接下来的不用我多说了吧？太熟悉不过了。

付好之后，回过来，回到Domain Management。

点击“Buy/Sell”下面的“Backorders and Monitoring”:

点击右侧的“Add Backorders”，然后

下面填写关于你抢注域名的一些信息：

OK，到这里就结束了。

看到“Status”一栏为“Public Backorder Active”就说明已经成功提交了，接下来就是等待，看最后是否能成功抢注到我们所需的域名。

或许这些文章您也喜欢：

删除域名抢注实战 (12)

删除域名抢注实战(12)

5款备受关注的开源 NoSQL 数据库介绍

李谭伟 — Fri, 13 Jan 2012 03:04:21 +0000

随着社会化网站的兴起，传统的关系数据库在应付这类网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL(NoSQL = Not Only SQL )，意即反SQL运动，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于目前铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。

以下是我关注得相对比较多的nosql数据库，希望可以给从事数据库和运维的朋友们带来一些帮助。

1. 集中式缓存系统 memcached

memcached是一套分布式的快取系统，当初是Danga Interactive为了LiveJournal所发展的，但目前被许多软件（如MediaWiki）所使用。这是一套开放源代码软件，以BSD license授权释出。

memcached缺乏认证以及安全管制，这代表应该将memcached服务器放置在防火墙后。
memcached的API使用三十二位元的循环冗余校验（CRC-32）计算键值后，将资料分散在不同的机器上。当表格满了以后，接下来新增的资料会以LRU机制替换掉。由于memcached通常只是当作快取系统使用，所以使用memcached的应用程式在写回较慢的系统时（像是后端的数据库）需要额外的程式码更新memcached内的资料。
memcached具有多种语言的客户端开发包，包括：Perl/PHP/JAVA/C/Python/Ruby/C#/MySQL/

2. 分布式K/V存储方案 Cassandra

Apache Cassandra是一套开源分布式Key-Value存储系统。它最初由Facebook开发，用于储存特别大的数据。Facebook目前在使用此系统。
主要特性：
分布式
基于column的结构化
高伸展性

3. 开源NoSQL系统 Membase

Membase 是 NoSQL 家族的一个新的重量级的成员。

Membase是开源项目，源代码采用了Apache2.0的使用许可。该项目托管在GitHub.Source tarballs上，目前可以下载beta版本的Linux二进制包。该产品主要是由North Scale的memcached核心团队成员开发完成，其中还包括Zynga和NHN这两个主要贡献者的工程师，这两个组织都是很大的在线游戏和社区网络空间的供应商。

Membase容易安装、操作，可以从单节点方便的扩展到集群，而且为memcached（有线协议的兼容性）实现了即插即用功能，在应用方面为开发者和经营者提供了一个比较低的门槛。做为缓存解决方案，Memcached已经在不同类型的领域（特别是大容量的Web应用）有了广泛的使用，其中 Memcached的部分基础代码被直接应用到了Membase服务器的前端。

4. 超高性能 key-value 数据库 Redis

Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类keyvalue存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了Python，Ruby，Erlang，PHP客户端，使用很方便。

性能测试结果：
SET操作每秒钟 110000 次，GET操作每秒钟 81000 次，服务器配置如下：
Linux 2.6, Xeon X3320 2.5Ghz.
stackoverflow 网站使用 Redis 做为缓存服务器。

5. 面向文档的数据库 CouchDB

Apache CouchDB 是一个面向文档的数据库管理系统。它提供以 JSON 作为数据格式的 REST 接口来对其进行操作，并可以通过视图来操纵文档的组织和呈现。 CouchDB 是 Apache 基金会的顶级开源项目。

CouchDB落实到最底层的数据结构就是两类B+Tree 。

或许这些文章您也喜欢：

百万级访问网站前期的技术准备（中） (9)

百万级访问网站前期的技术准备（中）(9)

12306网上订火车票攻略：实用脚本实现半自动化

李谭伟 — Tue, 10 Jan 2012 02:38:08 +0000

12306.cn 可以网上购火车票了，但由于我镇的『国情』决定了春节时分它竟然比电话购票都不靠谱。但是，毕竟它是最方便的，所以在意识到其实这不仅是个技术活、更是一个体力活之后，终于决定博彩众家之长搞这么一个一条龙的轮子……现在放出来也许有点晚了，但是对于赶年前一两天以及回程票的同学还是有点用的，所以还是放出来吧

半原创，借鉴了不少别人的思想和思路，但代码基本上都是重写的。目前实现的功能有：

记录登录的用户名和密码，在打开登录页面后自动填写；

运行需求

您必须准备以下条件之一：

Firefox，最好比较新的版本（6+），并安装 Scriptish 扩展；
Chrome（4以上版本）

注意，如果您以前有安装过类似的脚本（如自动登录、自动查询等等），请先移除它们。

Firefox下的功能介绍

在登录页面，本脚本会加入密码记录功能和自动登录功能：

记录密码后，下次登录直接就会填入，并自动定位到验证码段。需要提醒的是，密码是明文记录在Cookies中的，所以如果不是你自己的电脑，建议不要记录。

填完后，你可以用传统方式登录。不过现在不是有了自动登录了吗？点击自动登录呗。在没有成功登录的情况下，系统会自动反复重试，重试的时候桌面右下角会有弹窗提示正在进行的操作：

登录成功后，也会有提示，并且页面会自动进入查询页面：

进入查询页面后，在查询下面有加一条选项，选项意思简单明了，不需要解释的吧

当没有查询到符合要求的车次时，会自动重试。由于系统按钮有5秒钟的限制，所以不允许设置在6秒内重试。

（上图木有查到，是因为过滤了“仅卧铺”）。

如果查到了，会停止刷新，高亮行，并在桌面右下角弹出提示：

Chrome下的功能介绍

在Chrome下的功能基本上是一致的，以下不再做详细描述。

不过Chrome的桌面提示是需要授权的，所以有提示的界面上会有按钮提示：

“请点击以启用通告”，点击后在浏览器上方点击“允许”，否则通告无法使用。

登录过程的界面提示，内容基本一致，不过就是换个样子：

登录成功后会一样进入：

呃，查询界面一样经典呐：

查询成功时会有声音提示（可以选择开启或关闭），并弹出提示：

小贴士请注意喔：

Chrome下的桌面提示仅在浏览器正常模式下才起效（也就是说你要是把浏览器最小化了，提示看不到的），不知道是不是Chrome都是这样，但我测试的结果是这样……所以一定要注意声音啊
Firefox下的桌面提示是可以在桌面上弹出来的。我这里用的是Scriptish，没有测试GreaseMonkey的兼容性……木有时间啊
很多人说又要用IE去付款，还不是要反复登录的体力活吗？建议用银联在线支付，关联银行卡后用手机即可在Firefox或Chrome下直接付款（值得注意的是，Firefox6以上的版本它的安全控件暂时不支持，可以用我制作的安全控件补丁，点击下载）。

感谢前人：

12306 Auto Query ，Jingqin Lynn
12306 Booking Assistant，Hidden
12306 Auto Login，Kevintop

下载

请选择您需要的版本（根据您的浏览器选择）：

Chrome：http://www.u-tide.com/fish/Service.asmx/Download/44/45/12306_ticket_helper_for_chrome.user.js
Firefox：http://www.u-tide.com/fish/Service.asmx/Download/44/46/12306_ticket_helper_for_firefox.user.js

点击链接后在提示中点击安装或继续即可。

自动登录，遇到人过多或繁忙的时候自动重试，直到登录成功（有点儿抢线的味道）；
自动记录查询信息，一次查询线路后下次再查询自动填入；
自动刷新查询，当没有需要的车次时，自动重新刷新；
支持 Firefox + Scriptish 或 Chrome。
在 Chrome下，查票和登录有右下角提示和声音提示；Firefox下暂不支持声音提示，但有桌面弹窗提示。

随机推荐阅读：

博客搬家到新浪SAE服务器，暂时使用二级域名访问

李谭伟 — Thu, 25 Aug 2011 14:26:47 +0000

博客搬家啦！！

搬到了新浪云计算平台SAE的服务器里面，访问速度有了非常大的改善，同时也会非常的稳定了哦！

由于我的顶级域名没有通过万恶的备案，现在还不能使用顶级国际域名访问，所以大家看到的是sinaapp的二级域名。目前备案已经在办理中，预计一周后就可以使用。备案成功后访问就恢复正常了。

给您带来不便，请您谅解！

李谭伟

2011 08 25

随机推荐阅读：

与技术无关：下棋感悟

李谭伟 — Fri, 15 Apr 2011 01:11:36 +0000

闲暇周末，独自在家，在网上下了几局棋，颇有感悟，想写下来和朋友们一起分享共勉！

先说说棋局：我自认为布局是非常不错的，但是进入中局的时候，一步一步的被攻破，被吃去很多棋子。一直到接近结束的时候知道输已经是定局了，最后均以失败告终！

人说人情如纸张张薄，事事如棋局局新。真是这个道理，至少今天说明了“事事如棋局局新”的道理。这几局棋让我想到了很多事情，我自己遇到的，朋友遇到的。就说说人对自己的打算吧，看看和这棋局是多么雷同！

很多人从小都被人夸很聪明，很漂亮，是个人才，同时从小的确也学习很好，甚至也考上了好的大学。这可以算是布局。

但是大学毕业面对和很多的现实，有就业的压力，人和人的竞争，开始接触社会，面对欺骗、尔虞我诈、等等，自己从小的梦想，从小的抱负，大家夸赞的好儿童、人才在现实的冲击下，慢慢的失去了斗志、也失去了很多优势（或者说别人更有优势！）。这可以算是进入中局。

很多人在中局的洗刷下，败下阵来。当然也有感觉凯旋而归的。

有的人通过面对的这些情况知道了自己在哪些方面不足，虽然败了，但是却收获不少，为了东山再起，在此收拾河山，继续前行！但是有的人却一蹶不振，有的对整个社会充满了怨恨、埋怨我们国家政策不好、埋怨改革开放太乱、有的还埋怨中美货币差导致了物价上涨，不能生活等等云云。。。这就是漫长的中局中很多表现对吧！

结果一阵厮杀，棋确实已成定局了。很多人知道胜券在握了，有的人知道已经无力回天了.慢慢真的“已知天命”！这是向残局过度的阶段吧！

棋局进入到了尾声，有的自动放弃的（认输），有知道已经不可能胜利但是也不可能失败，然后将就过日子的（和棋）。也有经过不断的努力还在继续奋斗，还不知道天命的！其后者一直奋斗，到最后棋局结束.这是残局吧！

象棋真的好像上天赐予我一个检验我心理状态的仪器一样，在不同的时间，不同的情况，我下一局棋。让我悟出很多人生道理。棋子只有这么几颗，谁的棋子从一开始都是一样多的。是好是坏，就看自己怎么把握。有一着不慎满盘皆输的，也有力挽狂澜杀出一条血路最后反败为胜的！一切的一切，需要自己不断总结、学习、思考。

人生如棋、事事如棋，布局并不重要，重要是怎么好好把握。中局失利并不重要，重要的是怎么痛定思痛、组织兵马从头再来然后力挽狂澜。只要中局做好了，残局输了又怎么样？人生是何等精彩！棋有输赢、但是人生却没有，只有是否精彩。

谨此短文与兄弟姐妹们共勉！愿我们都走一盘精彩的棋！

随机推荐阅读：

百万级访问网站前期的技术准备（中）

李谭伟 — Fri, 07 Jan 2011 09:28:57 +0000

七、数据库

几乎所有操作最后都要落到数据库身上，它又最难扩展（存储也挺难）。对于mysql，什么样的表用myisam，什么样的表用innodb，在开发之前要确定。复制策略、分片策略，也要确定。表引擎方面，一般，更新不多、不需要事务的表可以用myisam，需要行锁定、事务支持的，用innodb。myisam的锁表不一定是性能低下的根源，innodb也不一定全是行锁，具体细节要多看相关的文档，熟悉了引擎特性才能用的更好。现代WEB应用越来越复杂了，我们设计表结构时常常设计很多冗余，虽然不符合传统范式，但为了速度考虑还是值得的，要求高的情况下甚至要杜绝联合查询。编程时得多注意数据一致性。

复制策略方面，多主多从结构也最好一开始就设计好，代码直接按照多主多从来编写，用一些小技巧来避免复制延时问题，并且还要解决多数据库数据是否一致，可以自己写或者找现成的运维工具。

分片策略。总会有那么几个表数据量超大，这时分片必不可免。分片有很多策略，从简单的分区到根据热度自动调整，依照具体业务选择一个适合自己的。避免自增ID作为主键，不利于分片。

用存储过程是比较难扩展的，这种情形多发生于传统C/S，特别是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务的模式，是机海作战。方便水平扩展比那点预分析时间和网络传输流量要重要的多的多。

NoSQL。这只是一个概念。实际应用中，网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等，这都不是传统关系数据库所擅长的，于是就产生了很多非关系型数据库，比如Redis/TC&TT/MongoDB/Memcachedb等，在测试中，这些几乎都达到了每秒至少一万次的写操作，内存型的甚至5万以上。例如MongoDB，几句配置就可以组建一个复制+自动分片+failover的环境，文档化的存储也简化了传统设计库结构再开发的模式。很多业务是可以用这类数据库来替代mysql的。

八、缓存。

数据库很脆弱，一定要有缓存在前面挡着，其实我们优化速度，几乎就是优化缓存，能用缓存的地方，就不要再跑到后端数据库那折腾。缓存有持久化缓存、内存缓存，生成静态页面是最容易理解的持久化缓存了，还有很多比如varnish的分块缓存、前面提到的memcachedb等，内存缓存，memcached首当其冲。缓存更新可用被动更新和主动更新。被动更新的好处是设计简单，缓存空了就自动去数据库取数据再把缓存填上，但容易引发雪崩效应，一旦缓存大面积失效，数据库的压力直线上升很可能挂掉。主动缓存可避免这点但是可能引发程序取不到数据的问题。这两者之间如何配合，程序设计要多动脑筋。

九、队列。

用户一个操作很可能引发一系列资源和功能的调动，这些调动如果同时发生，压力无法控制，用户体验也不好，可以把这样一些操作放入队列，由另几个模块去异步执行，例如发送邮件，发送手机短信。开源队列服务器很多，性能要求不高用数据库当做队列也可以，只要保证程序读写队列的接口不变，底层队列服务可随时更换就可以，类似Zend Framework里的Zend_Queue类，java.util.Queue接口等。

十、文件存储。

除了结构化数据，我们经常要存放其他的数据，像图片之类的。这类数据数量繁多、访问量大。典型的就是图片，从用户头像到用户上传的照片，还要生成不同的缩略图尺寸。存储的分布几乎跟数据库扩展一样艰难。不使用专业存储的情况下，基本都是靠自己的NAS。这就涉及到结构。拿图片存储举例，图片是非常容易产生热点的，有些图片上传后就不再有人看，有些可能每天被访问数十万次，而且大量小文件的异步备份也很耗费时间。

为了将来图片走cdn做准备，一开始最好就将图片的域名分开，且不用主域名。很多网站都将cookie设置到了.domain.ltd，如果图片也在这个域名下，很可能因为cookie而造成缓存失效，并且占多余流量，还可能因为浏览器并发线程限制造成访问缓慢。

如果用普通的文件系统存储图片，有一个简单的方法。计算文件的hash值，比如md5，以结果第一位作为第一级目录，这样第一级有16个目录。从0到F，可以把这个字母作为域名，0.yourimg.com到f.yourimg.com（客户端dns压力会增大），还可以扩展到最多16个NAS集群上。第二级可用年月例如，201011，第三级用日，第四级可选，根据上传量，比如am/pm，甚至小时。最终的目录结构可能会是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync备份时可以用脚本只同步某年某日某时的文件，避免计算大量文件带来的开销。当然最好是能用专门的分布式文件系统或更专业点的存储解决方案。

下面，我们要谈谈代码了。

来源：一路凯歌（http://zhiyi.us/）
原文地址：http://zhiyi.us/internet/thinking-twice-before-building-your-site-one.html

或许这些文章您也喜欢：

5款备受关注的开源 NoSQL 数据库介绍 (0)

5款备受关注的开源 NoSQL 数据库介绍(0)

念宏的胡言乱语

Facebook股权结构设计

或许这些文章您也喜欢：

Related Posts

Recent Comments

Android 4.0设计规范（附全文翻译pdf）

随机推荐阅读：

Related Posts

Recent Comments

敏捷开发思想谈

或许这些文章您也喜欢：

Related Posts

Recent Comments

苹果产品开发的绝密工作流程

设计驱动产品

构建公司内部的“start-up”

执行苹果新产品进程（ANPP，Apple New Product Process）

每周一次产品评估

EPM绝对控制生产

反复设计、生产和测试

独立的包装设计区域

绝密的产品发布计划

或许这些文章您也喜欢：

Related Posts

Recent Comments

godaddy抢注域名流程

或许这些文章您也喜欢：

Related Posts

Recent Comments

5款备受关注的开源 NoSQL 数据库介绍

或许这些文章您也喜欢：

Related Posts

Recent Comments

12306网上订火车票攻略：实用脚本实现半自动化

随机推荐阅读：

Related Posts

Recent Comments

博客搬家到新浪SAE服务器，暂时使用二级域名访问

随机推荐阅读：

Related Posts

Recent Comments

与技术无关：下棋感悟

随机推荐阅读：

Related Posts

Recent Comments

百万级访问网站前期的技术准备（中）

七、数据库

八、缓存。

九、队列。

十、文件存储。

或许这些文章您也喜欢：

Related Posts

Recent Comments