@pkwenda 了解，我设想的场景可能是给 review 者大概感知下哪块是需要重点看的

回到了母体之后，没等我弄明白状况，就被叛军 xx ；随后一阵晕眩，我又回到了母体

一样的问题，我们的需求是 xml -> json -> pydantic object，小文件完全 ok，文件变大之后问题会越来越明显，无论是速度跟内存占用都很爆表。前面的文本处理效率还能接受

之所以要用 python 主要是一些包调起来方便，现在已经准备慢慢用 java 重写了。。

@wangyzj 20M 左右就已经慢到不能接受了~

@BingoXuan 也是一种办法了，不过有些工程不是一个库形态没有 setup.py ；

@jsisjs20130824 哈哈，这个题突然跑好远。pylint+tox 是阔以；

@black11black 当然从开发者的角度我们肯定是希望支持越高越好，不过上生产确实有些特殊原因受限，在运维解决好这些问题之前我们只能在我们这一侧保障质量；

@Leigg 按我想法 gui 不如简单的命令方便呢

@kingfalse 学习了

@dqh3000
跟 @charlie21 的观点差不多，不想浪费本地办公机器的算力

@594duck
看了一下是运维同学，我理解你们的场景需要；
统一打包是最合理的，但是一线工作里总是存在一些 trade off ；
没有吹 docker，但它的确是目前容器化做得比较好的；
我没有鼓吹技术，仅提 idea，不知道你这些都是从哪里读出来的？

@devliu1
谢谢，docker 官方 sdk 有 go 跟 python，本来打算用 go 写的就不会有这个引入成本，后来觉得先简单点用 python 写个出来看看；
IDE 跟 debug 确实无解了，工作量过大，也没那么多时间

@devliu1 懂你意思，不过写这个脚本还是费点事儿
顺便，楼下这个 https://code.visualstudio.com/docs/remote/containers 貌似不错

@xiangwan 好东西.. 可以脱离 vscode 吗

@Alias4ck 其他设置项堆进去就行了，不是大问题； linux 跟 macos 是用 dockerpty 做的，拼 command 只是为了兼容 windows

@devliu1 求个例子
@xinta 这倒是真的
@mmrx 对，这是策略层面的；不过有些团队的现状是，CI 不够完善，但项目不能停还得往前跑
@Jirajine 有点，容器化也就是为了隔离

@hantsy 同意，单测大概率是推不动的，一般有这几个原因：

- 项目安排不会预留写单测的时间
- 一般都有测试兜底，做不做无所谓
- 自测 or 质量流程稀烂

基本是个恶性循环，除非项目愿意让步 or 有个比较有魄力的人来下决定。开源社区这类东西做得好一般也就是上面三点做得好：

- 没项目压
- 没测试，自己兜底
- 流程相对严谨

比起单测，我觉得覆盖率反而是个比较值得推的东西。

自己的 python，覆盖率到一定程度之后还是蛮有用的
https://github.com/williamfzc/stagesepx

@waruqi 权重太奇怪了，看了一下 traffic，连一次访问都没有，感觉是直接限流

hackernews 还是得足够吸引人的内容才行，沉得太快，然而老外的关注点又很奇怪；
stackoverflow 时间周期可能会比较长；
国内互联网最好还是去各种社区发帖子

一般选择去咖啡厅之类的地方看看书，整理一下自己近期的工作内容跟知识体系..
选择去外面还是因为，毕竟周末，不想给自己太多工作的感觉：）但又还是想利用起来这部分时间，所以咖啡厅之类的地方就是最优解了