UP月记录

个人记录 UP

Created At : 2023-10-27 09:48

Views 👀 :

月记录备份

月记录备份

2023-07

以后写工具应该注意，一个工具放两个代码库维护是容易出问题的，能统一尽量统一，统一不了应该只在一个里面修改

对方回复的内容一定要仔细理解，不要含主观臆断
1. X场景下，……………………………（省略），这个功能就不需要了。（非X场景是需要的，不能直接删掉这个功能）
2. 今天晚上就合入版本了（几点？能不能在全量发布服务器前完成，而不是晚上这种模糊时间）
需求中途变更
1. 代码设计初期一般会留有一些考虑能够应对需求变化，但是需求变化后可能会导致实现可以简化，这个时候继续服用复杂的代码还是简化代码就需要考虑了
多沟通协调
1. 后台有多个服务器，每个服务器不同的人负责，前台可能认为后台是一个整体，所以找你沟通的时候最好不要只考虑本服务器的事情。
  1. 我这里完成了前台认为所有服务器完成了
2. 对方代码还没合入的时候，你说对面完成了，结果实际没完成
测试
1. 一个功能还是完整的测试吧，A功能虽然等于B+C功能，但B和C功能分别正确不一定B+C就是正确的
  1. pyclient加上这个还是很方便的
GM工具
1. GM工具好多都是有使用场景的，非使用场景使用会出现问题，所以还是要标注清楚
流水线异常
1. 流水线异常的时候手动操作了报错部分，然而报错导致后续操作也被中断了，但是忘记了操作后续部分，只操作了报错部分
  1. 流水线都现成的了直接用吧别手动操作了、
2. 新版服务器未更新到目标服务器出了N个乌龙BUG单

2023-08

兜底方案
1. 当时在众多人说自己无法进入游戏的时候，都没有去考虑补上兜底方案
  1. 因为当时考虑到这些都是异常情况，正常情况玩家地图上是不会有自己的主城，只要是正常环境就没有问题
  2. 然而遇到了Logic崩溃了，Logic没有记录选州成功，此时大地图已经选州了，玩家游戏直接卡死，之后才把兜底补上。这次就不是异常情况了，是正常情况下可能会出现的问题了。
一个不起眼的小问题，可能背后的原因是非常离谱的。
1. dev环境选州Logic崩溃，竟然是由于Logic代码写错的原因（为啥外网没有遇到呢？）
2. 测试反馈添加的主城全部报错30000，结果是因为roleId循环的，已经添加主城的roleId再次添加主城，由于兜底机制+指定roleId主城存在就会将roleId顺延，顺延之后的就是空roleid，后面就拿不到离线时间的数据
注重系统整体架构的设计
1. 有输入相比自己死磕能够成长的更快
  1. 看看其他人的方案拆解
    1. 不能同一帧将所有点位检查这种情况，才想到要延时进行刷新。
    2. 不能是单单的将需求点列出来，需要对应到具体的改动是啥，这样评估时间才准确。
    3. 注意下时间评估这里，目前我评估的时间还是非常的不准确的
  2. 看看其他人的cr，不然自己没有负责过的模块是一点都不清楚
    1. 同时看了之后还有和其他人PK的机会
    2. 看看其他人的设计，学一学自己将来才可能遇到，不然都是在自己思维下兜圈子
    3. 看看别人的CR和方案，这里为什么这么设计，自己想的话如何设计，一下对比就出来了。进行后续沟通还能了解到更多。
2. 之前看到帝国觉醒只是想到了战斗服需要在压力场景下减少发包
  1. 但是大地图是不是需要呢？完全没有考虑过，大地图是否需要
    1. 大地图实际是不需要的，至少目前的同步机制是够用的
    2. 战斗服可能是需要的，不过后面就没跟进了解了
  2. 24年2月又做了不下发其他人的PET, 我为什么没想到呢?
