“痛点” 是个很有意思的词，他通常只会出现在向 GOV 要（骗）钱的申报文档里。

你发在了 mysql 区，而 mysql 分页只需要简单的在最外层末尾加上 limit first,max 即可。这你都痛苦，那遇见 oracle 的分页你得自杀。

除非你是微软的机器，或者专用的游戏机器，否则电脑开机后的第一部，是通过 设置—恢复—重置 ，后面还要选择“从网络下载”和完全格盘，先把系统重新装一遍。

有一个基准原则：后面正在排队的人，他看到的等待人数，只能不动或者减少，不能增加。

如果你排号要是有“等待人数”这个功能，那么过号只能完全作废，不能再插回来。这种情况下你不能再管过号后怎么处理，而是怎么优化过号，或者说怎么排队的逻辑。比如说，4 号没有立刻响应的话就让后面的依次顶上，但是 4 号还没过号（排队队列也没变化），10 分钟后 4 号还没响应再让 4 号过号，然后排队队列往后移动（但是因为前面已经有人顶国区了队列会一次性移动好几个）。

如果你排号没有“等待人数”这个功能，那就看现场人员的发挥了。

IDEA 的编译真是个令人头疼的东西，开了自动构建 CPU 扛不住，不开重构的时候要吃屎——大量文件的编译错误它不报。

NFC 跟 原生谷歌犯冲，你必须放弃一个。NFC 普通功能没啥用，像支付、公交卡这样的高级功能，都是要服务器认证的，所以你想用这个就必须用国区的系统，而国区系统，是不可能有原生谷歌的。国区系统的 google play 服务只是为了让部分依赖这服务的游戏能跑起来，不是完整的 GMS 框架，你要像用原生谷歌就得刷成外区系统。刷同厂商外区系统不用 root ，不掉保修，比如三星刷港版，一架刷氧，但是换了外区 NFC 高级功能就没法用了。

首先考虑的问题是，不带 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 插件）外，还要附加人工评审，对于不适合让工具自动处理的格式化，进行人工格式化。
三，每隔一段时间，停止所有开发，进行一次集中的总体代码优化。