gdtdpt

@zcfnc 还要纠正 leader 的根本性错误，血压 up

首先自身业务代码层次要清晰，各层级间耦合度要低，这样在 Mock 的时候工作量才会少，才能专注测试的内容，不然光写 Mock 就一堆代码。
在一个 Service 方法里调用另外 3 、4 个 Service，然后又调用几次 Dao 不同的方法这种流水帐一样的代码写 Mock 都要写死人，怎么让人写单元测试。

主要是现在前端组件都需要 npm，JSP 不适合 npm 。
比如 vue，虽然我也见过用 cdn 方式引入，一个 JSP 一个 vue 对象的方式，但是对应的 UI 库对 cdn 的支持就不是很好了。

@JasonLaw 偷懒的时候吧，比如逻辑部分会 throw 多种 Exception 子类，不想在 throws 里写全，直接写个 Exception

@yazoox 可能是后端很容易找到借口把工作推给前端。
我们这里有很多项目都是打着 REST 的名义将数据字段关联动作推给前端的，比如微服务下两个服务间 A 服务业务表保存了 B 服务业务表的 ID 做为逻辑上的外键，但是数据库中因为是不同的库所以没有约束。这时候后端就会借口说根据 REST 风格，我以为把数据相关的 B 服务业务表的 id 给前端了，至于 id 关联的数据，前端请自己到 B 服务请求数据回来。
这时候就出现了某个页面只有一个 table，但是加载过程中会发送 10 多次请求的情况，而且加载了几次后内存缓存的数据量大了，页面加载的时候有明显卡顿，这时候领导来一句“页面为什么这么卡，前端怎么写的，优化一下”，这时候就很难受，明明不是前端的锅。

成本大概就是完成以上流程花费的人力成本吧

借题问一下各位大佬们，在工作中经常会遇到一些非资源类的 Api，比如开始执行某个任务(xxxAction/execute)之类的，这个动作虽然可能在某些资源下，可以用 /resource/:resourceId/execute 这种方式，但是如果有多种类型的 action，是使用 /resource/:resourceId/:actionType/execute 好还是将 actionType 放到参数中好，或者有没有什么更优雅的方式？

之前掘金公号推的时候看了一下，有点兴趣，看目录感觉内容是偏项目架构的

点赞👍

@myBatis 哟，哪看出我是上补习班的了，楼主也是说想学后端，又没说想学能做到什么程度的后端，楼主说自己现在是前端我推荐 nodejs 怎么了，上来就喷人你是什么情况。
再说补习班怎么了，补习班坑你了还是抢你工作了，鄙视补习班你是什么情况，你能保证补习班教的你都会？