现在前端 spa 框架应用如果不做好架构规划，代码审核等约束，是很容易构建出以 mb 为单位的 bundle.js ，再加上很多公司内网的客户端(电脑浏览器)性能并不高，如果再使用 IE 打开，再 ajax 请求上千条数据，是很容易直接卡死的，用户体验非常不好。

以上是我公司内部某个应用整改前的真实情况，这个应用后端开发总是想着只把数据给到前端就行，业务逻辑能让前端做的都让前端做，前端实在做不了的才会放到后端。
整改前，没人觉得几 mb 的 bundle.js 有什么问题，用开发的用的电脑测试没觉得慢，直到有一天领导打开一个页面加载需要 30 多秒，领导强制要求整改。在没有专业前端技术主管的情况下，没有人知道应该怎么改、往哪个方向改，前端代码写得太自由，都揉在一起了，拆分也需要重新梳理需求，整个过程异常痛苦。

相对来说，后端主要是用 Java 开发，强类型保证了代码不能乱写，逻辑至少是可读的，springboot 框架和 mvc 的代码结构深入 curd boy 心，结构清楚逻辑好梳理，光看代码就能看个大概，相比前端一个 ajax 如果不真正执行，返回什么数据我都不太清楚的情况好太多了。

考虑到团队成员的能力差异、异常排查的难度、可能出现的坑的大小、帮别人填坑的难易程度等因素，如果我是项目管理，我也会要求逻辑代码放后端。

对于服务端的开销问题，一般业务逻辑不太容易影响服务器性能，如果真的到了由业务逻辑影响服务器性能的时候，也应该好好审查一下后端代码或者逻辑是不是有问题，一般这种代码或者逻辑放到前端也不一定能顶得住(比如对大量数据做聚合)。

@coolcfan 你好，这个我详细看过，macOS 的 2020.2 版本的 Preference 里 maven 是没有'Import Maven projects automaticlly'这一项的，对比的是 2019.3 版本。在配置其他地方也少了一些配置，只不过我使用起来感觉差异最大，最不方便的是 maven 的 auto-import 这个功能没了。

@Habyss 你好
1. 单位有正版化要求，但是 idea 这个工具还没到必须要购买的地步，eclipse 一直在那，所以不太可能集中购买。
2. 我没有想要白嫖，只是想说有没有价格稍微能接受的购买渠道。
3. 不设置快捷键是因为我需要用到的电脑太多了，linux/windows/macOS 这三个系统的功能键位都不太一样，我希望常用的软件除了关键配置其他的都保持默认，这样能保持当在新的环境中只需要少量配置就能上手工作。
4. EAP 玩玩还可以，工作上还是不敢用的，万一出了什么问题不好排查是我的问题还是 EAP 的问题。

@MLeo 你好，是可以的，下载页面有关于社区版的许可说明，是 Apache 2.0 的 license，可以商用。

我公司里现在所有项目差不多都这样，我不想鄙视谁，但是天天看着他们得过且过，这里复制一下那里粘贴一下，从来不会想去弄明白为什么，真的很气。

@liubx kill -15 是不会的，springboot 会向 eureka 发送完服务下线的消息才停止。

设计模式的目的主要是解耦，让用户使用抽象的与细节无关的东西，不是为了接口而写接口。
这样做的好处是
1.对调用方只需要在意抽象的东西，不需要管理具体实现，具体来说就是我不用在意通过依赖注入或工厂方法拿到的一个东西它到底是 AImpl 还是 BImpl，总之它是这个抽象(interface)的 Impl 我就都能用。
2.对服务提供方我只需要在正确的地方提供相同抽象的不同实现，调用方代码都是一样的，只需要维护服务提供方的代码。
3.调用方和服务提供方都只需要遵守抽象的规则(interface)，两方之间不需要沟通。

在 C 井和 Java 中，最没有细节的抽象就是 interface，基于 Java 、C 井这种纯面向对象的语言就会变成“基于 interface 编程”。

当然现在很多教程都是照本宣科，到底需不需要 interface 我个人的看法是看代码是不是真的需要抽象，比如 MVC 结构的 web 项目，我的 Service 层就这么一套逻辑，一般我是不创建 interface 的，因为我觉得这里我不需要抽象，如果业务需要一个 Service 内的方法存在不同的实现，那么我才会创建 interface 。

缓存问题即使使用了 Vue，Angular 这种文件名 hash 的方法还是会有缓存问题，因为对 index.html 的请求结果很可能是会被浏览器缓存的，特别是 IE 系列的浏览器。

我倾向于毫秒时间戳，javascript 官方标准好像没有要求支持 ISO8601 的解析，全靠浏览器支持、js 引擎支持，或者项目中引入第三方库。
我之前的项目中有遇到 js 解析 ISO8601 字符串，我使用 new Date('ISO8601 字符串')，在基于 chromium 的浏览器上能正确解析，但是在 macOS 的 safari 或者 iOS 的 webview 上好像是报错的。

可以用，有坑，而且坑不少，很多坑没文档说明，遇到了也不知道怎么解决，只能换种方式。

虽然我们对数据整合都是前端处理，但是我不赞同前端处理。我认为后端接口应该基于业务需求而不是基于数据类型。

我们很多项目前端为了整合一个 table 的数据需要调用 7 、8 个后端接口，本身又是 SPA 架构的前端，聚合全在浏览器里搞，有些接口对应的 sql 还有点慢。领导的反馈就一句话：“为什么这么慢？”，因为项目逻辑已经很复杂，架构已经定死，现在只能哪个页面领导觉得慢就改哪个——面向领导优化。

改得多了我经常在想，既然这样，我弄一个 SSR 的前端框架直连数据库不是更好吗，为什么还要多一层后端。

分开好，大项目里牵一发动全身太难受了

@balabalaguguji iPhone 的待办是你想要的逻辑，也做到你想要的和苹果电脑完美结合，只要一到时间，你的 AppleID 下的所有设备都会通知。

主要就是懒和本能的抗拒。
对于 CSS 无非就是盒子模型，而且现代浏览器+CSS3 已经不需要像以前 IE6 时代需要很多 hack 操作来做兼容，已经简单很多了。
我从后端被挤到前端刚开始也很抗拒，觉得 CSS 弄不明白，好烦。但是当我认真去看 CSS 禅意花园的源码，突然觉得每个页面也就那样，就是盒子模型，一部分 CSS 决定盒子放哪里，一部分 CSS 决定盒子长什么样，一部分 CSS 决定盒子的动画，盒子就是 HTML，没了。瞬间觉得比后端的 Spring 有多少种注解，每种注解怎么用简单得多。
对于 JS 能用得好后端各种框架，我相信对于前端使用 Angular 、React 、Vue 框架不会觉得难。

@smallgoogle 用 move_to_element_with_offset 吧，好像没什么好的方法，要不就每次 preform 后再 move_to_element 移动到某个元素来重置鼠标位置吧，不知道能不能 move_to_element('body')。