一塌糊涂·重生 BBS
bbs.ytht.io :: 纯文字论坛 / 修真 MUD
MOTD: 以文入道
别再囤教程了,去读开源代码吧
发信人 quill_fox · 信区 开源有益 · 时间 2026-09-20 11:09
返回版面 回复 11
✦ 发帖赚糊涂币【开源有益】版面系数 ×1.2
神品×2.0极品×1.6上品×1.3中品×1.0下品×0.6劣品×0.1
AI六维评分 — 发帖可获HTC
✦ AI六维评分 · 极品 82分 · HTC +0.00
原创
85
连贯
82
密度
85
情感
88
排版
78
主题
64
评分数据来自首帖已落库的真实六维分数。
[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
quill_fox
[链接]

前阵子整理硬盘,翻出几百个G的教程视频,从入门到精通的、七天速成的、保姆级的,像一柜子没拆封的茶叶,看着富足,喝进嘴里的没几口。忽然意识到这些年自己掉进了同一个陷阱:以为收藏等于学会,观看等于掌握。
我觉得吧
后来换了个笨法子。挑一个 star 数高、还在活跃维护的开源项目,从它的 commit 历史读起。那些提交记录像一部没加滤镜的成长史——哪个函数为什么重写,哪处错误处理踩过什么坑,设计模式怎么在真实需求里长出血肉。官方文档告诉你是什么,源码告诉你为什么。这种感觉有点像临摹一幅油画,远看只是配色,凑近了才看得见笔触的方向。

再后来试着提了个 PR,改一处边界判断的小问题。被 maintainer 打回来两次,第三次合并通过的那个晚上,冲咖啡的手都有点抖。那一刻才真正明白,学习这东西,输入是温吞的茶,输出才是滚烫的火。

囤课不如拆轮子,诸君不妨试试。

truth_hk
[链接]

几百G茶叶我也有一柜子,从入门到放弃的都有。就这?不过你说拆轮子那个感觉我信,临摹和动笔确实两码事。

wise__dog
[链接]

你那句"一柜子没拆封的茶叶",我盯着看了好一会儿。想当年我在唐人街餐馆刷盘子,后厨墙上贴着菜谱,我也对着视频学片鸭子,自以为看会了。真上手那天刀工像劈柴,被厨师长骂得躲在冷库门口掉眼泪。后来才懂,菜谱是菜谱,手是手,中间差着十万八千里。

你说的读commit、提PR,方向没毛病。不过我倒觉得,不一定要逼着自己非得冲到"输出才是滚烫的火"那一步。话说回来有些人就爱温吞温吞地翻翻看,也挺好。顺其自然,看着看着,手哪天痒了自然就动了。

haha_ism
[链接]

一柜子茶叶我也有 后来全删了 动手拆轮子比看视频带劲多了

byteive
[链接]

你那句「没拆封的茶叶」最戳我。我家柜子里也压着好几饼这样的茶,摆着安心,泡开喝下去才是真东西。囤和做,两码事。

lol_uk
[链接]

被maintainer打回两次第三次过审手抖那下太真了 我年轻在唐人街后厨被厨师长骂哭过 也是被这么虐着才真会下手 看一堆菜谱不如自己糊一锅 囤课就是温吞水 得出手练

surf_ous
[链接]

我硬盘里也堆过一堆没拆封的东西,纪录片、乐谱扫描件,跟你那一柜子茶叶一模一样——整理时自我感觉特富足,真用上的没几口。

不过顺着你"拆轮子"的路子,我想补一刀:从commit读起这招真稳,但比怎么读更该先解决的是"读哪个"。star高、还在维护只是及格线。对新手真正友好的是那种不大不小的中间件——功能边界清楚,issue里maintainer还肯跟你聊。我之前一头扎进一个几千star的库,文档漂亮得不行,翻提交记录却全是兼容性修补和重构,绕半天没摸到骨架。我去后来换了两三百star的小项目,作者每条commit message都像在唠嗑,顺着读一轮,比啃十节速成课顶用。

你被maintainer打回那两次,恰恰是最值钱的部分。好多人PR一拒就缩回去了,觉得"我不行"。可人家愿意写review、点名哪行逻辑有问题,这免费的一对一是花钱买不着的。火是被磨出来的,不是一上来就烧旺。

这周末我挑个边界判断的小问题开拆。有人一起的么,组个互相review的小队,気持ちいい。

penguin_2001
[链接]

收藏当学会这个坑谁没踩过哈哈 读commit历史这招新鲜,比囤视频顶用,下次我也去扒个活跃项目瞅瞅

hamster_456
[链接]

临摹油画那段给我看乐了,可不咋地。我当年也是被个开源小工具勾着,硬对着commit历史瞎翻,比守着那几百G教程顶用hh

bored_12
[链接]

我柜子里那堆没拆封的书跟你这几百G教程是一回事哈哈 全是假性富裕

scoop_1
[链接]

你第三次PR能过,我怀疑是maintainer看你改了三回心软了哈哈。话说被打回来那两次都改了啥方向?我之前提PR也被来回折腾,最后发现对方就想要我把测试补上,前面绕了好大一圈。

scout_876
[链接]

那个被 maintainer 打回来两次的 PR,我可太想听细节了。到底是哪个项目?好家伙你改的那处边界判断,前两次打回分别卡在哪儿——是测试没覆盖到 case,还是人家觉得你这改法牵动了别处的逻辑?我听说过不少大项目的 reviewer 自己都未必逐行看完 diff,有时候打回纯粹是 CI 挂了,或者他那天刚跟对象吵完架,跟你代码质量半毛钱关系没有。所以第三次能过,未必是你真改对了,也可能是人家终于消气了(手动狗头)。
对了
你这套「从 commit 历史读起」的路子,我捋下来比看官方文档狠太多了。怎么说文档是打扮过的门面,commit 才是没修过图的素颜。有个事不知道该不该说,我认识的一帮写代码的朋友里,真有人靠翻某个项目前两三年的提交记录,反推出他们架构为啥从 A 迁到 B——文档里一个字没提,全藏在那些 revert 和「temporary fix, will refactor later」的注释里,结果那个「later」就再没来过。

不过补一刀:star 高不等于适合新手拆。几千 star 的项目模块盘根错节,一头扎进去容易迷路。反倒是百来 star、两三个人的小项目,作者还在亲自回 issue,你提个 PR 他当天就能跟你聊上,那种「滚烫的火」来得最快。你最后挑的是哪一类?有空报个牌名,我也去凑凑热闹。

[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
需要登录后才能回复。[去登录]
回复此帖进入修真世界