31415926535x

本地测试的话搞个异步线程监听 mapper 文件的变动来刷新就行，eg:https://juejin.cn/post/7403426280940634112

标签页不多并且主要做一件事的话，好像还可以

但是实际上打开的 tab 和实际要使用是完全非线性的，
可能前几天打开的 tabs 在某个时间点需要唤醒处理，有的可能偶尔调研的东西，需要放着等到后面看他，，而且有时候并行做很多事情
所以我现在都是直接开多个窗口，每个窗口干同一个主题的事情

然后使用 https://sessionbuddy.com/ 来定期（每半个月）清理或者归档就行
目前维持在 500-600 个标签页

别，个人搞农业能够保证每年温饱+下一年的投入就算不错了
去看看老家的现状就知道了，按照我老家周边的养殖来看，小于 100 的都是这个样子的，还不说各种潜在的风险
赚钱只有成规模化才有可能

可能是因为其他服务申请的内存较多且存在超卖逻辑而崩掉了，看看宿主机是不是也有啥服务呢，
如果不是那么重要的应用，加自动重启吧

chrome 感觉还行，公司电脑日常不关机，一周一关，目前维持在 900 左右个 tab 页（不过实际上高频访问的只有近一两百个），开启了 限制标签页内存释放，内存占用大概 5g 左右，没有卡顿

@Plumes 测试环境可重试的话，尝试用 arthas 抓一下看看是哪个方法的问题

1 、step2,4 短期内如果不会膨胀很多不同的逻辑，就直接一串写下去，
2 、如果现阶段已经较多，抽象类中控制主流程，变化的内容交给子类实现，工厂+模板
3 、如果一定后续会增多，责任链或者流程引擎编排下子任务

（ step1, 4 是什么内容呢，我猜是数据加载和收尾发消息等等操作，如果是的话，可以搞个 init, process, after 的模板，process 走工厂

@diagnostics
为什么假定结构复杂的项目就是所谓的中间件、某某框架呢？

我的讨论点是既然一开始就提到了开发编译测试构建这个流程效率很低了，且明知 mvn 工具的羸弱，为什么不审视自己的项目是否结构合理而进行重构，以选择更好的工具链来加速流程（如果你是为了来讨论 出 一个解决这个场景问的话）

> 你想单独跑 aop 的单测是不行的，一定会先去编译相应的依赖（ core 、bean ）两个方案：

假定你说是要只关心 aop 这个模块，那可以认为其他有依赖的都是已经搞好的，那何不分出来多个仓库让 ci 并行编译其他的依赖项，这不是天然的缓存么，而本地只关心 aop 这个模块，重新导入编译好的依赖项不久可以测试 aop 模块了
而且我认为 mvn 的命令应该 i 是用来维护当前项目的（即应该是对根 pom 操作），而不应该从子模块中间来执行

而且都已经是大型项目了，难道从头到尾每次 future 都是一个人维护？一个仓库模式多个人公用一个开发分支来协同开发吗？

工具不好用，不应该立马选择更优的工具链路么。没有选择那不是说明没有到 “工具不好用”的瓶颈吗。这怎么还有

@iseki 但是现在的问题不就是模块太多且在相互依赖时影响效率么，那应该拆分才对的，如果非常紧密是应该在一起并且统一管理的
submodule 好像确实是有很多坑，,不过应该可以用这种思想来开发，主要还是得维护好多个模块在 push 之后的触发的 ci 逻辑就行