3. 千人测试的时候，重启城郊会导致战斗服也需要重启的问题
4. 千人测试的时候，Logic崩溃导致事件完成了任务没有完成
输入
1. 代码
2. CR
3. 方案拆解和评估
4. KM文章
5. 开源项目
注意点（不要将问题带到线上，这样处理起来非常的麻烦，而且会增加不靠谱）
1. 异常情况处理
2. 兜底
3. 自测
需求拆解和方案评估
1. 不能是单单的将需求点列出来，需要对应到具体的改动是啥，这样评估时间才准确。
2. 注意某些重要的异常情况处理和兜底处理
之前删掉了一段代码，导致城郊出现问题，忘记为啥删除的了，后面修BUG还是带上BUG单的链接把
1. 没有强制检查, 保持的不太好
防御性编程，校验外部传进来的参数
野怪最大等级改了获取位置，写代码的将等级为0认为是错误，直接返回了, 对于能跑的屎山小心动.
1. 然而赏金这里有特殊处理，等级是0则按1级

2023-09

遇到BUG还是感觉留下现场，比重启解决问题更加重要
1. 问题可以后面解决，复现问题可能再也没有机会了
编码规范
1. 空指针这种错误都犯了
  1. 改一个位置的时候，尤其要注意使用的所有参数，这些参数可能在外面并没有校验
  2. 改代码比新写代码更容易出现
帮忙
1. 帮忙处理东西的时候，一定要搞清楚，问清楚。自己也要看清楚，不能只是不带脑子的执行了。
注意可能发生死循环代码的兜底
1. 服务器更新脚本中就遇到了，重复的更新服务器。
数值类的最好不要写死
1. 如果是配置中的值，配置变了，写死的数值就会导致问题
2. 还可能导致本来热更就能搞定的，需要重新编译服务器
可能还是要减少通用错误码的使用, 兜底的通用错误码竟然用到了.
客户端参数校验
1. 没想到出现了非联盟成员拆联盟建筑的问题。
压测
1. 压测场景和实际场景不匹配
  1. 出现问题之后，都能发现问题，关键是出现问题前发现限制点
2. 扩容
  1. 寻路服爆炸了，然而没有办法扩容，没有机器。
重新编译的问题，没想到还学到了不少。
1. tars文件重新生成的问题
  1. 先用md5比对写了一版
  2. 结果还是直接用CMake写最好，几行的事情
2. CMake和Make的基本原理
3. 依赖分析，编译加速？

2023-10

迁移日志
1. 最后日志传输工作给了运维来搞，自己搞还是太麻烦了
  1. 该找运维的找运维了
2. 不要压缩超大包，或者进行分卷了
  1. 解压起来对磁盘要求太高了(预期下当前所做是不是可以解决问题, 而不是只顾当前压缩)
