stream 很好用 ，仅仅是 foreach，就没必要用了。
map groupBy filter reduce sort limit 写起来很爽

要么延期，要么拆需求分阶段上。粗暴的解决加人 /加班

数据库设计要有人把关~ SQL 不熟悉还是多练，数据统计的需求多了就熟了

不要碰这个，某银行部门做 cobol 的都逼着转型学 java 了重构了原系统了

看到楼上知乎链接里说，数据库早期的设计是满足 C/S 构架的，真是一针见血，DB 也承载服务端的工作，需要数据一致性和安全。而现在流行的主流的构架是 B/S，DB 只专注于存储，似乎外键、存储过程、触发器都没有什么必要，很奇怪当初还要设计这些东西，安全和数据都可以由应用控制。阿里的 java 开发规范也明确不要使用外键和存储过程。java 适合应用层，阿里的规范也就是 B/S 构架下的一种最佳实践吧。曾经听说过，前端 js 里写 sql 直接调数据库，或者存储过程，把后端的处理分到前端和 DB 上，我觉得这设计真糟糕，没反应过来这是 C/S 的构架，至少有一点好处，减少了中间的消耗，提高了速度。

没人用的系统才是最好的系统 XD
该改就改，还能怎么着。

你自己用就行啦，不用管他们。没冲突的~

别急啦。多面下，没有辣鸡，只有放错位置的资源。你只是不适合某家公司罢了，总有你擅长的，面试的时候可以尝试引导下，表现出你的优势，先找家你认为合适的，再计划下

语气确实不对，工作本来就是谈恋爱一样，合不来就拜拜。不过这个职业规划可能是简单了点，价值观和他不一样。招的是只是干活的人，要求太多了。说的不对，看看就好哈

可以尝试下，不要怕做不好嘛。单身是很自由，结束单身了，痛和快乐并存。

窝不是打广告，随想云，可以看看，运维比较烂，配置我觉得可以，我搭机场的

用 jenkines 就行啦，gitlab 拉代码打包，maven 有 docker 插件，打包的时候可以触发制作镜像上传 habor，再写个部署脚本，更新镜像，重启。

mybatis-plus +1，在此基础上做请求参数解析，结合这个插件，做个 CURD 的框架，单表的 CURD 完全不用写，只要写前端。要重写的都是多表操作，和特殊的业务。

我最想知道如何处理业务压力的？不加工期，人力资源也没协调好，或者人力有限，不专业，比如后端开发前端。最后都是基本都是通过加班解决，下班也赶。赶完了，为了赶进度，又可能分担其他人的工作，体验极差。

做你想做的事，为自己干活才有动力，其它的负责就行了

不工作~