个人认为 CR 还是非常有用

我是 QA ，RD 的代码我都会 CR 。
我对业务还是相对熟悉（这个前提很重要），CR 不是发现语法问题，这些静态代码检查就行了，主要是发现业务逻辑问题，还有实现的问题，实现不能得过且过，还是能发现很多问题的
还有个作用就是促进相互了解，两个人开发模块，可能都重复造轮子了，互通一下比较好。还有就是你以后也会开发别人的模块，相互了解团队人员也能相互 backup
其余还有个好处就是大家写代码会多想一点，把代码写好。我们团队之前就遇到一个模块的代码 review 了一星期还没合进去，有了这次经历后续那个 rd 写的代码质量就好很多了。（当然这个看人，说不定别人还恨你）

最后频率问题
「每天提交代码时互相 Review 一下，人也轻松」你这样不太好，代码不是按行或者按天分的，今天写的逻辑都不完整，而且每天提交也不是个好习惯。应该是能运行的一个子功能提交一次（ bugfix 除外），基于此 review 。提测前可以再拉上 QA 一起 review 下

我天天上班迟到（ 10 点上班）

楼主太秀了

那不就是你路由器不行 连的是 5G 频段吗？

其实主从就挺好的，前面在放个 proxy 。主从切换多演练几次，问题不大。

加油吧 校招的 hc 还是有的，多面面。

每个时代有每个时代的问题，只是现在确实过了红利期，各行各业赚钱都不容易。你现在至少毕业了，你看看今年考研的情况。

@ChrisFreeMan 这不是因为使用问题嘛 正常哪需要这么多

@24owls 嗯嗯 我都试试

@Cooky 我试试

@imn1 运维已经要从我工资里面扣了 （开玩笑

@alphanow 「用文件读取处理的方式生成一个对象」这是什么操作，但可能也不行 因为文件内部还有 import 嵌套

「开一个独立的 process 处理数据，用完直接干掉」改成多进程模型，这倒好像可以，但其实就用不上缓存了，不知道性能如何

@v2exblog 还没呢 得先多想几个解决方案

@zhengxiaowai 哈哈哈，老哥 你这留下的坑，请打开飞书交流

嗯嗯 hook 的思路想过，还得具体试试

@hhhhhh123 这样细节上不好操作
特别是请求量大的时候，比如 a.b.c1 a.b.c2 cache 里面有 a.b ，如果 a.b.c1 后删除 a.b cache ，刚好 a.b.c2 内部在用的时候取不到了

@PrinceofInj 比如有些优惠券 别人能看见你看不见

退货可能变得严格，比如之前即使过了退货时间也能免费退换，黑号就不行了

@ruanimal 拆分也没用吧 总量不会变。耗内存

@keepeye
importlib.invalidate_caches()
Invalidate the internal caches of finders stored at sys.meta_path. If a finder implements invalidate_caches() then it will be called to perform the invalidation. This function should be called if any modules are created/installed while your program is running to guarantee all finders will notice the new module’s existence.

这个主要是发现新模块的，比如 a.b.c 多了个 a.b.c1

实际试了下也不会清 sys.modules

简单来说用 Postman 其实挺好的

写代码的话 一般都是 py.test reqeusts 封装下 《使用 Python nose 组织 HTTP 接口测试》 https://iyaozhen.com/use-python-nose-to-http-api-test.html