又要“牛逼”又要“全面”，两者很难兼得啊。

要知道毕业设计的目的不是为了让你搞出一个多么牛逼、有多么强的适用性的实际产品出来，而是考察你在校期间学习的专业知识能否学为所用。所以，我觉得你在技术选型的时候，不要想着现在业界都有那些牛逼的技术，然后填鸭式地临阵磨枪，并试图把这些技术都塞到自己的项目里。相反，你要梳理一下你已经掌握的知识和技术，并从中找到自己的强项。接着，分析自己能利用这些强项做到什么，有哪些创新的地方，突破了哪些壁垒，等等。然后，专注于某一点去为你的毕业设计选题。

拿我自己的本科毕业设计为例，我做的是一个基于深度强化学习的综合能源微网优化调度。这个题目是老师选的（学渣没人权）。由于我不擅长深度学习这一领域，所以我将重点集中在了优化调度的载体上，而不是深度学习模型的构建、调参和训练上。最终，虽然训练出来的 DQN 模型不是很理想（事实上传统数学方法更优），但是我成功地将其集成到 麒麟 970 平台上，利用 麒麟 970 的 NPU 加速神经网络的运算，从而使得在嵌入式平台上实时地应用深度强化学习的手段对综合能源微网进行优化调度变得可行。最终，我的毕业设计取得了还算理想的分数。至于优化 DQN 的工作，后来老师将其交给了一些擅长深度学习领域的研究生去继续进行。

希望我的见解可以帮到你

问下前辈，你是如何读 Qt 的？是直接读 Q T，还是读 “cute”？

不只是 commit message 和分支命名规范。我司的代码仓库有 PR 钩子，引入 coverity，对提交的代码用 SonarQube 进行静态分析，不符合代码质量规则的 PR 将无法合并

同事刚才还在和支付宝那边的接口人同步这个问题 😂

最近身体不适，就不去了。以后有缘再会 😂

初三学生都开始看 SICP 了，后生可畏啊（如果看得懂的话）

你的 TreeMap 构造函数中的 Comparator 实现有问题。参考 Java 官方文档：

The ordering imposed by a comparator c on a set of elements S is said to be consistent with equals if and only if c.compare(e1, e2)==0 has the same boolean value as e1.equals(e2) for every e1 and e2 in S.

然而在你的 Comparator 中，当 o1.equals(o2) == false（但 map.get(o1) - map.get(o2) == 0 时），有可能返回 0。

对于这种情况，官方文档是这样解释的：

Caution should be exercised when using a comparator capable of imposing an ordering inconsistent with equals to order a sorted set (or sorted map). Suppose a sorted set (or sorted map) with an explicit comparator c is used with elements (or keys) drawn from a set S. If the ordering imposed by c on S is inconsistent with equals, the sorted set (or sorted map) will behave "strangely." In particular the sorted set (or sorted map) will violate the general contract for set (or map), which is defined in terms of equals.

这下问题的原因就很明显了。对于 TreeMap 而言，键是不能重复的，当键重复时，put() 方法会将原有的值用新值替换。而键是否重复是通过对 put() 方法里传入的键以及容器中的存量元素的键应用 Comparator 进行判断的（而不是 equals() 方法）。参考 JDK 源码：

Comparator<? super K> cpr = comparator;
if (cpr != null) {
    do {
        parent = t;
        cmp = cpr.compare(key, t.key);
        if (cmp < 0)
            t = t.left;
        else if (cmp > 0)
            t = t.right;
        else
            return t.setValue(value);
    } while (t != null);
}

这就可能导致重复键的插入。

我们值班是没钱的

值班时段虽然不用在工位待着，但是不管你在干啥，都要保证一旦出了问题，接到电话后可以第一时间连接到公司网络跟进并及时解决问题

至于带薪的那种加班，只有 SRE 能申请到。RD 的话，不管你的项目排期有多紧都是申请不来的。带薪调休都申请不来。只能自愿加班 😂

这样的需求在绝大多数场景下都不是很适用。业务逻辑应该和测试逻辑分开的，比如在多数 java 的 web 项目中，业务代码都放在 main 目录下，测试都放在 test 目录下。如果通过注解来辅助测试，业务代码中会不可避免的多出来很多测试逻辑。试想一下每个 service 方法上面都有 @MockWith(...) @AssertThat(...) 之类的东西，代码的可读性会下降多少。