某手游项目组4个月进度的感想与领悟

************************

2.底层架构必须完善且牢固，并且底层与上层逻辑间必须分离不可杂糅。没有牢固的底层，则上层建筑修的越高整栋楼崩塌的可能性越大，就算通过修修补补实现了未崩塌，那栋大楼也是摇摇欲坠破烂不堪。

************************

3.规范清晰的命名规范和代码风格是必须的，但在制定出相应文档后，真正的实施依靠于一个严厉的监督者。

************************

4.程序设计上讲究可扩展性，但可惜再优秀的架构师设计出来的框架其可扩展性都是局限在一定扩展方向内的。初期确定了游戏的玩法必将导致程序架构上侧重于方便实现该玩法，后期对玩法的较大调整（比如由一个shellraser玩法改为刀塔传奇的玩法）其必将对原有的架构造成破坏性影响，该影响一定程度上是不可修复的。因此在更换游戏玩法等设计重构上需要小心，程序禁不起多次大方向的需求改动，因此没有绝对意义上能支持一切扩展的可扩展性框架。

************************

5.功能设计上，游戏的功能（如技能）不应是越强大越好，越强大的功能往往对平衡性造成极大影响，且越强大的功能会导致程序需要做一些破坏性的操作。好的游戏应该经典好玩，好的游戏功能应该简单明确，且应该从设计上避免对其他模块的影响。试想一下如果lol中某个英雄的技能可以绝对性的杀死敌人，那么还会不会有人愿意接受lol及这个英雄。一个有优秀的策划方案，其应该能让程序在简单清晰的代码中将其实现。否则要么是策划不行，要么是程序不行（但不要下意思的认为实现不好就一定是程序的问题，程序不是神，有时候实现还确实需要策划方案的配合）。

************************

6.提供给玩家的操作应该流畅明确，不应该有任何的功能或状态破坏玩家的操作体验，切莫跟玩家作对，不应该尝试从限制玩家操作或体验的角度来解决某个你遇到的问题，如果这种问题真的发生了，那么请优先思考某些功能本身是否有问题。玩家获得的操作体验必须畅快且无歧义。

************************

7. 清晰度到底意味着什么？对代码的评价中有如下几个点（包括但不限）：性能，安全性，防错性，容错性，可扩展性，可移植，可重用，可维护性，清晰度。

    从字面理解，清晰度似乎只代表着外观，拿人做比喻可以理解成清晰度是一个人外在是否整洁审美，似乎不影响此人的内在与整体实力。回到代码这一层，清晰度似乎只代表代码是否优雅顺畅，似乎不会影响其他几个重要指标。而性能、容错防错、可扩展性等才应该是代码的重中之重。上述的观点是对清晰度最大的误解，实际上在编程领域，许多神一般的大牛（至少我知道的）均表示，清晰度应排在代码诸评价点的首位，因为清晰度是其他指标的前提，没有了清晰度其他的根本无从提起。

    没有清晰度，意味着代码很难理解且牵扯很强，正常的流程中存在着复杂的跳转和对外部的依赖，因此耦合度必然很高内聚性必然很低。因此可扩展性低，这是毫无疑问的。扩展一个功能时会发现此部分对一大堆外界存在依赖，且流程错中复杂，扩展根本无从下手。

    没有清晰度，意味着程序员无法对程序的执行细节一眼望穿，意味着具体的执行逻辑如一张复杂的渔网纠缠不清，程序员根本无法理清顺序，这样的代码其bug率无疑很高，而且项目月进行到后期bug愈多，bug量和bug率随着时间的递增而递增。且后期开发一个功能或修复一个bug很可能还将又触发之前已经修复的bug，不排除会导致如这现象：即到后期，欲修复一个bug，结果引发三个bug，而修复这三个bug又各引发三个bug，如此递进。这绝不是危言耸听。

    清晰度不高，则容错防错无从谈起，容错防错是指代码能够容忍意外的事件发生，而这必须建立在能明确哪些是意外的事件哪些是合理的事件这个前提条件智商。清晰度不高，代码复杂，程序员无法判断从局部出哪些是合理的事件哪些是意外的事件（必须是全局，但这做不到，而且部分事件在特定条件下合理在特定条件下不合理），因此，容错防错力不从心。

    可重用就更不必谈，清晰度不够的代码必然模块或函数不够内聚（因为内聚的代码自然很清晰），不够内聚的代码如何重用？

    更甚者，清晰度不够的代码，到项目后期连正常的功能开发都很难做到，清晰度不够意味着你很难做到增量编码，无法做到增量编码意味着什么？无法做到增量编码意味着每增加一个部分则都要牵扯到之前的代码，因此后期不存在小功能，因为每个小功能都会以为无法增量编码而转变成大功能，大功能又因为牵扯太多而产生无数bug。

    可维护性，这个就更不提提，代码无法掌控无法理解如何可维护？

    最后一点，如果去了解一些失败的项目的案例会发现，代码清晰度不够极容易导致项目烂尾，根本谈不上上线盈利或不盈利。

    正常情况下，程序不应该影响策划，策划理应由自由伸展的空间。但当策划方案在程序现有框架里无法得到良好的实现，如要实现必然会降低代码清晰度的时候，是应该考虑策划为程序所让步，要么此放弃此策划案，要么考虑给程序时间用以重构（当然反复的重构也不被推荐），又或者很多时候该考虑是否应从策划层面解决这些问题：即为何会诞生这些实现复杂的策划案。当然也可以考虑，是否是程序的水平不够才导致该策划案无法被良好的实现。

    来看几位大师的言论：

