首先考虑的问题是，不带 html 的内容是不是必须存，评判标准是：有没有根据它检索的需求。如果是必须存那就没 2 的什么事了。如果不是必须存，那 1 跟 2 在黑盒功能上是没区别的，用哪个就看你用哪个更方便。

简历放 github 可能有两个目的：一，我在编程行业是小有名气的人（名气很高的人通常也没必要再挂 Github 链接，甚至简历都不要，所以必定是有点名气但又不高的），你们可以放心用；二，你可以看看我的代码，评估以下我跟团队是否能匹配。目的一通常用于个人外包或自由职业者，很少用于求职，因为求职是有笔试或面试过程的，小有名气基本没啥用。求职过程通常是用于目的二，那这是要给人看代码的，是给将来可能的同事看的，不是给 HR 看的。

综上，真正放 github 的简历，是让筛选出来后做深入考核用的，不是让你筛选用的。你要用 Github 链接情况来筛选简历，那你就真得只能筛选出假的。

POST/DELETE 通常不会 404 ，因为资源添加通常不会产生不存在，删除资源则因为幂等性允许资源不存在。但是，你 POST/DELETE 一个不存在的资源类型，比如说你在教务系统里面添加苹果（简单说就是后台压根没有这个 URI ），那就该 404 了。404 代表的是 URL/URI 不存在，不一定总是代表资源不存在。

我觉得，这里面应该先别讨论 POST 能不能 404 ，URI 存在但资源不存在的 GET 请求，是返回 404 , 还是 200 。

从技术上来说，用户这种被绝大部分其他业务依赖的东西，删除要比创建难很多。但是这不意味着注销比注册难，因为从业务上讲，要想注册就必须首先考虑怎么注销，所以注册的难度包含注销的难度。这方面银行卡就是个典型，办卡绝对比销卡难。

凡是注册难度小于注销难度的，都要当成贼船看待。上船容易下船难，能不上就不上。如果真上了，那就别想下船了，你只能跳船。

要先纠正两个盲区：是先有 IT 行业，后有互联网行业，不是反过来；传统 IT 部门是管理部门，不是技术部门。以前 IT 部门都是吸收转向管理的技术大佬，用来管理和协调乙方 /软件供应商。现在廉价（并且能随意无损开出）的码农多了，IT 部门就动了外包转自研的想法。不过外包永远比自研便宜，所以离真正的自研还远着呢。

楼主啥都没说清楚，删除的是啥都不知道，下面就一堆要小手段禁用 Windows Defender （正常禁用 Windows Defender 压根不用任何小手段，任意安装一个其他防病毒软件即可）。这帮人碰见小偷估计也是让人先弄走警察。

当你回到全 ORM 的基础上的时候，才会有 User 是关联 Department ，还是关联 departmentId 的选择。然而这个并没有选择，对象层面没有外键关联，只能是 User 关联 Department ，User.departmentId 只是 User 的一个属性，不是 Department 的外键。

这个实际上能做得选择是，User 要不要关联 Department ，这个选择取决于业务和性能，而不是技术细节。业务上 User 跟 Department 是必须在一个事务当中的，那么就得关联。业务上二者没有紧密的事务结合，或者说虽然是紧密结合但是因为性能不得不放弃事务一致性而改为最终一致性，那么就不能关联，这时候可能需要 User.departmentId 来维持业务（而非技术）上的弱关联关系。

带关联的 Entity 是纯对象层面的设计，不用 hibernate 这种全 ORM ，你能设计个蛋蛋。你下面的关联问题，光用 mybatis 压根就不会有。光用 mybatis 你压根设计不出“User 关联 Department”。当你基于 mybatis 加了好多框架层代码把 “User 关联 Department” 设计出来的时候，那么恭喜你，你造了个新的 Hibernate 。

既然 DDD 了，就别搞微信这么搓的交流工具了。IM 工具不适合技术性交流，要找社区交流工具。

