31415926535x

别，个人搞农业能够保证每年温饱+下一年的投入就算不错了
去看看老家的现状就知道了，按照我老家周边的养殖来看，小于 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 逻辑就行

问个问题，为什么这种多个模块的项目都要放到同一个仓库中并且由一个 idea 打开呢，maven 确实一般都是用在层级比较小的项目的构建，那为什么不拆分到多个仓库中，分开并行构建（或者用 git submodule ），因为每次改动不是所有的模块都是会修改的吧，而且即使有应该也是一步步来开发测试的

然后为什么 ut 会依赖其他模块的类呢，ut 不是一般都是测当前类的方法么，，如果是集成测试，是不是还是在一个统一的维护 case 的平台来操作呢，pipeline 的单测通过之后，触发集成测试的验证

@3x1415926535 一瞬间以为我回复了🤣