性能优化感觉难点是发现性能问题, 包括编译加速. (20%的问题造成了80%的负面影响, 如果去处理另外80%的问题收益就很低)
下午看了看相关的博客，还是感觉要坚持输入一些内容，整理整理哪些可以看吧
1. 阮一峰, 内部论坛
接触了下战斗服和逻辑服的代码, 把相关环境也搭建好了, 后续也确实看过几次对应的代码.
终于把之前想过的时间触发器抽了个Module出来, 后面就可以复用了. 写Module之前vscode中写下预期设计挺好的, 继续坚持了.
做事之前尽量确认好, 不然竹篮打水一场空, 时间浪费不少.
1. 需求理解一定要正确, 仔仔细细逐句逐句的看需求点.
2. 看看需求的特殊要求, 比如退盟之后是否重置, 这个影响到了数据记录到哪里.
3. 还得考虑下客户端是否支持
4. 考虑下实现的复杂程度, 可能预期很简单, 但是因为牵扯过多或者不支持导致变得复杂.
指定时间点触发的循环定时器, 每轮都计算下时间相比固定时间的更加稳定.
主城周围搜索物体, 采用涡旋状搜索, 类似蚊香.
有的功能大地图并不知道有没有, 还是说下不知道之类的吧, 最后接下来了发现是别人的工作.
代码BUG
1. 显性BUG, 状态校验放错了位置. 写的时候还是没考虑好运行路径.
2. 隐形BUG, 抽函数后加东西, 导致相对于原有增加了一些功能, 这种是很危险的抽函数.
看到小问题的时候深究深究就会发现可能并不是那么简单
1. 转表工具报错, 空白列占位
尽量统一函数对统一内容进行清除, 比如标志位, 这样方便发现错误清理的地方
指针判空, break
1. 这次是在JavaScript中没有判空, 有的block没有数据
遇到问题即使下意识感觉问题就是那里, 也一定要确认下. 可能并不是那样.
如果解决一个小bug, 完美的方式改动很多的话, 感觉不如简单的处理下.
1. 长久来说, 还是要考虑下解决这个问题, 算是一个优化点?
尽量不要写死参数, 配置或者计算得来, 否则后面还需要同步修改.
测试东西或者搞新东西的时候, 注意不要影响到旧的东西, 该开测试空间的开测试空间
1. 这次自动提单提了2K+, 如果不是提到了临时空间估计直接爆炸了.

2023-11

配置化
1. IDC的流水线配置化了, 一些写死的内容移到了外面, 同时把流水线进行了统一, 不然一下改几条流水线直接升天
查BUG
1. 仔细检查触发条件, 为什么这个场景触发了, 其他类似场景没触发, 这两个场景看起来很相似, 哪里有区别
隐形问题, 只有监控没有报警or明显提醒, 几乎相当于没有监控.
1. 磁盘炸了, 服务器对外无法提供服务.
降本增效
1. 对于非重要数据, 用了Prometheus的双写服务, 把数据向自己搭建的服务器上同步一份, 这样就不用在腾讯云存储太长时间
写BUG
1. 城郊里的功能没有加开关, 影响到了大地图
坚持记录每天所做所想, 不然忘了自己做了啥还是难受.
公共位置要使用公共账号和密码, 不把自己账号密码存进去, 容易出问题
当时看到经分文档里两个说明很别扭, ABBA格式, 不是ABAB, 想着容易出错, 结果真的把AB用反了.
7月就记录过了, GM工具标注使用场景, 结果到了11月还是没几个工具标注, 复习下.
JPS寻路算法学习, 这个得出的就不是最短路径
移动接口的调用地方太多了, 结果搞出来了一个死循环的移动, A向B移动被修正到C点, A向B移动. 能够统一调用位置就好了.
有的需求来来回回改的太多了, 加上后面加了新需求, 旧的代码没有删掉, 新旧代码同时作用导致表现有问题.
1. 说的就是回城控制

2023-12

编译大小分析
1. -fno-loop-optimize这个拖了很久,还搞了个乌龙出来
2. 编译的时候没有-r, 用release和debug版本比较的, 最重要的是通知到群里的是乌龙信息
日志分析, 看了看骏鹰的日志清洗相关的内容, 写了一个ES导出脚本, 这下可以一次查询所有的日志了, 还不会占用IO. 顺便把WARN也导出了, 只需要改一个字段.
1. 这个轮子是真TM的难用. 用开源的你就大大方方的用, 结果旧版本+乱搭配
2. 后面还是尽量充当制定规则的, 整好文档, 减少被@的次数
深入浅出编译链接, 看了看留了点印象, 但是也不太深
尝试优化elf文件大小
1. 大小可以减少, 得看看副作用具体是啥, 文档描述的不太清楚
2. 变迁一下, elf是object文件合并的, 直接去统计下object文件获取更好, 已经帮忙分割开了.
3. 两个方面
  1. 整体优化, 通过添加编译选项, 去除非必要的debug信息
  2. 单独优化, 查看较大的object文件分析原因