个人一点拙见，DDD 最难的不是技术部分（战略设计也是技术部分），而是如何让需求跟开发形成通用语言。要是还用界面原型、效果图、甚至领导的想法来定义需求，那是用不成 DDD 的。最低的极限也得是拿数据库设计得概要模型或者逻辑模型当主要需求（界面原型只做辅助）。

同步方法才能直接返回最终值，异步方法只能返回 promise 或者类似机制，你要想让异步方法产生返回最终值的效果，那就要使用“异步回同步”处理（起的名字可能不对）。

这个“异步回同步”处理，对于多线程语言或者允许当前线程阻塞的环境来说，可以给 promise 设计个带 wait/await 的方法，调用它就能立刻（在当前线程）同步阻塞的等待返回值，例如 Java 的 java.util.concurrent.Future#get() 。而在 async/await 设计理念下，你可以通过 await 调用异步方法来获取返回值，就是你代码里面的 return await Axios.request(options) ，但是这个调用必须是在 async 下的，因为要不是在 async 下那么你就是在主线程中，这时候是不允许阻塞的。

国内还是别搞代码规范了。一管就过——一刀切的代码风格会严重挤占正常的开发时间甚至还会制造为了让工具零报错而产生的诡异代码。一松就乱——偶尔不检查一次后面就只能都不检查了。

代码风格跟代码一样，要想一直保持高质量，需要持续改善，需要：
一，定义一个强制性但最低限度的基础代码风格用于自动化格式，这个通常是要 IDE 插件自动格式化，在 maven/gradle 构建阶段自动格式化会导致开发阶段没法所见即所得。
二，在代码合并阶段，除了自动化检查代码格式工具（ Git hook 、maven/gradle checkstyle 插件）外，还要附加人工评审，对于不适合让工具自动处理的格式化，进行人工格式化。
三，每隔一段时间，停止所有开发，进行一次集中的总体代码优化。

黑客或者感兴趣的开发者才会研究如何绕过，用户最好的选择是扔了买其他的。

已经开的发票还能改，税务局这么好说话的吗

不使用字段上的 @Autowired 的唯一好处是，去掉 Spring 后你仍然可以手动注入。这在 Spring 几乎不可能被去掉的前提下，属于过度设计。而且还是很严重那种，因为替代方式都有问题：
隐式构造器依赖注入（就是说得 private final + @RequiredArgsConstructor ）需要有强的团队约定否则就严重影响代码可读性。
构造器注入容易出问题，而且参数多了会影响可读性
Setter 注入器因为 lombok 尚不能很好的支持，没法用。

把主页和新标签页，设置为空白页（ about:blank ）,不让设置就换浏览器。

严格意义上来说，swagger 的接口定义是要自己写 yaml ，跟你后端定义的对象无关的。能够自动根据 Java 类生成 Swagger 接口定义的，是 Springfox-swagger 插件。而这个插件，是允许你通过注解的方式用自己的定义覆盖默认定于一的，所以及时使用 Map 仍然能够不影响 swagger 这类的接口定义，只是需要多做一些注解 /注释性的工作。

当然，用 Map 不影响，不是鼓励 Map ，首选仍然是特定的类。楼主这里推荐用 Map ，是因为它返回内容当中的字段是不固定的，有可能还是前端要啥后端返回啥，这时候没法定义特定的类了（或者说定义的类就用一次，太浪费），用 Map + 注释 /注解会更省事。

这个警告的原因，不是强制类型转换，而是 List 到 List<String> 加泛型。

如果你需要的是 List 而不是 List<String> 那么用 List<?> 或 List<Object> 代替 List<String>。

如果你需要的就是 List<String> ，并且确定返回的就是 List<String>，那么 @SuppressWarnings("unchecked") 就是最优解。

如果你不能 100% 确定返回的是 List<String>，那么还得用 List<?> 或 List<Object> 接受变量，然后 if (get(i) instanceof String){...} else {...}