结婚了就不能撩漂亮小姐姐了……

是的，只要你能把所有代码都写对地方就行。

正常的操作逻辑：在 A 上面打包成 jar 或者 war，然后上传到 B 发布。

你非要通过 A 控制 B 去 pull 源代码打包发布也不是做不到，但会比较麻烦就是了。

本来也是和楼主一样的计划，然而因为疫情，也只好先维持维持了。

@keelii
> 前端代码中本质上讲 HTLML/CSS 都是配置文件，而且是「快销」的配置文件。它不需要抽象，只有 JS 有逻辑，需要抽象。但是前端不得不把配置文件和程序的代码混合在一起，而且在这中间摇摆不定，最终使得代码没有条理。

我个人理解，前端的 3 个组成：UI(控件)、数据和交互事件，组成了 MVVM 里面的 View，应该由 HTML+CSS 来定义，这里面不应该包含任何的逻辑。ViewModel 负责数据和控件的绑定，处理交互事件，如果需要加载 /保存数据，则回调 /调用 Model 里面的相应方法。ViewModel 和 Model 只有 JS 代码，不应该有任何的 HTML 和 CSS 代码。

MVVM 模式本身就是一种抽象和封装，但似乎很少有人能够理解 MVVM 模式，大多数程序员只会套用框架。其实交互逻辑有时候也挺复杂的，其复杂程度并不下于后端的复杂的业务逻辑。如果不能适度抽象和封装，这代码想必是 bug 百出且难以维护的。面对这种挑战，前后端其实也没什么不同。后端相对来说会比较成熟，所以前端在遇到挑战和困难的时候，也不妨看看后端是如何解决的。

@DOLLOR 你说的很对，这就是过犹不及的道理。做什么都应该掌握一个合适的度，在工程上面尤其如此。

用 select 的结果集替代 values 的内容，一般用于倒腾数据、生成临时表记录和使用模板数据来生成记录。

我认为前端主要的问题是不懂何为抽象，何为封装，更不懂什么叫做结构。结果就是代码臃肿、混乱，难以阅读和维护。当然后端同样，但比前端稍好一些。

@qloog 就是语法要求更严谨一些，原来 5.7 上没问题的 sql，8 上面可能会报错。跑一遍单元测试就知道有没有问题了，有问题也很容易改。

去年就升级为 8 了，然后有一点小坑，处理完就好了。

这个解耦没多少意义啊，而且平白地增加了复杂度。再说，日志是允许丢的数据，没必要和数据完整性死磕呀。
@wangking

耳塞洗不坏，晾干还能用。没有连耳机一起洗就成，哈哈哈

fluent 直接写 es 啊，要什么 kafka 和 logstash

只要钱给够，工期不催命。你当他是外包的甲方爸爸就行了嘛……

@sunorg 楼主但凡能够稍微审视一下自己，你我也就没机会回复了……

楼主棱镜门了解一下

这种懒货就不要帮了啊。或者以自己没空为由，给他介绍个有偿服务。

Kibana 的 management 里面看一下 Index management 有没有内容，然后 Index Patterns 要根据日志格式简单设置一下，很简单的。

没有同样强大的，Navicat 有类似功能，但用起来差点意思。我已经用脑图替代 pdm 了，感觉比 pdm 好用得多。