gdb卡慢的原因分析
1. 目前来看就是卡在了符号表这里, 首次运行慢, 后续运行快
2. 好像是首次跑火焰图
C++避免重定义, 定义和声明分开
1. 增加inline
2. 定义放到不会被include的文件中, 如cpp, h文件可能目前没有被include但是将来不一定
小需求
1. 死亡军队过期兜底删除
  1. 现在写别人分配的一句话需求, 小心不少了, 基本都会问清楚.
2. 城郊拾取不再强行要求有军队
3. 联盟领地buff
怪物组复活和自动拾取逻辑修改
1. 怪物组复活这里最开始通过事件处理已经理不清了, 换成了定时器检测.
2. 自动拾取这里有一个参数一直都用错了, 最后的目标不一定是击败者
3. 感觉开始处理还是取巧了一些, 结果后面要重写了
查看是啥问题导致global更新不上去的, 打包global版本服务器
1. 很迷的问题, 换成request好了一点
竞技场支持怪物组和BOSS
1. 小需求, 但是这个需求整体还是很大的, 周边系统还是要去看一看
2. JJC需求
3. 定时器修改
堡垒刷新bug的修复, 当时刷新理解的有偏差, 导致写了bug出来, 进了新的阶段刷新不出新堡垒, 验收和测试也没发现, 最后修的时候真的是火急火燎的.

2024-1

整了个编译发布流水线的历史变更记录, 希望能总结出一点东西, 毕竟这个东西变更了太多版本了, 为什么没有一开始一步到位, 是有哪些问题之类的.
bug部分和up部分都拆出去了, 这里就搞下汇总之类的, bug那边也能写点记录, 方便后续查看
上周六终于是找了个腾讯学堂的视频看完了, 写了点总结, 这貌似是我接近两年来, 第一次看完历史视频并写笔记? 之前只整理过直播如何写博客的
占矿
1. 起初是想用击败者, 结果参数用错了, 参数并不是击败者. 不过就算是用对了, 也会有参数为空的情况出现.
2. 改成从战败者的follower中选取, 但是被击败这个事件中, 野怪的follower信息被清理了, 所以提前进行判断, 结果发起的MoveTo会被后续的覆盖, 改成立即移动之后依然有问题.
3. 此外还有一个问题, 依赖战死和取消战斗状态, 提前之后就会被影响.
4. 直接改成了从玩所有军队中获取, 改回了之前的阶段, 结果军队列表中存在死亡的军队. 过滤了死亡军队目前正常了.
我大意了.jpg
1. 事件监听错, 本该是A事件, 结果监听了B事件.
2. 误删正常代码
考虑不全面
1. 参数未判断, 0范围的视野也进行了添加.
2. 开服日期之前启动服务器, 此时计时器需要为负天数. (这里还出过一个时区的问题)
3. 恢复为旧的代码时, 旧代码已经不能执行了.
做了没必要的
1. 直接过滤掉所有可能阻挡位置的遗忘堡垒点位, 不要为了展示高超的技术写复杂了.(之前做了太多额外功能了百分比阻挡这些, 直接粗暴点就好)

2024-2

增加成员变量之后需要考虑,构造函数, 拷贝构造函数, 移动构造函数, 赋值运算符
1. 漏掉之后会导致新字段丢失的问题, 比较难查.
添加1和添加2分两步的RPC操作, 添加1到添加2之间会有时间间隔, 添加1之后执行的操作没有添加2的信息.
1. 有新增添加或者修改操作的时候, 可能添加1也需要修改, 支持直接添加这些字段, 分两步会有时间间隔.
一些内容可以和策划对, 更简单的实现是否可行
1. 从击败军队还是所有军队中选一只去占矿
看了podagent的实现, 本身podagent不需要任何特殊配置, 依托游戏服务器启动时向其中注册(socket)信息.