我还觉得自己的嘴部肌肉很僵硬，经常由于语速太快而嘴跟不上，导致说话不清楚，当我刻意想控制语速，就会结巴。

结巴很多年了，因为平时语速太多，在某些场景下会导致结巴
1 紧张或者着急的时候
2 跟人讨论事情，当脑子思考很快，会导致嘴巴跟不上

Intel 的 cpu 和 gpu 都太差了，带 4k 都很勉强。
Java 开发 16g 内存是够的。

AOC 卢瓦尔 4k 65w type-c

小米 12x

怎么对接业务数据？

很多人不自知，所以要提前进行心理建设。每半年进行一次绩效评定，对每位成员进行优点鼓励和不足建议。你该做的都做了，该帮的都帮了，能不能行那就看他自己了。当公司要辞退他的时候，他的心里应该提前感觉到了。

git 是摆设吗？

32g 12 寸 macbookair 会是我的 java 神器，如果有的话。

个人看法：你与别人讨论一个问题的时候，不应该说你的观点来自哪本书， 因为这没有任何说服力。
看书是为了让你看到更多的想法，成为自己的思想，为自己所用。所以，你与别人讨论时，应该把你的逻辑用严谨的话表达出来，才能说服人。说某个观点来自某本书没有任何意义。

是两只手都关节炎吗？
我曾经使用 mac 的触控板，导致右手关节炎。所以就再也不用了。

两个方案都各有优缺点，很多大厂使用的是方案 1 ，我现在使用的是方案 2 。

方案 2 优点
无论团队大小, 既然是微服务, 那肯定会为每个服务指定负责人, 而不会交错负责.
1. 每个人只需要关注自己负责的服务的代码.
2. 小团队,可以避免团队内有人随意修改他人负责的代码. 大团队,只开负责的代码仓库的权限.
3. IDEA 中只打开自己负责的代码, 搜索代码什么的都很方便.
4. CI/CD 方便
5. 版本管理方便, 减少代码冲突.

方案 2 缺点
1. 需要搭建 maven 私仓, 对所有的公共技术模块进行严格的版本管理, 在 base-pom 中对版本进行统一管理.
2. 降低开发者维护公共技术模块的意愿. 因为修改公共模块,哪怕只修改一行代码,都需要升级版本, 然后对很多 git 仓库进行代码提交. 服务发布前,还要把相关模块的版本从 SNAPSHOT 改为 RELEASE, 有点麻烦.

方案 2 的优点就是方案 1 的缺点.整体来看,我觉得方案 2 的优点更多更好.

Java 项目 在用 maven ，没有更换 gradle 的任何理由

当一个个体引起众怒的时候，大众不会去细究它哪些是好那些是坏，只管打倒它。我是支持这种行为的，矫枉必须过正。
辩证与客观只能存在于小团体。

如果还没有找到原因，那就用笨方法：控制变量，一个个尝试。
列出所有可能导致该问题的原因， 每次改变一个，观察执行结果。

既然用微服务了，那就可以异构微服务。
迁移原则是：仅在必要时或极低成本时迁移，C 代码以保留为主，迁移为辅。

* 在 nodejs 前再加一层，用于兼容微服务间调用方式，如 http 。
* 老代码以保留为主，分离为辅。
* 如果 1 个模块功能已经比较完善，那就不必要用 java 重写，直接 http 调用
* 如果 1 个模块在未来需要大量开发，那就用 java 开新服务。这样 1 个模块既有 java 代码，也有 c 代码。这个模块内部，需要功能间方法调用，如果功能简单，则可以直接以 java 重写，如果功能复杂，则 http 调用。


Dubbo 支持异构微服务，其他的技术栈你可以再找找。

Oppo k10

红米 k20pro 小屏+全面屏，没有可代替的新机，准备一直用下去