结合公司的招聘情况看了，一般情况遇到这种程度的基础可以 pass 了。但如果短期实在缺干活的人，或者公司能开出的薪资水平本来就比较一般，那还可以试试挖掘面试者其他方面。例如稍微引导一下面试者，如果他能说出快排的基本思路，能通过代码写出基本 bug free 的版本，而且代码风格还不错，那至少说明思维和代码能力不错，属于能实际上手干活的那类人，那还可以往这方面继续考察考察。毕竟面试过程看的不是某个单一问题的回答，而是不同方面能力的综合考察和综合判断

这个“小”具体是多“小”啊。上推荐系统的话，最后上线得能验证效果，那就得先有简单的 AB Test 吧。要 AB Test 的话，就得有简单的数据平台，简单的埋点 /离线数仓 /取数 /报表不能少吧。而且 AB Test 要能跑起来样本量不能太少吧，说明产品已经比较稳定且具备一定用户规模了。

到这个程度其实已经过滤掉大部分小公司了，这种公司一般都有一个小型的 BI 或算法团队了。这个时候搞个推荐系统应该比较水到渠成了，毕竟业界都有相对成熟的方案，丢给算法团队搞就是了，应该轮不到 OP 来提这个问题吧。如果确实还有这种问题，可能得检查下算法团队是不是有水分了（逃

虽然但是，这里有个概念问题。

端到端加密和可信中间人是两个不同的问题。密钥不泄漏 or 不被伪造是端到端加密的“预设条件”，而非其“目标问题”呀。在满足密钥不泄露的前提下，可以做到除了发送端和接收端之外的其他节点无法获取明文信息，就是完备的端到端加密了

举个最极端的例子：即使是使用 Signal 通过当面交换公钥，但是用户在实际使用中使用了不受信任的物理设备，导致密钥直接在物理层面泄露了，这也会导致信息泄露发生。但这并不能说明 Signal 提供的端到端加密是假的或不完备的...

@baleeny 嗯，主要还是看组合课程在后台怎么上架，以及在 C 端怎么展示 /怎么检索。如果组合课程的上架逻辑 /展示逻辑 /检索逻辑等都和单课程商品的类似，那把它设计成一个特殊 SPU 是合适的，这样可以最大程度复用原有逻辑；反过来如果这些逻辑都不太一样，就没必要强行抽象成一个 SPU 了，把这个逻辑解耦反而更干净一点。反正只要能满足价格和库存逻辑上的需求，其他展示啥的都是次要问题了，选择相对舒服和干净的实现方式即可

@baleeny 主要看组合课程是否是独立计算库存，以及后台的上架逻辑是怎样的。看你说组合课程价格还不一样，猜测组合课程后台是一套独立的上架流程，然后库存也是独立的？如果都是独立的那就比较简单，可以把组合课程当作一种特殊 SPU 处理就行。如果库存不是独立的只是价格不一样，建议做到下单逻辑那边好一点，不要做在商品和 SKU 这边。大概可以理解成组合下单的价格优惠逻辑，实际下单还是多个 SPU ，识别到固定的 SPU 组合就做个减价就行。不过核心还是得看组合课程的后台上架逻辑是怎样的

如果是商品的话核心是价格和库存吧。描述得不太清楚，但我理解产品形态应该类似一个课程商城，点击某个课程进入详情页之后可以选择上课地点、时间、年龄然后匹配不同的价格下单？

如果是这样直接参考电商商品的数据库设计，一个课程是一个 SPU ，上课地点 /时间 /年龄等相当于商品属性，每一个固定商品属性排列组合对应一个 SKU ，不同 SKU 对应不同价格、库存

商业 /社科畅销书：微信读书
专业向的、技术书籍等需要边看边圈圈画画：Zlibrary 下载到 iPad 看

不否认 Vim 在拓展性上确实有优势，但是很好奇除了自己折腾的场景除外，在真正生产场景中 Vim 的高拓展性到底能发挥多少价值？我是 JB 系重度使用者和 VsCode 轻度使用者，在现实生产场景中用到 JB 的功能甚至都占不到它完整功能集的 20%。JB 的功能已经完全超出我在生产场景中的需求，偶尔一些拓展性借助插件也能实现。我真的不需要那么灵活的拓展性，而且我遇见过的程序员他们大多也不需要

