2014.03 (译) 不要说谎 (Don't lie.)

Views

按:本文是两年半前翻译的一篇文章,译于[2011-11-05](修订于[2014-03-22]),原文发表于[2011-10-04],出自 DEADC0DE 的 blog(需翻墙),原文在这里(需翻墙)

现在我仍记得,初读此文时,脑海中反复回响着的林锐博士的一句话:“做一个真实,正直,优秀的科技人员。”

在漫长的职业生涯中,一个程序员会不断面临各种主观和客观的压力,前者比如视野,品味,学习能力和天然惰性,后者比如项目进度,主管偏好等等。能不能在面临这些实实在在的压力时,仍有一丝不苟的操守,认真对待自己写下的每一行代码,这对于有追求的程序员几乎总是一个艰难的选择。我相信,凡是热爱编程的程序员,都曾有过这个体验——必要的时候,哪怕小到给一个临时变量命名,却还反复斟酌,直至茶饭不思,甚至于“吟安一个字,捻断数根须”。是的,不是每个程序员都能成为卡马克,但并不妨碍他为这个世界增加一段 真正 有用的代码。

不要说谎(Don’t lie.)

代码的签入并不意味着任务的完成。

对产品而言,“完成”是指:

  • 签入
  • 足够稳定(通过自动化测试)
  • 符合指标(内存和性能符合要求)
  • 可用性(配套工具和参数的提供)
  • 已通过验证(相关的美术,策划和你的程序主管)

如果忽略掉后面的四条,想发布产品就是痴人说梦了。必然的,你会被没完没了的加班带来的压力逼疯,最终发布一个始终达不到质量标准的次品。 这也意味着在开发产品的时候,我们总是从一个稳定的,可靠的,符合性能指标的原型出发,并在整个开发过程中不断地(通过测试等手段)去保证它始终不被打破。 没错,照这样来,会让你会花双倍的时间完成同一个任务。有时候,为了“真正地”完成某个任务,你甚至必须花时间去调整各个相关的子系统,另外腾出地方来把它塞进去。

当然,逃避所有这些很简单——说谎。

游戏行业是个充满创造力的行业。身处这个行业中,由于时常面对各种变化,我们很少循规蹈矩地事先做好所有的计划。 通常我们在开发一个产品时,没法制定一个确切的时间表。更常见的是,手里有个原型(demo)我们就抄起家伙兴冲冲地开始干了。

想象一个团队一同画一副画的情境。如果一个人画手指,一个画眼睛,还有个在画鼻子,你就不该抱着侥幸心理,指望这些东东能正正好好拼到一起。让他们全部在一个指定的日期前完工就更难了。要是少个耳朵怎么办?项目发布前让所有人一起加班到深夜画这只耳朵?

好吧,傻子才这么干。可事实上很多游戏公司都是这么干的。他们不明白各种因素是相互作用的。任何改动都不是局部的,静态的。 整个系统是有机的,每个改动都要贴合它对应的上下文情境 。在画布上,你画上去的每一笔都要有个明确的意义。

在绘画的时候,你总是从一个草图开始,慢慢加工成一件艺术品,自始至终,不管完成了多少,它都是一副(概念上)完整的画,不是堆在一起的一堆不相干的零件。在这个过程中的任何时候你停下来,它都是一幅画,也许不够精细,细节也不够多,但它是完整的一幅画。

游戏也是一样,只消看它能不能正常运行。如果它时常宕机或者吃光内存(亦或性能达不到指标),就算不上是游戏,只是一堆冒着烟的二进制文件。

项目开发中的历次迭代(在任何时候)都不应打破产品的质量标准。

自始至终,它都应能够顺利运行。

补记: 有同学可能会觉得这位老兄不太现实。坦率地讲,我也很清楚,要是按这标准去衡量的话,国内的团队基本都得歇菜。就一条吧,敢问哪个团队能做到,在研发过程中,产品的关键性能指标始终能维持在“可对外”的水准?我承认,在如今游戏行业的土壤里,这种做法的确缺乏可操作性和可推广性,可这并不代表这种理念本身是错的。如果阅读这篇文章能让你思考自己所在团队的开发模式,利弊得失,进而萌生改进的意愿和思路,那我翻译这篇文章的目的就达到了。

附原文:

Don’t lie.

c0de517e|DEADC0DE

A task is not done when its code gets checked-in. In production, “done” is:

  • Checked-In
  • Stable (passes automated tests)
  • In-budget (memory and performance)
  • Usable (tools, parameters)
  • Verified (art-directior or designer or lead programmer)

If you ignore the last four, you’re living in a dream. A dream in which you will ship the game. Instead, you’ll die under the pressure of crunch time and ship a flawed product that does not match the quality standards it should.

That also means that in production we start with a stable, in-budget product. And that we do have means of verifying that this is true for the entire production (tests).

Yes, it will take twice as much time to finish a task. Yes, it will mean that some tasks can’t be declared done until you make more space somewhere else, to fit them in.

Of course you can avoid all this. All it takes, is to lie.

We are a creative industry. We have to deal with change, we don’t plan things up ahead and then waterfall until they are all done (not most of the times at least, there are situations in which that applies).

We don’t craft a product by following a plan, we make drawings and sketches (prototypes) and then take a canvas and start painting. You don’t have a person detailing a finger, another one refining an eye, another working on the nose and then hope that everything will stick together just right. Or hope that you will have all the parts done by a given date! And what if it then misses one of the ears? What do you do, take ten artists working on that ear till midnight every day near the deadline?

Only an idiot would do that, and still many game companies work like that, they don’t consider that everything has to fit just right, and that change is not local, every change has to fit with the entire context, every brush stroke has to make a sense in the entire painting. You start with a painting, a rough one, and then refine it, and at all time the painting is a painting, it’s not a collection of unrelated pieces. You can stop at any moment and it will be still a painting, maybe not that refined, maybe not as intricate and detailed as you wanted, but it’s a painting.

A game is such only if it runs. If it crashes or goes out of memory on the target platform, it’s not a game, it’s some binary that crashes. If it does not hold its performance, it’s not a game, we can’t burn it to a disc and call it a game, it won’t be shipped, it won’t pass certification. Iteration should not break this quality, it should go from a “shippable” game to a “shippable” game. Especially during production.

(全文完)


comments powered by Disqus
Built with Hugo