感觉先把 Core Java 学好最重要吧。

明年我也加入这里 10 年了，希望到时候能有点什么可以回忆的东西吧

Go ，因为没有泛型，符合原汁原味的 OOP 思想。

DDD 和六边形那套东西，函数式编程的概念反而没什么难的

「小红书」和「有趣的计算机」这两个词居然可以在同一句话里出现吗。

扫了一眼基本上也都是些大企业老板、富哥富姐或者产品经理之类的，很好奇这些 title 跟「有趣的计算机」有什么联系？

要看彩虹屁我还不如去推特看马斯克喷人去。

年化 5%的方法，大概你标题里面已经给出来了。

头一回见到把类型、参数名和注释垂直对齐的格式，这种格式要是稍微改个参数名感觉要维护起来会很难受

能不返回 None 就不要返回 None

首先，这不叫防御性编程

@UncleCAT4 是指大四大五啦，法国的大学学制是五年的。


@roundRobin 主要也是看团队里面并没有把 PR 细化到这个地步，一般一个 issue 就是一个 PR ，如果大家的 commit 和 PR 都很细的话我肯定是跟着他们做的。GitHub 上的个人项目倒是不会做那么细就是……


@Contextualist 好建议，我倒是还没太熟悉 rebase 的用法，感谢提醒。


@tolbkni 注释我感觉问题在于后面改来改去的很容易就会丢掉上下文……


@GeruzoniAnsasu 示例这个确实不太好，不过一方面也有看团队里一个 PR 也就几个 commit ，我自然会倾向于避免上来就推几十个 commit 的巨型 PR ，所以也会有想要把 B 「虽然是不同的事情但在功能上相互联系的几件事组合在一起」的倾向，尤其是发了两次包含连续四五个 Refactor 的 PR 之后。


@Scarb 这个模版倒是不错，有时候我感觉我也有点像在往这方面靠。


@janus77 会的，会先看 git blame 找出 commit 的历史记录，问题是一般来说别人都是简单的一句话甚至没有提到他的代码意图，所以我才感觉如果有个 commit message 会清晰很多。

@roundRobin 对一个 PR 来说，这个 algorithm 可能只是其中一小部分，issue 里面提到的东西经常需要改蛮多东西的，而且产品那边也可能也会反复需求。

不知道这玩意哪里改革生产力了，降本增笑是从古代就有的原始经济学，也是这片土地如此贫瘠的原因之一。

不去做大蛋糕只想着更高效率的切蛋糕，这不叫改革，叫倒退。

2000 入国军还挺好的吧，我的评价是 2003 年入伊拉克军队。

你都有自己的答案了还有啥提问的必要吗？

光怼 rm 没用吧，不安全的命令也不是只有 rm 。mv 也能把文件和文件夹搞飞。

没有线程哪来的协程？

或者 op 想说的是手写线程池动不动开个新线程那种做法？