项目结构及编程规范

项目结构

提到项目结构这点，其实它的重要程度很多人都忽视掉了，清晰合理的项目结构可以让多人开发更高效，越大的项目效果越明显；优秀的项目结构可以让人更好的沟通，让其它模块的人迅速熟悉和了解另一模块，还可以让新加入团队的人快速了解和掌握项目。

先说项目结构。项目结构非常重要，有的项目结构非常混乱，别说是新加入团队的新人，就是熟悉项目的人也不能迅速的找到一个功能所在的位置，这样的目录结构就是非常糟糕的了，熟悉项目的人都很难第一时间找到想要的东西，更别说其他人了，这为新加入团队的人增加了熟悉项目的难度，同时在项目不断庞大的后期维护中也越发的难以控制，维护成本越来越高，而这种情况往往随着时间的推移，混乱程度越来越高。而清晰规范的目录结构则不同，它可以让开发人员规范自己的代码，可以快速的找到想要找的功能，新人也可以快速了解项目，这给后期的维护和工作交接等降低了很多成本。同时清晰和规范的目录结构也能约束开发过程的不规范。下面列举两个客户端的项目结构，单并不是唯一，也不是最优：

//以MVC为分层的目录结构
root -- core
     -- game -- model
             -- view
             -- control
     -- platform

//以功能为分层来管理目录结构
root -- core
     -- game -- shop -- model
                     -- view
                     -- control
             -- task -- model 
                     -- view
                     -- control
     -- platform

上面两种结构中是常用的两种管理方式，core是项目中使用的核心库，都是从业务逻辑中抽象出来可以复用的类库；game是游戏的业务逻辑目录，主要了两种管理方式都是体现在这里；platform是游戏外平台渠道相关的逻辑，是对外的业务目录。第一种通过设计来管理目录的这种方式适合项目规模不大，业务较少的项目，这种形式就非常简单明了，但是规模较大、业务较多的项目就不适合了，继续用这种方式管理，就会造成每个目录下臃肿并且业务逻辑显着冗余，这时适合第二种通过业务逻辑来管理目录的这种方式。

除了项目内的目录结构外，还有项目外的整个工程目录结构也要管理清晰，这个涉及到后面各个部门间的协作沟通，以及后期不同版本的维护等。多个游戏版本开发中，有很多管理方式，一般常见的有主线开发打支线和支线开发合并到主线上这两种。比如主线开发就是有一个版本作为主线版本，其他所有版本的内容都现在主线版本中开发，再同步到其他支线版本中，其他支线版本再针对各自的需求制作各自特殊的修改。主线版本中版保证了各版本中共性的部分可以同步，例如在某个支线版本中发现了一个bug，不仅要在这个支线版本中改掉，还需要同步到主线版本中并验证，如果主线版本中也存在相同的问题，那么其他从主线版中打出去的分支版本也都要进行同步的修改。在这些个版本中，无论主线还是支线，除了代码的同步外，还有游戏配置、资源源文件等也要同步维护。这些负责的功能管理都需要项目的工程目录合理清晰，否则会越来越乱，越来越臃肿，难以管理。

项目结构看似简单，实质上有很多东西值得讨论，同时也有很多项目组并不重视这点，小型的项目可以能还好，中大型项目如果不重视这点，尤其是到上线维护后，版本过多弊端就会明显，所以项目之初就要考虑好这些问题。

命名规范

意义

命名规范的意义不用多说，很多开发者应该或多或少都应该感受过优秀的命名规范带来的益处或者糟糕的命名规范带来的痛苦。命名规范和上一节讨论的项目结构一样，能够为项目带来客观的正向收益，下面就仔细的聊一下命名规范。

原则

首先先讨论一下命名规范的原则。其实命名规范并没有一个统一的标准，每个公司甚至每个项目规范可能都不一样，但这不是问题，只要我们遵守几个原则去定义规范就好了，下面几个原则点是我个人的总结，有不对或者不全面的请指出。

• 简单：命名要尽量简单，用简短的命名来表达语义，而不用很复杂的词组，当然如果这个变量所表达的意思就是很复杂，那么也不要强制把它简写，能看懂毕竟比简单要重要的多。
• 明确：明确就是指能够看懂所表达的意思，并且没有多重语义。上一点提到过，明确要比简单重要。
• 统一：这点非常重要，在实际开发中这点总被忽视，而且也带来了很多问题。比如对点券这个变量的命名，有人命名成cash，有人命名成money，甚至还有ticket，这在其他人阅读代码时就造成了很大的困扰，会认为他们是三个东西。所以这种变量命名一定要统一，并且是全局统一，不仅在客户端或者服务器，二是整个项目，包括前后端以及策划文档等。

条目

这里罗列一下哪些东西需要命名规范，前两类在各种编程入门、进阶等书籍或者很多地方都说到了，所以前两点就不细说了。

• 项目名、文件名。
• 包名、类名、函数名、变量名。
• 项目中的资源名。资源命名除了能体现是什么功能外，还要体现出资源类型，所在目录等。最好是单独拿出一个资源时，能快速的知道这是什么资源、在哪里、什么功能等。
• 模版生成的代码命名。工具自动生成的模版代码在项目中很常见，这类代码一般是不允许直接手动修改的，所以这部分代码除了遵守基准的命名规则外，还要能体现出它是模版代码，在使用或者引用时能让使用者或者阅读代码的人能够知道这部分代码是不能直接修改的。
• 文档、日志。提到命名规范时，大部分人可能首先想到并且只想到的都是编写代码中的命名规范，其实除了编码外其它很多东西也是需要命名的。比如，比较重要的一部分就是文档，文档中对一些名词的命名也要规范统一，否则后期理解维护成本会较高。

经验

这里简单说几条经验，规范这个东西越早提出越好。当然对应一个新团队来说，可能没有这些积累，但是早期应该有一个大概的规范框架，在项目开发过程中不断完善和修改，慢慢就积累下来了。还有关于命名统一这点，项目可以做一个通用名词对照表，放在一个大家都可以方便查看的地方共享，由大家来维护。最后再次强调命名规范的重要性。

参考推荐用名

这里有个常用短语命名大家可以参考：

参考推荐用名：http://www.jianshu.com/p/126dc658d763

最后欢迎关注我的公众号，浏览更多文章：