第一个乍一看不觉得有问题，仔细看发现只是为了 equals 避免空指针写了这么一大堆 if ，改成 Objects.equals 就好。

如果是业务条件需要的类似判断场景，那么像图一这么写两层 if 嵌套其实比楼上一些人的全写到一个 if 括号里更容易阅读。

就是昨天，用百度导航到某景区停车场，它给的路线是驾车到景区侧门然后步行穿过景区内到达前门的停车场，我当场裂开。

全方位的优势，除了价格。
但是价格成本这东西怎么说呢，之前银行、运营商学着互联网搞“去 IOE”，去了这么多年还去不掉，很大一个原因就是你要自己养一个玩得转 MySQL 的团队，去优化，去定制开发，这个成本未必比直接用 Oracle 低。当然了，系统规模不大直接用社区版的 MySQL 也够了。

再以我作为软件开发者角度的使用体验来说，Oracle 下 sql 语句想怎么写怎么写，只要不是索引没覆盖到使用的字段，性能基本没问题。MySQL 就不行了，必须要熟悉 MySQL 索引背后的机制，熟悉 sql 优化的逻辑，一个不小心性能就爆炸。
所以很多大厂的规范也是不允许在 MySQL 下做 3 张表以上的关联；从 Oracle 迁移到 MySQL 时把复杂 sql 语句做拆分也是必须的步骤。
很久以前做过的一些系统里面不少 sql 语句几十行，甚至上百行，先不讨论这种代码是不是很烂，但它在 Oracle 下跑起来性能就是没啥问题。

@coderxy 不用微服务这套框架就不能自己拆分项目了么
太多人无脑套用微服务框架这套东西事实上就是徒增了很多没必要的工作。

你们这些觉得太闲会废了的赶紧回国，拼死拼活几年后就会发现，也并不能拼成个人上人...

我在想是不是现在的小朋友都不会写 sql 了 所以 jpa 这种东西才会这么热

@lewis89 你才是根本就不知道什么叫做中年危机。

中年危机的本质是人在年龄增长过程中的心理反应，不局限于特定的金钱状况、家庭状况、社会地位，任何人都可能会有中年危机。

做 CRUD 而已，3-5 年的也够用了

我公司正在招做 CRUD 的，面了十来个 3-5 年的了，没一个能用的。
个人感觉 3-5 年跟 8 年以上还是区别蛮大的。

如果甲方一开始就有意要你的源码后续自己开发，他会在谈合同时就提的，没人愿意冒风险去反编译 class 。
如果没要源码，那就是没打算换人接手，或者要换就一整套都换掉。

@BenX 27 寸的 4K 都达不到视网膜级别，30 以上的看着更难受。

当年就是因为这个卸载的搜狗