有，想看就看，有时一个 bug 想改就告诉开发怎么改，然后催他提交

还没失业

我更倾向于提测后功能验证前就 review，重点应该是先看代码变更影响范围，然后针对实际测试情况去针对性的看功能逻辑，对用例完整性也可以做到反补（review 更多的在前期工作，熟悉了持续迭代过程中耗费的时间会越来越小，覆盖率什么的华而不实，根本的目的在于对实现的理解以及整体的把控）；还有一个是发布前检查变更是否符合预期有没有夹带私货，线上配置是否合理等等；

真的想提升能力：
1、去翻负责的业务的代码，弄清楚相关需求的代码实现，提 bug 的时候能清楚的猜到哪行代码出现的问题；
2、思考对应业务代码问题怎么修改，不明白的就看开发修复后的代码提交逻辑，看多了就会了；
3、多去翻优秀项目源码，学习设计模式；
只想找个工作：
1、混关系，学吹牛，转行；

前提：懂代码、懂代码、懂代码！
1、先了解什么是性能？性能指标怎么指定和分类；
2、了解代码实现、可能的性能瓶颈以及性能优化方法；
3、使用工具更多的剖析整个链路路径，结合 1 中的指标分析指标是否合理以及哪些有缺失；
4、分析需要做性能业务的部署方式、访问方式、各种外界因素（海外构造弱网意义不大，正应该剔除网络因素给出纯服务层响应；
5、模拟重点性能场景、单场景、混合场景，抽象成脚本进行压测；
6、结合压测数据分析数据合理性以及性能解决方案；
7、给自己揽活；

牛啊

IOS 抓包需要设置代理，每次刷新都会生成新的端口，对应的就需要修改手机配置的代理端口，有啥好办法解决么