从个人编程到工程化思维
a、tmp，函数一写上百行，能跑就行。半年后需求改了，他打开自己当年的代码看了半天：「这段到底在干啥？」改完一处，别的地方又报错，只好再通宵排查。小丁也写代码，但会顺手写两行注释说明「为什么这么写」、把长函数拆成几个小函数、关键逻辑补上单元测试；提交时写清楚「改了什么、为什么」。半年后需求再改，他几分钟就定位到该改哪里，改完测试一跑，心里有底。差别不在谁更聪明，而在是否在用「工程化思维」写代码——为「别人」和「未来的自己」留一条能走通的路。本章带你认清个人开发与团队交付的差异，再讲清可读性、可测试性、可维护性三件事，以及文档、版本控制与协作习惯；最后落到一句话：为他人与未来写代码。
一、个人开发与团队交付的差异
一个人写、一个人用、写完就丢，可以「怎么快怎么来」。一旦代码要给别人看、给别人改、要长期留着用，游戏规则就变了：别人看不懂就会来问你、问多了你就成瓶颈；没有记录，过几个月没人记得「当时为什么这么设计」；没有规范，每个人风格不一样，合在一起就像拼布被子——能跑，但维护成本暴增。
- 自己看懂就行，命名、结构随意
- 改完就忘，不写注释、不写文档
- 能跑就行，不测也没关系
- 代码在本地，换电脑就没了
- 别人能接手：命名清晰、结构清楚
- 有记录：注释、文档、提交说明
- 可验证：有测试，改完敢发布
- 可追溯：版本控制、协作流程
所以，从「个人编程」到「工程化思维」，本质是责任对象的转变：从「对当下的自己负责」变成「对队友、对半年后的自己、对产品与用户负责」。下面三件事——可读性、可测试性、可维护性——就是这种转变在代码层面的具体体现。
二、可读性、可测试性、可维护性
这三项经常被合在一起说，因为它们互相支撑：可读别人（和自己）才看得懂；可测改完才有信心、重构才敢动手；可维护才能长期演进、不变成一坨不敢动的「祖传代码」。
- 可读性：变量、函数、类、文件的名字要「见名知意」；函数别太长，一段逻辑该拆就拆；注释重点写「为什么这么做」，而不是重复「做了什么」。代码是写给人看的，顺带让机器执行。
- 可测试性：核心逻辑尽量「纯」、少依赖全局和隐式状态，这样才容易写单测；大块逻辑拆成小函数、依赖通过参数或接口注入，测试时可以用 mock。可测试的代码往往结构也更清晰。
- 可维护性：高内聚、低耦合——一块代码只负责一类事，块与块之间通过清晰接口通信。这样改需求时能快速定位「该动哪一块」，改完也不容易误伤别处；重构时也有测试和结构兜底。
一句话： 可读是基础，可测是保障，可维护是结果。三者做到位，代码才能「活得久、改得动」。
三、文档、版本控制与协作习惯
工程化思维不仅体现在「代码怎么写」，还体现在文档、版本控制和协作习惯上。这三样是团队能并行工作、能交接、能追溯的根基。
文档：写什么、何时写
不是「代码里堆满注释」就叫文档，也不是「什么都写成长篇大论」。文档要对读者有用：架构文档给新人或评审看、API 文档给调用方看、运行手册给运维看、决策记录（ADR）给未来的自己看「当时为什么这么选」。原则：该写的写清楚、能代码表达的用代码、文档和代码一起更新。过时的文档比没有文档更害人。
版本控制：不只是「备份」
版本控制（如 Git）的作用不只是把代码存到云端，而是：谁在什么时候改了什么、为什么改，都有记录；可以开分支并行开发、再合并；出问题可以回滚或对比。工程化习惯包括：提交信息写清「改了什么、为什么」；分支策略统一（例如 main 保护、feature 分支开发）；重要改动通过 Code Review 再合入。下面这张图帮你建立「提交与分支」的直观印象：
协作习惯：接口、评审与沟通
多人改同一套代码时，接口要约定清楚（模块之间怎么调、传什么、返回什么），这样大家并行时不会互相踩脚。Code Review：别人改的代码你看一遍、你改的别人看一遍，既能发现错误又能统一风格、传播知识。沟通：需求不清先问、设计有争议先对齐、阻塞了及时说——这些看起来是「软技能」，却是工程能否顺畅运转的关键。
四、建立「为他人与未来写代码」的意识
有一句话常被引用：「写代码时，要假设六个月后接手的是一个知道你住址的暴力狂。」 意思是：别指望「反正我会记得」——你会忘；别指望「反正只有我用」——迟早会有人接手。所以，为他人与未来写代码，就是把「读者」当成一个具体的人：可能是你的队友、可能是半年后的自己、可能是下一个维护者。他们需要能快速看懂、能安全修改、能通过测试和文档理解「为什么这样设计」。
具体可以这样落地：命名多花几秒想清楚，避免 a、tmp、data2；函数别写太长，一段逻辑一个函数；复杂处补一句注释说「为什么」；关键逻辑加个单测，改完跑一遍；提交时写清「改了什么、为什么」；设计有取舍时写进 ADR 或文档，方便以后复盘。这些习惯一开始会多花一点时间，但会省下大量未来的排查和沟通成本。
五、小结
个人开发只对自己负责，团队交付要对他人与未来负责；差异体现在命名、文档、测试与版本控制上。可读性、可测试性、可维护性是工程化代码的三根支柱：可读别人才能看懂，可测改完才有底气，可维护才能长期演进。文档、版本控制与协作习惯是团队并行与交接的根基：文档要对读者有用并随代码更新，版本控制要留下清晰历史与分支策略，协作要讲清接口、做 Code Review、及时沟通。最后，建立「为他人与未来写代码」的意识：把读者当成具体的人，用可读、可测、可维护和良好习惯为他们铺路。下一章我们进入需求工程：需求获取与分类，为后续设计与开发打好地基。