去年帮朋友看一个企业站，代码打开源码文件夹，网站三千多个文件，源码index.php里嵌套了七层include。代码那哥们儿说这站是网站五年前花八千块找人做的，现在想改个banner图都得翻半天。源码

代码网站源码这事，代码说白了就是网站一堆文本文件按特定规则堆在一起。但偏偏有人能把简单的源码东西搞成迷宫。我见过一个CMS，代码模板文件里混着SQL查询，网站控制器里写着HTML，源码模型层干脆不存在。代码这种代码能跑起来算奇迹，网站维护起来要命。源码

自己写代码的时候，我有个习惯——看别人的源码先找入口文件。index.php、app.js、main.py，哪个先执行就从哪开始读。顺着调用链往下捋，比看文档快得多。有些开源项目文档写得漂亮，源码打开一看，函数命名全是data1、data2、temp，注释只有一行“TODO: fix this”。

前阵子想给博客加个暗色模式，翻了个热门主题的源码。CSS变量定义在三个不同文件里，JavaScript监听器绑在body上，切换逻辑写了八十多行。我自己重写，二十行搞定。不是说人家写得差，是很多主题作者在加功能时只管往上堆，从不回头整理。这就像往衣柜里塞衣服，塞到最后门都关不上。

源码质量跟项目规模没必然关系。GitHub上有个只有四百行的静态博客生成器，变量命名清晰，函数职责单一，读起来像散文。反而是一些大厂开源的框架，继承链深得吓人，一个方法追了十几个类还没到底。抽象是好东西，但过度抽象就是给自己挖坑。

下载源码来学习，别一上来就通读。挑个感兴趣的功能，比如路由怎么解析、模板怎么渲染，只追这一条线。读完在纸上画个流程图，比看十遍代码都管用。我学Vue的时候就是这么干的，把响应式原理的源码打印出来，用荧光笔标出依赖收集和派发更新的部分，贴墙上看了三天。

改别人源码要克制。见过有人接手项目，觉得之前写得烂，大刀阔斧重构，结果上线后bug比功能多。我的做法是先加日志，搞清楚哪些代码在跑、哪些是死代码。确认没用的直接删，要改的先用注释标出来，跑一周没问题再动。源码不是艺术品，能稳定运行比看着优雅重要得多。

现在GitHub上很多项目用Monorepo，一个仓库几十个包。找源码得先看package.json里的workspaces配置，不然在根目录翻半天找不到入口。这种结构对大团队有好处，对小项目就是灾难。我自己的项目从来都是一个仓库一个包，简单直接。

源码读多了会有种直觉。打开一个陌生项目，扫一眼目录结构就知道作者水平大概在哪个段位。config和src分开的，基本靠谱；所有文件堆在根目录的，做好心理准备；看到node_modules被提交进仓库的，直接关掉别浪费时间。

最后说个真事。有个朋友接了个外包，甲方给了套源码让二次开发。他打开一看，数据库连接信息硬编码在三十多个文件里。改数据库密码得用sed批量替换。这种代码能跑，但每改一次都是在赌命。源码是给人看的，顺便让机器执行。搞反了这个顺序，迟早要还债。