天下文章一大抄,是古代的一句俗语，并无明确出处和作者,这句话的最初灵感来源自清代孙洙编辑的《唐诗三百首》序言。我把他用在了软件开发岗位，发现思路是相同的，写代码和写古诗思路是相同的。 “熟读唐诗三百首，不会做诗也会吟。”
一开始我对这句话是有抵触的。因为它听起来像是在为“照搬”找理由。但后来写的代码越来越多，看的系统越来越复杂，我才慢慢意识到： 真正的问题从来不是“抄不抄”，而是“你抄的是什么”。
一、最早“抄”的，是能跑起来的结果
刚开始工作的时候，我抄代码的方式很直接：
- 找一个能跑的例子
- 改变量名、改接口
- 让功能先上线
那时候我最关心的是：
它能不能用。
只要能用，哪怕自己并不完全理解，也会下意识地跳过。
这种方式在一开始是有效的。 它能帮你快速完成任务，也能积累“做过”的经验。
但问题很快就会出现：
- 同样的代码，换个场景就不敢动
- 出问题时不知道从哪里查
- 一旦需要扩展，就开始整体失控
我慢慢发现： 我抄到的只是“结果”，而不是“能力”。
二、后来发现，真正值钱的不是代码本身
有一段时间，我开始有意识地多看一些成熟项目的代码。
但这一次，我关注的点变了。
我开始问自己一些不太“代码层面”的问题：
- 为什么这个逻辑要拆成两个模块
- 为什么这里要多绕一层，而不是直接写
- 为什么这个接口看起来“有点麻烦”
这些问题，一开始是很难通过“抄”解决的。
因为答案通常不在那几行代码里，而在：
- 这个系统之前遇到过什么问题
- 这个设计在为未来哪种变化做准备
- 它在性能、可读性、扩展性之间选了哪一边
我第一次意识到： 我真正该“抄”的，其实是这些取舍。
三、现在理解的“抄”，更像是顺着别人思路走一遍
现在再看代码，我很少一上来就关心实现细节。
我更关心的是：
- 这个东西存在的动机是什么
- 它解决的到底是哪一类问题
- 如果没有它，系统会在哪里变得难受
很多时候，我会刻意跳过细节，先去找：
- 这个模块在系统中的位置
- 它和其他模块的边界
- 哪些地方被刻意“限制”住了
只有当这些东西逐渐清楚，我才会回过头去看代码是怎么写的。
这时候再看“实现”，感觉完全不一样。
你会发现很多代码并不“优雅”， 但它们非常有针对性。
四、为什么“只抄代码”很容易卡住
我见过不少人说自己也在看源码、抄实现，但进步并不明显。
后来我慢慢觉得，原因往往不是不努力，而是关注点错了。
如果你只在抄：
- API 用法
- 具体实现技巧
- 某个“很巧妙”的写法
那你抄到的，大概率是局部最优。
一旦脱离原来的上下文，这些东西就很难复用。
相反，如果你在抄的是：
- 模块是怎么被拆出来的
- 变化是被隔离到哪里的
- 哪些地方被明确禁止“随便扩展”
哪怕一开始你写不出一模一样的代码， 你的系统会越来越像“能长期演进的样子”。
五、回头看，我们到底在“抄”什么
如果现在再让我用一句话总结，我会这么说：
我抄的不是代码，而是别人为复杂问题付出的思考成本。
代码只是这些思考留下的痕迹。
当你开始试着去抄这些东西时，你会发现：
- 看代码变慢了
- 理解周期变长了
- 但写出来的东西，反而更稳了
也正是在这个阶段，我才真正感觉到：
“抄”这件事，开始对我产生长期回报。 所以我将这段话，作为我的博客 slogan