编程时间分配图
- Greyby - 酷壳 - CoolShell.cn下面是一个程序员coding的时间分配图,原图在这里. 思考会是一个很重要的过程,当然耽搁拖沓也有可能也是因为没有想好,抽烟/喝咖啡应该也是一种思考,吃点东西是为了让脑子转得更快一点,上网搜索一下灵感可以借鉴一下其它人的想法,抱怨写注释只是一个例子,更多的应该是抱怨加班或是公司的老板. 如果需要加上点什么的话,我觉得应该加点“重构”,“编译”,“调试”,当然,他们都可以算在coding里.
在Warsztat(一个波兰的游戏开发组织)工作的几年中,我发现一个有趣的现象。经常我们会组织一些编程竞赛,这些竞赛通常分为两种形式。一种是个人行动,一般只有2个小时的时间,另外一种是长时间的(数天/周)。作为一个额外的要求,前者通常限制只允许使用基本的API(SDL, OpenGL等),而后者通常没有限制(可以使用各种引擎,UDK/Unity等)。
结果有点让人吃惊。很多人更愿意参加短竞赛。但不管游戏是在2个小时里开发出来的,还是在4周内开发出来的,它们中优秀的部分的在水平上一样的。为什么?
这也许是我们得到的最重要的教训。如果你需要很快的完成某项事情,代码可能会写的很差,但也会很短小、简练和灵活。如果没有时间的约束,程序的复杂度,功能项和缺陷率会上一个等级。给日后维护带来的工作量并不体现在现在。
在4周的编程时间里,你可以进行数次的快速迭代编程,每一次都对游戏的核心功能进行改进。但如果一开始你就把一些以后未知的特征功能考虑进去,写这部分功能以及修改bug会耗去大部分的时间。诚然,你可以用这4周时间写出大量的assets测试,但核心的游戏娱乐方式设计的足够好吗?
最后,给你们一个绝对有价值的C(++)忠告:当增加新功能时,从最小的核心功能开始: