引言
记录总结了从7月到11月积累的非技术经验, 涉及添砖加瓦方方面面.
前言
本文是自己从7月到11月积累的部分非技术经验, 总结了工作记录中遇到的问题. 由于是个人经验积累, 适用性不强, 也不是大而全. 发布出来主要还是用于自己自勉, 整理了, 不发出来有感觉浪费.
史山之从设计到制作
需求设计
需求评审
评审时, 如果不是很确定这部分功能, 自己负责的服务器能不能做, 就不要承接下来, 最后发现做不了, 再转手.
需求文档到手
- 从需求文档中找到需求点, 协商好需求点由哪个服务器来处理, 防止开发重复内容或者无人处理. 或者由于种种原因是对方压根做不了, 只能自己来做.
- 尽量避免想当然的情况, 比如文档中说每天增加一次挑战次数, 但是没有提初始次数是多少次, 这时候最好沟通下.
- 虽然可能不清楚其他需求, 但还是尽量能够判断下和其他需求是否有重叠, 导致出现边界情况, 对好这个时候怎么处理.
需求文档看完, 开工之前, 先定协议
定完协议之后, 各个参与人就可以独立开发. 如果先开发再定协议, 可能导致后定的协议不便于所有人使用.
开工之前, 进行下预期设计, 同时评估时间
- 写代码之前先在vscode进行下预期设计, 写写伪代码. 虽然需求可能要的比较紧急, 但花一点时间提前设计下, 比直接撸起袖子开干还是感觉最终效率好很多.
- 代码放到哪个模块
- 这个功能大概是什么流程
- 预期设计完成后, 根据功能点和设计, 能够更加准确的进行排期.
- 根据需求工作量确定下复杂程度. 虽然完善的设计很重要, 但有时会因为过于完善, 导致简单的需求变得非常复杂, 同时后续也不一定用得上这次设计的完善机制.
- 预期下异常情况处理和兜底处理
制作
将重复的项目抽取出来
第一次做的时候, 可能考虑到需求比较简单或者时间不足, 一个功能就放在了一起实现, 但是后续又双叒叕用到这个功能了.对于个人提升来说, 就可以考虑抽取出来了.
做好兼容性处理
负责的功能要将兼容性处理做完善, 能够做到其他人无感知是最好的. 不要想着其他人只需要小小的一点处理就能解决, 到时候不管提示再多次都会有人@问什么问题的, 所以最优解是其他人无感知.
预估时间后无法完成后, 要及时周知相关人员
应该及时通知，否则默认你这边完成了, 其他人进行了一些处理, 导致不必要的问题出现.
开发的时候加足DEBUG日志
- 遇到问题的时, 查日志相对看代码是效率非常高的解决方式.
- 加日志的位置和内容还是吃经验. 个人感觉站在将来查问题的角度去加日志有帮助.
- DEBUG日志一般会在线上关闭, 一些重要内容就要注意使用更高的等级, 否则一点日志都没, 外网问题全靠复现才能查.
个人统一的工具仓库
工作中难免会写出来一些小工具, 提供给他人使用的时候一般都是放到公共代码库中, 这个时候工具就会在本地和公共代码库有两份, 注意只在一个地方修改, 否则容易出现不一致.
需求中途变更后简化代码
代码设计初期一般会留有一些考虑能够应对需求变化，但是需求变化后可能会导致实现可以简化，这个时候继续复用复杂的代码还是简化代码就需要考虑了.
代码尽量一步成型
个人感觉修改次数越多, 出问题的概率越高, 修改了这里忘记了同步修改其他地方是重灾区.
避免设计无用的东西
一些本来加个函数就能解决问题的, 是否要抽成一个模块就要仔细考虑下了.
数值类配置化or计算化
- 数值类的最好不要写死
- 如果是配置中的值，配置变了，写死的数值就会导致问题
- 还可能导致本来热更就能搞定的，需要重新编译服务器
- 尽量不要写死参数, 配置或者计算得来, 否则后面还需要同步修改.
减少通用错误码的使用
如果错误码一对一能够及时发现问题, 如果是多个地方使用的, 只能靠日志+看代码路径了.
客户端参数校验
老生常谈了, 基本上每本书里都会提这点, 这次就出现了所有服务器都没校验的一个操作, 甚至是客户端都没检验.
状态校验放错了位置. 写的时候还是没考虑好运行路径
加代码的时候, 仔细考虑好相关的运行路径. 可能某个分支下, 这次加的就是有问题的.
加快调试速度
需求写完之后, 想要测试下自己的代码, 尽量将GM工具完善好, 否则每次修改代码都要重复操作好几步, 导致花费的时间反而比加一下工具要多.
- 副作用, GM工具要标注下使用场景, 否则错误场景使用后容易出乌龙问题.
史山之从修改到回归
修改
修改前-不确定是bug还是feature时要进行确认
否则可能将feature作为bug处理了, 后续还要改回来, 造成不必要的时间浪费或者麻烦.
修改前-遇到BUG还是感觉留下现场，比重启解决问题更加重要
问题可以后面解决，复现问题可能再也没有机会了
修改前-简单方式解决问题
对于一个小bug, 简单的打个补丁就可以解决的话, 还是偏向于打补丁. 至于刨根问题解决虽然好, 但是一旦牵扯过多, 然后自己对项目不了解, 大刀阔斧重构容易出问题.
查问题中-用物体的事件经过查问题挺方便的
事件驱动的场景下, 可以先查询顶层都有那些事件, 看看这些事件的内容和实际是否正确, 比一下钻到底层查问题要快很多.
影响扩大-确定修改后果, 注意一个函数都有哪些作用
- 一个函数可能不是你想的那种作用, 或者带有一些条件, 再或者是副作用. 之前没有使用过的, 不熟悉的最好看一看实现.
- 修改一处代码的时候, 考虑全面是否会波及其他调用方
影响扩大-抽取函数注意不要影响到原区域功能
发现一段代码可以复用的时候, 会从其他函数中将这个函数抽取出来. 但是抽出来的函数增加代码的时候, 注意不要影响到原位置. 如在抽取出来的函数中, 由于其他需求, 增加了一层判断, 导致原位置(抽取函数前的位置)功能被影响.
影响扩大-enum中增加新类型
enum中增加新类型后要注意看看这个enum的使用位置, 如果只是关注自己新写的代码忽略旧代码, 可能导致旧代码的判断过不去.
修改后-BUG修复关联BUG单
否则后续会忘记为啥修改这里, 当时是什么BUG做出的这样的处理.
测试
尽可能进行全面的自测
真的有某些代码是依靠BUG运行的, 修复BUG之后反而运行不了了, 所以基本的测试是必需的, 能想到的可能影响到的地方, 最好也是自测一下. 想到的地方不去测一下的话, 可能就是想到的这个地方出了问题.
A通过B通过不等于A+B通过
一个功能还是完整的测试吧，A功能虽然等于B+C功能，但B和C功能分别正确 不一定B+C就是正确的
自动化测试
一些功能测起来可能比较麻烦, 使用自动化工具会方便很多, 比如pyclient完全模拟一个客户端, 写代码有时候比点来点去构建测试环境方便很多.
积累
问题的优先级安排
并行处理任务的时候, 注意优先级的安排. 可能当前的工作进行到一半, 有其他高优先级的工作要做的话, 还是要切过去. 尤其是查BUG到一半的时候, 很容易上头, 导致又多查了半天.
充分关注自己的工作
其他人都开始要联调了, 自己的功能还没发布到服务器上. 虽然当时在处理其他问题, 但还是已经做过的善后优先一些.
不懂就问
文档较少, 全靠口口相传, 遇到不懂得项目, 一定要进行询问, 不能常识性的去做.
重视不起眼的小问题，可能背后的原因是非常离谱的
遇到过不止1-2次了, 看起来就是很小的一个问题, 深究起来问题可能一串一串的.
特殊处理
没有注释的代码, 可能使用了一些特殊规定, 如果错误删掉了就会影响到功能. 比如数值是0的时候, 按照1来处理, 看描述很简单, 但是实际代码可能没有那么直观.
预期下当前所做是不是可以解决最终问题, 而不是当前某一步
当前所做可能确实能解决当前问题, 但是不一定能解决最终问题. 比如传输日志之前需要压缩, 压缩成几个小包也是压缩, 压缩成超大包也是压缩, 但是压缩成超大包可能不利于传输和解压.
去看看别人负责的模块, 不要只顾自己的模块
对于多模块(多服务器)后台, 多去关注下自己负责模块之外的内容, 这样对项目了解的更深.
问题的原因, 不一定是第一印象想到的点
遇到问题即使下意识感觉问题就是那里, 也一定要确认下. 可能并不是那样.
协作
他人回复的内容一定要仔细理解，不要含主观臆断
- X场景下，……………………………（省略），这个功能就不需要了。（非X场景是需要的，不能直接删掉这个功能）
- 今天晚上就合入版本了（几点？能不能在全量发布服务器前完成，而不是晚上这种模糊时间）
后台开发代表全部后台, 前台开发代表全部前台
后台有多个服务器，每个服务器不同的人负责，前台可能认为后台是一个整体，所以找你沟通的时候最好不要只考虑本服务器的事情, 有需要就拉上其他服务器的一起建群.
帮忙
帮忙处理东西的时候，要问清楚原因, 搞清楚要做啥, 不能只是直接照做.
对应的事情尽量给对应的人去做
运维可以通过内网传输日志, 比通过sz和rz快和稳定很多.
36技
CR发起前可以自己整一个临时CR看看代码
每次提交代码前, 全局的看一看自己的代码, 可能功能正确, 但是有不小心动到其他地方的代码.
测试代码在最终CR的时候要及时去掉 使用TODO 名字方便检索
使用TODO标记测试代码, 提交前批量查找下, 全部去掉.
不建议手动操作流水线
流水线中某一步错误后, 尽量重新触发流水线. 手动执行错误的一步, 很容易出错, 漏掉某些操作.
自动化操作没有监管人
流水线有的没有人监管, 即使将结果通知到了使用者, 使用者可能也会忽视结果, 导致有错误没有发现, 进而导致其他问题. 所以错误提示要尽可能的明显.
压测和扩容
- 压测
- 压测场景和实际场景不匹配
- 出现问题之后，都能发现问题，关键是出现问题前发现限制点
- 压测场景和实际场景不匹配
- 扩容
- 重要节点前, 预备一些机器, 否则出问题的时候, 机器没办法即时拿到.
发现问题比解决问题更重要
性能优化感觉难点是发现性能问题, 包括编译加速. (20%的问题造成了80%的负面影响, 如果去处理另外80%的问题收益就很低)
指定时间点触发的循环定时器, 每轮都计算下时间相比固定时间的更加稳定
尽量统一函数对统一内容进行清除, 比如标志位, 这样方便发现错误清理的地方
测试东西或者搞新东西的时候, 注意不要影响到旧功能
该开测试空间的开测试空间, 防止影响到其他空间