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 想说的是手写线程池动不动开个新线程那种做法？

「做这块的没几个人」。

那感觉还是走吧，是他们有求于你，还对你这样，你去了只会给他们软柿子的印象以后有的你受。

反过来说，你的竞争力应该不弱，竞争对手也不多，也许短期内找不到下家但总能找到。

再加上你说的外包污点问题，我觉得走人是最佳解。

欢迎来到后 AI 时代。