V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  sy20030260  ›  全部回复第 1 页 / 共 4 页
回复总数  80
1  2  3  4  
结合公司的招聘情况看了,一般情况遇到这种程度的基础可以 pass 了。但如果短期实在缺干活的人,或者公司能开出的薪资水平本来就比较一般,那还可以试试挖掘面试者其他方面。例如稍微引导一下面试者,如果他能说出快排的基本思路,能通过代码写出基本 bug free 的版本,而且代码风格还不错,那至少说明思维和代码能力不错,属于能实际上手干活的那类人,那还可以往这方面继续考察考察。毕竟面试过程看的不是某个单一问题的回答,而是不同方面能力的综合考察和综合判断
132 天前
回复了 James369 创建的主题 程序员 现在搭一个小的推荐系统麻烦吗?
这个“小”具体是多“小”啊。上推荐系统的话,最后上线得能验证效果,那就得先有简单的 AB Test 吧。要 AB Test 的话,就得有简单的数据平台,简单的埋点 /离线数仓 /取数 /报表不能少吧。而且 AB Test 要能跑起来样本量不能太少吧,说明产品已经比较稳定且具备一定用户规模了。

到这个程度其实已经过滤掉大部分小公司了,这种公司一般都有一个小型的 BI 或算法团队了。这个时候搞个推荐系统应该比较水到渠成了,毕竟业界都有相对成熟的方案,丢给算法团队搞就是了,应该轮不到 OP 来提这个问题吧。如果确实还有这种问题,可能得检查下算法团队是不是有水分了(逃
151 天前
回复了 cxytz01 创建的主题 程序员 即时通信 IM 端到端加密真的可以做到吗?
虽然但是,这里有个概念问题。

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

举个最极端的例子:即使是使用 Signal 通过当面交换公钥,但是用户在实际使用中使用了不受信任的物理设备,导致密钥直接在物理层面泄露了,这也会导致信息泄露发生。但这并不能说明 Signal 提供的端到端加密是假的或不完备的...
@baleeny 嗯,主要还是看组合课程在后台怎么上架,以及在 C 端怎么展示 /怎么检索。如果组合课程的上架逻辑 /展示逻辑 /检索逻辑等都和单课程商品的类似,那把它设计成一个特殊 SPU 是合适的,这样可以最大程度复用原有逻辑;反过来如果这些逻辑都不太一样,就没必要强行抽象成一个 SPU 了,把这个逻辑解耦反而更干净一点。反正只要能满足价格和库存逻辑上的需求,其他展示啥的都是次要问题了,选择相对舒服和干净的实现方式即可
@baleeny 主要看组合课程是否是独立计算库存,以及后台的上架逻辑是怎样的。看你说组合课程价格还不一样,猜测组合课程后台是一套独立的上架流程,然后库存也是独立的?如果都是独立的那就比较简单,可以把组合课程当作一种特殊 SPU 处理就行。如果库存不是独立的只是价格不一样,建议做到下单逻辑那边好一点,不要做在商品和 SKU 这边。大概可以理解成组合下单的价格优惠逻辑,实际下单还是多个 SPU ,识别到固定的 SPU 组合就做个减价就行。不过核心还是得看组合课程的后台上架逻辑是怎样的
如果是商品的话核心是价格和库存吧。描述得不太清楚,但我理解产品形态应该类似一个课程商城,点击某个课程进入详情页之后可以选择上课地点、时间、年龄然后匹配不同的价格下单?

如果是这样直接参考电商商品的数据库设计,一个课程是一个 SPU ,上课地点 /时间 /年龄等相当于商品属性,每一个固定商品属性排列组合对应一个 SKU ,不同 SKU 对应不同价格、库存
160 天前
回复了 Jaeden 创建的主题 问与答 问:大家读书时主要是那种阅读媒介呢?
商业 /社科畅销书:微信读书
专业向的、技术书籍等需要边看边圈圈画画:Zlibrary 下载到 iPad 看
160 天前
回复了 skywind3000 创建的主题 Vim 分享篇文章:为什么我会使用 Vim ?
不否认 Vim 在拓展性上确实有优势,但是很好奇除了自己折腾的场景除外,在真正生产场景中 Vim 的高拓展性到底能发挥多少价值?我是 JB 系重度使用者和 VsCode 轻度使用者,在现实生产场景中用到 JB 的功能甚至都占不到它完整功能集的 20%。JB 的功能已经完全超出我在生产场景中的需求,偶尔一些拓展性借助插件也能实现。我真的不需要那么灵活的拓展性,而且我遇见过的程序员他们大多也不需要

拓展性高,用统一的工具解决所有问题当然很爽,但是为了这种爽付出的代价是:开箱即用的产品体验、易用性更高的图形化界面、商用级别支持的 IDE 配套服务等等。为了多 10% 的高拓展性却要牺牲 90% 常用场景下的产品体验,这个边际成本对于大多数普通用户来说也实在忒高了...
162 天前
回复了 foufoufm 创建的主题 Markdown [提问]Obsidian 如何支持笔记的自定义排序
建立一个索引笔记,在索引笔记里链接其他笔记,然后把索引笔记 pin 住就行了。如果懒得每次手动修改索引笔记,可以进阶一点,结合 dataview ,加个 rank 字段然后按 rank 排序
在零单测的国内大厂待过,后面出来创业公司严格单测也搞过,深有体会。

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

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

你为了快点上线不写单测,那我还干嘛还吃力不讨好地维护单测呢?最后大家只能被动地选择一种对团队收益更低的方案。说白了也是一种 KPI 导向下的内卷形式
2022 年了,必须是 [Matter]( https://hq.getmatter.app/)
169 天前
回复了 mitu9527 创建的主题 程序员 数据库与缓存的一致性问题的两个疑问
@mitu9527 这个问题当然是存在的,一个更「完善」的方案当然也是值得追求的。但可能我没表达清楚,核心问题在于:没有具体业务场景作为前提,是没法衡量哪种方案更完善的。方案 A 可能在某场景下是完善的,但在其他场景下可能就远远不如方案 B ,而且甚至起到反效果。这种实际业务中是很常见的。

啥叫前提啊?你读取一个数,前提是你要知道进制;你问现在几点,前提是你得告诉我啥时区;你求个坐标,前提是你得知道参考坐标系。不给你参考坐标系你会求坐标吗,不会的话就别绕开业务场景谈什么更完善的技术方案
169 天前
回复了 mitu9527 创建的主题 程序员 数据库与缓存的一致性问题的两个疑问
关乎业务代码的问题,脱离了具体业务场景来做技术选型,无异于纸上谈兵

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

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

在使用 cache-aside 的情况下,还需要纠结两种队列用法之间细微差异的业务场景,可能是我见识太少,实在没见过。如果是真实业务场景的话还希望 OP 分享下,让我也长长见识
169 天前
回复了 voidmnwzp 创建的主题 程序员 大家公司的项目代码会写的尽善尽美吗
性能是一方面,代码风格则是另外一方面,这是两个问题啊~

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

反而,我遇到的那些写一手烂代码的程序员,大多数并不是不想写好代码,而是没能力把代码写好。或者由于缺乏经验和方法论,写一段风格良好的代码得绞尽脑汁、反复修改,久而久之就放弃了。懒只是个借口罢了~
169 天前
回复了 voidmnwzp 创建的主题 程序员 大家公司的项目代码会写的尽善尽美吗
性能是一方面,代码风格是一方面,这是俩问题啊~
171 天前
回复了 sunmoon1983 创建的主题 MySQL 求一个数据表设计的思路!
如果是 RT 敏感且高 QPS 的业务场景,还是多建一张表才是王道,直白简单易排查易维护,Keep It Simple Stupid
请问这个网站主题是有对应的 obsidian 主题吗,求分享
@ecnelises 涨知识了。但是简单看了下,感觉风格上和 Rust 区别还挺大的,如果说 Rust 是 70% 的 OOP + 30% 的 Functional Programming 的话,OCaml 更像是 70%的 FP + 30% 的 OOP ?
@libook 感谢提醒,忘记最重要的一点了...必须强类型
@kera0a 感谢提醒,主要是服务端
@libook @yourmoonlight 区块链一直都不止是一个纯粹的技术问题。比特币背后是有博弈学理论作为基础的,而博弈学同时也是经济学 /社会学的底层课题之一。可以说区块链本身就是个计算机科学 /密码学 /经济学 /社会学的交叉课题
1  2  3  4  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   实用小工具   ·   1286 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 57ms · UTC 15:49 · PVG 23:49 · LAX 07:49 · JFK 10:49
Developed with CodeLauncher
♥ Do have faith in what you're doing.