@hahaFck 如果设计成 user 表中加 department_id ，表示 user 对 department 有依赖，显然，业务上他们之间并不是这种关系。而且一个 user 可能会对应多个 department 。

至于你说的 organization ，和 user 不是直接关系，而是通过 department 间接关联，那么应该是 organization_department_relational 。

实体应该是独立的，不应该直接关联另一个实体，不同实体应该划分好边界，也就是 domain 的概念，通过关联表间接关联。

> user
> department
> user_department_relational

提醒作用，不使用 IDE 情况下，可以通过 override 就可以知道是重写方法。
如果父类删掉了某个方法，子类 override 修饰的方法编译时会报错。

反向操作....
正常应该是 jar 包发布后，保留对应版本的分支或者打 tag ，这样通过版本号可以找到 git history

我用 Go 也一样，有时候多提交几次就双 90% 了

涨幅不高就不要跳，继续找找。
工资不发就走仲裁，不可能输。

树高会影响 IO 次数，用 B+Tree 树就是这个原因，比 B-Tree 更矮更胖。

数据页是从磁盘加载到内存中的，如果发现数据不在当前页，可能在下一页，才会去磁盘继续加载页。

如果我是新人，我希望 mentor 做点实际的事情，而不是给我人生建议或聊一些有的没的：
0. 给我一份文档，让我在本地把环境搭建起来。（ Go/Java/Python/IDE 等等）
1. 给我开通各种权限，说明注意事项。（ Git 仓库 /DevOps/测试库 /日志等等）
2. 给我需求文档和代码仓库，让我在本地先能运行项目，然后熟悉项目需求，熟悉代码提交规范。
3. 给我介绍公司常用技术栈，让我平时能够自己学习技术。
4. 带我参与需求评审，分给我一个模块，按项目组规范写设计方案和画图。
5. 参与我的技术评审，指出我方案中的问题，给出建议。
6. 参与设计稿 /测试用例 /前端评审，介绍需要对接的同事。
7. 按集团规范进行开发，帮我 review 代码，有问题的地方及时修改。
8. 与前端同事进行联调。
9. 带我熟悉 test/QA 测试流程，如何冒烟自测，如何发提测邮件，如何使用 JIRA/禅道 等，与测试同事沟通。
10. 带我熟悉 uat/pre/prod 发布流程，如何排查问题，如何提交 SQL 脚本，一些注意事项。

带新人是上面安排的工作，做好自己的工作就行，又不是带崽。新人遇到问题时你再教他，你要让他知道“遇到问题及时问”，而不是手把手教他，更不能让他自己憋着。

如果一段时间下来，他还是无法胜任工作，问心无愧解除合同。

当然，如果新人很尊敬你，那就是另一回事了。

管理是一篇文章一本书就能学会的吗？不应该去关注员工本人吗？

美名其曰培养员工，扪心自问一下，真的投入时间和精力了吗？发现每个员工优点和缺点吗？员工产出超出预期时有给奖励吗？员工犯错的时候一起承担责任了还是甩锅了？

大部分 leader 为了方便管理，就定了一堆规矩，让员工按着自己的方向发展，甚至让员工相互卷，自己却不愿意做出一丝丝改变，这根本不是管理，所以也别指望员工能真正的尊重你，尊重是相互的，不骂你就不错了。把平台当做自己的能力，出了公司啥都不是。

按我的理解，你只能在 xml 里判断 title 是否为 null 。因为 title 为 null 时，直接用 `where article.title like #{dto.title}` 肯定是有问题的。
mybatis 就是用于动态 SQL 的场景，而且，这个判断跟业务流程也没太大关系，只是说 title 字段是 ignorable 的，在注释中写清楚就行。

搭一个 sonar 扫描代码呗，配置一下规范，分数低于 90 分不允许发布

我买的无刻的，刚开始也不太习惯，用多了就好了。不喜欢用机械键盘写代码，怕吵到别人，写久了手酸。薄膜键盘和 macbook 自带的手感就更差了。
其实主要是有洁癖，不想让别人碰我的键盘，甚至领导看我的眼神都不一样了。
https://www.v2ex.com/i/21nO1NV3.jpeg

@awanganddong

我之前也做过类似的需求，基本思路差不多，对搜索接口做了一点优化：

1. 异步删除帖子：用户被封禁时，通过 MQ 发送一条包含用户 ID 的消息，然后消费者异步删除 es 中的 docs
2. 搜索接口优化：搜索到结果后，可能存在某一个帖子还没来得及删，所以需要判断用户是否被封禁（可以通过查数据库、查用户缓存、bitmap 等方式）。如果用户被封禁，将该帖子数据简化，并标记为已封禁，然后返回给客户端。让客户端展示一个被封禁的文案（也可以直接过滤掉该条帖子，看具体需求）

由于 es 的 doc 是不可变的，所以最好不要做更新处理。更新操作实际上是通过一个.del 文件将原来的 doc 标记为逻辑删除，然后再新建一个 doc 。

真是令人唏嘘

帮顶（可惜没有后端）

没示例代码吗？应该是切面实现的问题

晒干了沉默

1. 前端维护一份 code -> description 的映射。缺点：需求变动可能要改代码重新发布。
2. 后端返回列表结果的时候把 description 直接带上。缺点：报文变大。
3. 后端提供一个查询接口，返回 code -> description 的映射，前端缓存。缺点：增加前端复杂度。

@awanganddong 是要在搜索结果中把被封的用户的帖子都过滤掉吗？