游戏服务器编程概述

发表于 | 分类于 |

规范 - golang

  • 函数注释
1
2
3
4
5
6
7
8
// fn意图
// @param p1 - 第一个参数(p1含义)
// @param p2 - 第二个参数(p2含义)
// @return r1(or TYPE) - 第一个返回值(如果函数返回值没有定义名称标注类型)
// @return r2(or TYPE) - 第二个返回值
func fn(p1 TYPE,p2 TYPE)(r1 TYPE, r2 TYPE){
    ...
}
  • import顺序
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import (
    标准包
    程序内部包
    第三方包
）
import (
  "flag"
  "net/http"
  "common"
  "common/zebra"
  l4g "github.com/ivanabc/log4go"
)
  • 全局const 和 var位置
    • 全局const,var变量放在文件最上面（import下面）或者保存在单独的const和var文件中。

  • 命名

    • 禁止程序中使用缩写或者有歧义的名称。
    • 采用驼峰式命名。
    • 形参和局部变量采用驼峰结构命名，首字母必须小写，不得出现下划线。
    • 常量统一采用大写字母，单词之间使用下划线进行分隔。如果是包可见的常量，可在其名字前加上 “k_” 作为前缀。可导出常量与不可导出常量应该分开声明，不得出现在同一常量声明块内。 例如: 
    1
    2
    3
    4
    5
    6
    7
    8
    9
    // 常量命名方式 
    const (
     	k_CONST_A = 1
     )
     const (
     	CONST_A = 1
     )

  • Slice初始化

    • 已知slice长度，使用make([]type, len)。
    • 已知slice容量，使用make([]type, 0, cap)。
    • 直接使用字面值形式[]type{A,B,C}声明和赋值，取消没必要的append操作。
  • Set类型
    • 使用map[Type]struct{}表示set类型。

设计

基础原则

  1. 模块原则： 使用简洁的接口拼合简单的部件
  2. 清晰原则： 清晰胜于机巧
  3. 组合原则： 设计时考虑拼接组合
  4. 分离原则： 策略同机制分离，接口同引擎分离
  5. 简洁原则： 设计要简洁，复杂度能低则低
  6. 吝啬原则： 除非确无它法，不要编写庞大的程序
  7. 透明性原则： 设计要可见，以便审查和调试
  8. 健壮原则： 健壮源于透明与简洁
  9. 表示原则： 把知识叠入数据以求逻辑质朴而健壮
  10. 通俗原则： 接口设计避免标新立异
  11. 缄默原则： 如果一个程序没什么好说的，就保持沉默
  12. 补救原则： 出现异常时，马上退出并给出足量错误信息
  13. 经济原则： 宁花机器一分，不花程序员一秒
  14. 生成原则： 避免手工hack，尽量编写程序去生成程序
  15. 优化原则： 雕琢前先得有原则，跑之前先学会走
  16. 多样原则： 决不相信所谓不二法门的断言
  17. 扩展原则： 设计着眼未来，未来总比预想快

面向对象设计

基本元素

  • 封装
  • 继承
  • 多态

基本原则(S.O.L.I.D) )

  1. 单一责任
  2. 开放封闭
  3. 里氏替换
  4. 接口隔离
  5. 依赖倒置

设计模式

项目原则 参考

1
2
3
4
5
1. Passes the tests
2. Reveals intention
3. No duplication
4. Fewest elements
5. The rules are in priority order, so "passes the tests" takes priority over "reveals intention"
  1. 测试，测试再测试
  2. 减少繁琐的继承层次设计
  3. 函数功能单一，避免一个函数实现多种功能
  4. 提取重复代码，避免一点改动多处修改(不只限于函数，还包括类和package)
  5. 注意扩展性和接口设计
  6. 清楚简单的算法的复杂度

重构

目的

使软件更加容易被修改和理解。

方法

项目

  • 少三
    1
    2
    3
    4
    5
    6
    7
    8
    原则
      新代码设计时考虑重构，为后续添加和修改功能留下空间。
    代码设计待改进的地方（随后会有相应的案例分析）
      1. 事件机制
      2. 商店重复实现
      3. 各种重置的统一处理
      4. 微服务化

资料

  • UNIX编程艺术
  • 设计模式
  • 重构-改善既有代码的设计
  • 代码大全
  • 编写可读代码的艺术