大佬们, 关于 Java 后端空判断

大佬们, 这种过滤是不是多余的啊, 数据库设计了部门 id 不能为空, 前端也加了校验, 后端还要进行多步的空判断吗, 有点晕了, 一般在什么情况下做这种多步的空判断啊
https://imgur.com/5RXY9q2
以下图片是改造的, 会有什么问题嘛, 是不是到这种程度就可以了
https://imgur.com/jWhJzYu

主要为了学习代码编码风格和规范, 看哪些开源项目比较好啊, 或者看什么别的东西

目前看的是 SmartAdmin 这个开源项目学习, 大佬们有了解的嘛, 看哪位作者的风格比较好呢, 若依实在不喜欢, 目前觉得这个 SmartAdmin 对我帮助很大

补一个问题 Java 后端大部分人都说 CRUD, 企业中 CRUD 到底是什么样子的, 一般一个后端会分多少个表啊, 或者分多少个模块啊, 学到什么程度可以, 一直没有概念, 距离辞职, 已经学习一年了

改的没问题，直接 map 提取部门 id 过滤就行

因为前面已经过滤 null 了，后续就不需要再检查 null ，所以你改得没啥问题。其次这代码本身就怪怪的，分页查询返回的 List 包括 null 元素（难道是返回固定长度的 List?）

感觉你应该没有太多编程经验，去看这种后台管理项目，去扣它的业务逻辑细节，实际上是走入了误区，想得太多写的太少。这种项目就是用来二次开发的，你自学根本没有实际的需求，看这种只有皮而无肉的空架子代码，那自然会陷入“这里要不要检查 null”，“这里为啥用 Throwable 而不是 Exception”等基本上没啥意义的实现细节。

我的看法是，真正能够有所收获，建立信心的是写自己的项目。你去找一个自己感兴趣且熟悉的领域，找到切入点，写一个至少能用的应用，不需要功能多丰富，实现多完美，至少其是自洽的，麻雀虽小，五脏俱全。比如你的求职目标是 Java 后端，那就去仿一个网站，从需求分析、数据库设计、后端实现、前端实现、应用部署一步步做起，并且去相关垂直领域宣传，给别人使用。

后端肯定要做判空，无论什么时候后端的入参都要校验，这是防御性编程。前端不可靠，你怎么知道用你系统的是人还是机器，数据库是用来保存数据的，如果把判空逻辑放到数据库，那这个系统得烂到什么程度，绝对是个屎山

@vyuai 才这么点就算多????

没写出 30W 行代码别说自己花的时间多

db 里面做了非 null, 去掉 null 判断倒是没啥问题, 就是可能某些代码校验工具里面会报 error 或者 warn.

但如果你不确定 "是否要判断 null", 那就果断判 null 吧, 浪费不了多少效率

前端校验是改善用户体验，可选
后端校验是系统逻辑处理，必选

1. 前端约等于用户输入，永远不要相信用户的输入是正确的，参见测试工程师那个段子；
2. Throwable 有两个子类，Error 和 Exception ，打开 Error 的源文件，注释上明确写了：……because most applications should not try to catch it.（翻译一下：因为大多数应用程序都不应该尝试捕获它），通常我们认为是一些硬件上或者 JVM 的问题，此时程序已经不能正常运行，事务回滚也没什么意义了。

你这套逻辑，加不加这个判空都可以
我的建议是如果你的业务逻辑需要这里的 id 不能为空，就自己加上，不要把这个控制交给数据库
毕竟这个字段不是主键，有可能后续因为什么原因就改成可为空了

这不是可选过滤，这个就不应该过滤。（除非在别人代码加逻辑怕出问题）

万一有人把映射改了，这个字段查不到值了，要第一时间抛出异常，而不是业务逻辑错误。