拓展性高，用统一的工具解决所有问题当然很爽，但是为了这种爽付出的代价是：开箱即用的产品体验、易用性更高的图形化界面、商用级别支持的 IDE 配套服务等等。为了多 10% 的高拓展性却要牺牲 90% 常用场景下的产品体验，这个边际成本对于大多数普通用户来说也实在忒高了...

建立一个索引笔记，在索引笔记里链接其他笔记，然后把索引笔记 pin 住就行了。如果懒得每次手动修改索引笔记，可以进阶一点，结合 dataview ，加个 rank 字段然后按 rank 排序

在零单测的国内大厂待过，后面出来创业公司严格单测也搞过，深有体会。

从整个团队的角度，写单测必然是正向收益的。写单测的时间成本真的没有大多数人想象中巨大，项目刚开始写单测可能会占用你 40%-50% 的时间，但随着单测数量变多，有越来越多支持单测的工具方法和示例代码，开发单测的时间会急剧缩短。多花一点时间写单测，省下的是未来大量重复排查、定位问题的时间，绝对的正向收益

但回归到现实中，在国内大厂搞单测覆盖的困境在于，如果和你协作的同事不写单测，只有你自己写，那这样的单测维护起来既困难，而且实际效益也极低。况且，单测终究是一项花费个人的时间精力，但是带来的收益更多却是团队收益的工作。所以可想而之，在国内这种 KPI 导向、排期倒挂的大环境下，没有人会愿意做这种牺牲小我成就团队的傻子

你为了快点上线不写单测，那我还干嘛还吃力不讨好地维护单测呢？最后大家只能被动地选择一种对团队收益更低的方案。说白了也是一种 KPI 导向下的内卷形式

2022 年了，必须是 [Matter]( https://hq.getmatter.app/)

@mitu9527 这个问题当然是存在的，一个更「完善」的方案当然也是值得追求的。但可能我没表达清楚，核心问题在于：没有具体业务场景作为前提，是没法衡量哪种方案更完善的。方案 A 可能在某场景下是完善的，但在其他场景下可能就远远不如方案 B ，而且甚至起到反效果。这种实际业务中是很常见的。

啥叫前提啊？你读取一个数，前提是你要知道进制；你问现在几点，前提是你得告诉我啥时区；你求个坐标，前提是你得知道参考坐标系。不给你参考坐标系你会求坐标吗，不会的话就别绕开业务场景谈什么更完善的技术方案

关乎业务代码的问题，脱离了具体业务场景来做技术选型，无异于纸上谈兵

回归实际业务场景：引入 cache 解决什么问题？引入 cache 之后期望穿透到 DB 的压力有多少？能否接受短时间内的数据不一致？可以的话最长能容忍多久的不一致？如果确实出现不一致会导致什么问题（用户体验下降 or 资损）...具体业务中还会有更多细节。不回答这些问题，实在无法做技术选型

在我遇到的大多数业务场景中，如果已经采用 cache-aside ，大多数情况下就是个逻辑简单、高并发、RT 敏感的读接口。这种业务场景对数据一致性并没有那么强的需求，设置个短一点的缓存过期时间就是了，甚至都不需要引入队列（徒增架构复杂度

在使用 cache-aside 的情况下，还需要纠结两种队列用法之间细微差异的业务场景，可能是我见识太少，实在没见过。如果是真实业务场景的话还希望 OP 分享下，让我也长长见识

性能是一方面，代码风格则是另外一方面，这是两个问题啊~

性能问题无所谓，能用就行，大不了先上线再优化；而代码风格方面：代码可读性，变量合理命名，避免重复代码等等...都是实实在在方便自己后续维护啊，对自己有好处的事有啥理由不做呢？

反而，我遇到的那些写一手烂代码的程序员，大多数并不是不想写好代码，而是没能力把代码写好。或者由于缺乏经验和方法论，写一段风格良好的代码得绞尽脑汁、反复修改，久而久之就放弃了。懒只是个借口罢了~

性能是一方面，代码风格是一方面，这是俩问题啊~

如果是 RT 敏感且高 QPS 的业务场景，还是多建一张表才是王道，直白简单易排查易维护，Keep It Simple Stupid

请问这个网站主题是有对应的 obsidian 主题吗，求分享

@ecnelises 涨知识了。但是简单看了下，感觉风格上和 Rust 区别还挺大的，如果说 Rust 是 70% 的 OOP + 30% 的 Functional Programming 的话，OCaml 更像是 70%的 FP + 30% 的 OOP ？

@libook 感谢提醒，忘记最重要的一点了...必须强类型
@kera0a 感谢提醒，主要是服务端