GPT答疑记录

月记录备份

2023-07

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

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

2023-08

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

2023-09

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

2023-10

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