Bjarne Stroustrup，C++的发明者：

我喜欢代码优雅而有效。逻辑应该很简单，使缺陷难以隐藏。依赖关系应该最少，从而便于维护。根据表达清晰的策略，有完备的错误处理。性能接近最优，这样就不会诱使人们进行无原则的优化，把代码弄得一团糟。干净的代码能做好且只做好一件事情。

Grady Booch，《Object-Oriented Analysis and Design with Applications》的作者：

干净的代码是简单而直接的，就像写得很好的诗。干净的代码从不隐藏设计者的意图，而是充满了鲜活的抽象和简单的控制结构。

************************

8.项目组类各职位人员的职责

游戏项目组内，策划及程序属于开发人员，其负担了游戏的开发工作。其他职位属于协调配合职位，他们的工作是协调人力物力资源配合策划程序进行开发，绝对不能本末倒置成了策划尤其是程序配合他们来完成工作。

当一个需求能不用程序实现的时候尽量不用程序实现，更精确的说法是一个需求的实现应该采取实现工作量最小、对当前游戏影响最小、对游戏的其他考核方面（如代码稳定性、清晰度）影响最小的方式来进行

有一句话听起来很绝对，但实际中很有用：策划能实现的坚决不让程序来实现。这句话听起来是程序在偷懒，但是如果你真正同时参与了策划和程序两边工作的话，你很可能会认同我的观点：当一个工作策划也能实现程序（或美术）也能实现但最后让程序来实现，那么99%可能性下是策划（或美术）在偷懒。在讲述这个观点的时候我们必须要明白一个事情：策划或者美术搞定一个事情，这种方案是一劳永逸的，它不会给程序的稳定性带来任何影响（不会导致崩溃也不会引来大量bug），它不会降低代码的清晰度从而不会对未来的开发带来影响（未来的功能开发依然可以高效且高质量的进行）。当如果让程序来实现一个策划（或美术）本可以实现的功能，则往往以为着该功能是一个资源调节性或者逻辑特殊判定性的功能，程序实现此功能必然会导致清晰度的下降（甚至是严重下降）、稳定性的下降（特殊判定一多稳定性无法维持）、结构的破坏（代码结构），其代价之高，我想没人愿意看到（策划人员想必也不愿意看到）。

************************

9.新人宁可不要，底层设计决不可让新人接手

项目前期的开发应该由经验丰富的老人（程序和策划皆是如此）来开展，切勿安排新人来做，否则大家会一起吃这样做带来的苦果——该苦果可能最终会无法被咽下。

************************

************************

11.避免上述问题，不断的收购极具战斗力的小团队是不错的选择，学学人家腾讯吧某司，吸收成分健康快速循环流淌的新鲜血液淘汰掉那些高血糖高油脂已经半凝固状的腐朽血液。

************************

12.如何避免任用一个只知纸上谈兵的策划和一个只知道埋头苦干（逻辑实现）的程序，这是管理者们最大的责任

新手策划最擅长纸上谈兵，新手程序最擅长埋头苦干逻辑实现。以上二者共同的特点都是将导致游戏（玩法及代码）混乱不堪不可维护，避免此问题的根源不在于要求策划和程序严于律己（期望新手产出高质量的成果这一想法本质上就过于天真），而在于要求管理者谨慎用人。

只有哪些有几年踏踏实实底层工作经验的策划才能避免纸上谈兵，只有哪些有几年踏踏实实代码编写经验的程序才能避免写出纯逻辑实现的功能代码。

************************

13.命名及代码风格、防错等规范统一的方法

    命名和代码风格等规范极其重要，但极容易被忽视（尤其是当主程主管本身就没意识到上述的重要性时），而且重在执行。

    在项目开始开发前，当由主程及核心程序员商讨确认命名规范和代码风格等要求，并形成编码规范文档，全组传送阅读并作解释。这一部分还是容易做的，难做到的是在新人不断加入后还将上述要求保持好。因此十分建议，新人加入项目组后，绝对不应该急切的让他们参与开发（视他们水平和项目进度留给他们两星期到一个月的学习上手时间），此段时间除了要求他们熟悉源代码熟悉项目进度熟悉项目规划外，应该讲之前形成的代码规范文档发送给他们要求他们阅读牢记，并给出一定的考核测试文档等到他们能通过这份考核测试文档后才让他们参与开发。

    考核测试文档不要求复杂，能表达意思达到目的即可，大概可以这样编写：给出一份实现了特定功能的小项目，但该项目的代码命名、风格等均不符合规范要求，考核方式及目标是要求新人按照给出的代码规范文档对该项目进行修改直到其达到规范要求。

    上述此点看起来似乎不太重要（很多人不把它当回事），甚至认为这东西有则无也也可，我见到的很多项目组都没有给此点予足够的重视。但此点到底有多么重要，我想只有等到项目组因未重视此点而在后期付出惨痛代价的时候我们才会知道——但此时已晚。