..
刚到游戏公司那会，记下的关于做好工作的感悟，叫 编程习惯。还挺有意思，留个念想。
流程
总体设计 -> 细节设计 -> 流程图示 -> 编码 -> code_check -> running -> bugfix -> testing
生产环境
-
内存爆炸
不能让内存有无限增长的情况. 例如, 系统中有一个订单列表
orders = [], 用户购买时产生一个订单信息order = {'ordid':1, 'good': 'coins15w'}添加到订单中orders.append(order). 当用户付完款, 完成订单时再将这个order从列表中移除.此时, 如果只有购买请求, 没有完成订单的操作, 意味着订单列表只增不减. 即便单独的
order信息再小, 也能通过简单的脚本模拟购买请求, 在短时间能将内存撑爆. -
集中配置系统变量
从开发分支上线到生产环境时, 通过一两次简单的操作就能将代码完全部署到线上.
第一步, 生成生产环境的配置信息 第二部, 执行运行脚本开发环境的配置 1/2/3/4 独立成文件, 而不是将多个环境的配置配置在同一个文件里. 互相影响泄露信息.
-
升级系统
版本迭代有可能影响持久化的数据表结构, 上线之前, 通过脚本将线上老的表数据结构转换成新版系统的结构.
升级前进行数据文件备份
脚本需要有开始提示,结束提示,中间的进度提示(防止代码死循环而不知道).
那些未存入数据库系统的, 线上的, 内存中的, 临时的数据, 重要的, 不可删除的. 新版的代码中需小心处理. 或者先强行入库之后, 再进行迭代操作.
-
钱很重要, 数据很重要
涉及重要数据的过程都需要加日志.
危险的操作,如清库,删记录,从日常接入用户权限中移除,特定用户执行特定权限,执行前给出二次确认提示.
-
充分测试
尽量模拟真实环境的条件下测试, 1.主观臆测很容易出错, 2.越急越快越容易出错, 3.尽早完成,尽早放入测试服,有充足测试时间; 另一方面,借助测试服进行盲测
-
记录日志
数据变动部位的开始/结束需加入日志,至少变动之后需要记录
