旧有的笔记 -- 编程习惯

..

刚到游戏公司那会，记下的关于做好工作的感悟，叫 编程习惯。还挺有意思，留个念想。

流程

总体设计 -> 细节设计 -> 流程图示 -> 编码 -> code_check -> running -> bugfix -> testing

生产环境

1. 内存爆炸

   不能让内存有无限增长的情况. 例如, 系统中有一个订单列表 orders = [], 用户购买时产生一个订单信息 order = {'ordid':1, 'good': 'coins15w'} 添加到订单中 orders.append(order). 当用户付完款, 完成订单时再将这个 order 从列表中移除.

   此时, 如果只有购买请求, 没有完成订单的操作, 意味着订单列表只增不减. 即便单独的 order 信息再小, 也能通过简单的脚本模拟购买请求, 在短时间能将内存撑爆.

2. 集中配置系统变量

   从开发分支上线到生产环境时, 通过一两次简单的操作就能将代码完全部署到线上.

    第一步, 生成生产环境的配置信息
    第二部, 执行运行脚本
   

   开发环境的配置 1/2/3/4 独立成文件, 而不是将多个环境的配置配置在同一个文件里. 互相影响泄露信息.

3. 升级系统

   版本迭代有可能影响持久化的数据表结构, 上线之前, 通过脚本将线上老的表数据结构转换成新版系统的结构.

   升级前进行数据文件备份

   脚本需要有开始提示,结束提示,中间的进度提示(防止代码死循环而不知道).

   那些未存入数据库系统的, 线上的, 内存中的, 临时的数据, 重要的, 不可删除的. 新版的代码中需小心处理. 或者先强行入库之后, 再进行迭代操作.

4. 钱很重要, 数据很重要

   涉及重要数据的过程都需要加日志.

   危险的操作,如清库,删记录,从日常接入用户权限中移除,特定用户执行特定权限,执行前给出二次确认提示.

5. 充分测试

   尽量模拟真实环境的条件下测试, 1.主观臆测很容易出错, 2.越急越快越容易出错, 3.尽早完成,尽早放入测试服,有充足测试时间; 另一方面,借助测试服进行盲测

6. 记录日志

   数据变动部位的开始/结束需加入日志,至少变动之后需要记录