如何写出简短的代码

其实这个部分针对于新手，老手可以不看

• 及时清理不再使用的代码或者配置信息

对于垃圾代码或者过时的配置，坚决清理干净，避免程序过度臃肿、代码冗余

• 保持统一的命名规范

• • 变量名统一使用驼峰形式书写，变量首字母小写
  • 不要使用一些常见包名作为变量名，如time config等
  • 如果参数为一个常量，它的首字母必须大写，且使用驼峰形式命名，如最大线程数应该表示为MaxGoroutine

• 保证你的变量名在足够明了的情况下尽量简单

• 使用defer做资源清理工作

• 在一个导出方法书写之后，应该在方法顶部加上注释，标注出函数的具体作用，如果有必要的话加上参数的意义

// Add 返回a+b
func Add(a, b int) int {
     return a + b
}

• 在写完代码之后记得对代码进行格式化操作
• 最紧张的资源应该尽量少的访问

在我们目前的服务中，数据库资源往往是最为脆落的、最为紧张的资源，我们应该尽量把访问拦截在上游，有访问频次限制就加上访问频次限制，如果有内存缓存就查内存缓存，否则查redis，没有redis可以考虑熔断降级，保证只有一定量的请求到达数据库

• 磁盘I/O，网络延时往往比你想的要更加耗时，应该尽量少的访问磁盘，以及减少网络通信中包的大小

我们禁止在一个循环中做SQL查询操作，这个可以改写成in语句或者any语句，如果我们需要循环做update语句时，最好预处理我们的SQL语句，并且开启一个事务进行更改

• 内存缓存只能用于缓存一些不经常被更改且即使被更改之后也不会影响现有业务的数据

• redis线上操作禁止keys、hgetall等耗时操作

• 用户输入的SQL参数严格使用参数绑定，防止SQL注入，禁止字符串拼接SQL访问数据库

• 用户请求传入的任何参数做有效性验证(试情况而定),忽略参数校验可能导致:

• • page size过大导致内存溢出
  • 恶意order by导致数据库慢查询
  • SQL注入

• 表的命名最好是遵循“业务名称_表的作用” 如 (game_config)

• 单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。

• 不要使用 count(列名)或 count(常量)来替代 count()，count()是 SQL92 定义的标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。

• 数据订正（特别是删除或修改记录操作）时，要先 select，避免出现误删除，确认无误才能执行更新语句