编程语言研究书库
Prompting Python(AI 辅助全栈开发)

最佳实践 — 让代码活得比今天久

最佳实践 — 让代码活得比今天久

这一章讲什么: 前面九章教你做出东西,这一章教你做「能活下来的东西」—— 扛得住需求变更、新队友、数据增长和 Python 版本升级。 三件事:干净代码(让人读得懂)、测试(让改动有底)、Git(让历史可追)。 外加一节「接下来往哪走」。这一章没有新花样,是把全书的做法收口的职业卫生课。

1. 这一章讲什么

书里给这一章的定位是「长寿(longevity)」:软件不活在真空里—— 它被读、被改、被部署、被人维护,常常在原作者离开很久之后1。 所以本章教你用稍微挑剔一点的眼光看自己的作品,不为找茬,为提升清晰、可靠、性能。

这一章也是全书态度的总收口:AI 在这一章的角色被明确收窄为评审者和教练—— 帮你改进结构、出测试题、解释报错,而不是替你思考2。

2. 顶层全景:三个支柱 + 一个方向

  支柱一:干净代码    命名 > 注释;小函数 > 大聪明;结构 > 解释
  支柱二:测试        arrange → act → assert;边界用例优先;AI 出题你答题
  支柱三:Git/GitHub  commit = 有说明的决策;branch = 安全实验;PR = 自我评审
      │
      ▼
  方向:深基础 → 小项目 → 测试习惯 → 后端架构 → AI 当长期伙伴 → 分享所学

  图说:前三个支柱让代码活得久,最后一个方向让你自己长得快。

3. 核心原理

3.1 干净代码:三个「胜过」

每个开发者都经历过这个时刻:打开几个月前自己写的文件,心想「我当时为什么这么做?」3 干净代码不是炫技,是给未来的自己和别人留一条能走的路。

Python 干净代码的三个定义性品质:易读、易推理、易改4。 注意清单上没有的东西:聪明的技巧、压缩到一行的写法、过早使用的「高级」模式—— Python 的长处一直是清晰,好的 Python 代码顺着这个长处走,不跟它拧着5。

命名是最快的改进。 对照(书里的原例):

def calc(x, y):            return x * y * 0.1     # 能跑,不解释自己
def calculate_discount(price, discount_rate):
                           return price * discount_rate   # 只有它会说话

两个都能跑,只有一个解释了它自己6。改法照旧问 AI:「给定这个函数和它的用法,建议更清楚的变量和函数名。」

小函数胜过大聪明。 一个函数干超过一件事,就是干太多。与其写一个长函数 (读数据 → 处理 → 格式化 → 写盘),不如拆成可以独立命名和理解的步骤: load_sales_data(path) / calculate_totals(data) / generate_report(totals)—— 每个函数更好测、更好复用、更好解释7。提示:「帮我把这个函数拆成更小的、单一用途的函数,不改变行为。」

结构比注释更能制造可读性。 好结构靠:一致的缩进、有逻辑的留白、成组的相关操作、 常量/函数/执行段的清晰排序。目标不是「用注释解释代码」,而是让代码不需要解释8。 让 AI 审结构:「审这个 Python 文件的可读性与结构清晰度,给改进建议,别加复杂度。」

PEP 8:共同语言,不是规则手册。 遵守它的意义:任何熟悉 Python 的人读你的代码更快; 工具行为更可预测;团队为格式吵架变少。理解规则为什么存在,比记住规则重要: 行宽限制改善扫读;一致命名降低心智负担;留白让逻辑更好跟9。 所以别对 AI 说「修 PEP 8 问题」,问:「解释哪些 PEP 8 建议在这里改善了可读性,哪些是可选的。」10

AI 的最佳用法:当评审者。 写完代码自己,贴上去: 「像队友一样评审这段代码,聚焦清晰、命名、可维护性。」然后你决定采纳什么、忽略什么——最终裁判是你11。 干净代码常常不是一次写成的:重构(改结构不改行为)发生在小步里, 动手前确保读懂、动手中步子小、动手后再测一遍;让 AI 解释「为什么这个重构有帮助」,不只是「怎么改」12。

3.2 测试:安全网,不是负担

测试保证代码现在对,并且在它长大后继续对。书里对新手的态度很直接: 测试感觉像可选项,但在真实项目中没得商量13。它给你四样14:

好处意思
用户之前抓住 Bug在变成事故前暴露
无惧重构第四章的「锁行为」靠它
更懂自己的逻辑写测试逼你想清边界
对作品有信心改动后有据可依

单元测试(unit testing)= 测小而独立的代码块(通常是函数)。 你写个「两数相加」的函数,单测回答:对不同输入,它是否总返回正确结果—— 测的是行为,不是整个应用15。

pytest 是本书的测试工具,流行因为:读写简单;强大而不复杂;真实公司在用; 不需要类或复杂配置就能起步16。

一个测试的三拍:Arrange(备输入)→ Act(调函数)→ Assert(验结果)。 用大白话说:「当我给这个输入,我期望这个输出。」17 测什么:正确结果、错误输入、边界情况(空值、零、负数)18。

好测试与坏测试(书里的对照):好测试小而有焦点、一次测一件事、 测试名说清在测什么;坏测试想一次测所有事、互相依赖、难读懂。 一个测试挂了,你应该立刻知道为什么19。

边界情况:Bug 的藏身所。 新手只测「快乐路径」(明显能跑的输入); 真实 Bug 出现在:输入为空、输入出乎意料、值极大或极小、类型错了(该数字给了字符串)。 测边界是新手与专家的分水岭20。

AI 的正确用法:出题人,不是答题人。 别让 AI「帮我写测试」, 用引导推理的提示21:

  • 「列出这个函数的边界情况。」
  • 「什么输入能打破这个逻辑?」
  • 「生成真实世界使用场景的测试用例。」
  • 「这个函数做了什么假设?」

测试挂了的时候:仔细读报错 → 定位什么失败,不只是失败这个事实 → 问 AI「为什么这个断言会失败?」「什么会导致这个函数返回 None?」「用简单的话解释这个报错。」 学得快,而不是闭眼修22。

什么时候写测试(好习惯清单):函数一跑通就写;修 Bug 时补一个; 先测关键逻辑(权限、支付、计算)23。书里没有说但值得记下的一条(我们的补充): 修 Bug 先写能复现它的测试再修——这是第四章六步流程第 ③ 步的常态化。

3.3 Git 与 GitHub:项目的记忆

如果 Python 是你写作的语言,Git 就是你项目的记忆24。 没有版本控制,开发变得脆弱:实验时覆盖掉能跑的代码;回不到早先版本; 协作沦为文件传来传去;Bug 没法追溯来源。Git 的记录让每次改动有意、可逆、有说明25。

四个必懂概念26:

概念一句话
Repository(仓库)被跟踪的项目文件夹
Commit(提交)一次改动的快照,附一条说明「为什么」
Branch(分支)代码的平行版本,用来安全实验
Remote(远端)托管在别处的仓库副本(比如 GitHub)

最小工作流三步:git init 建库 → git add . 把文件放进待提交区 → git commit -m "说明" 提交。书里的强调点:好的提交说明解释「为什么有这个改动」, 不只是「改了什么」27。

GitHub 不只是备份,是协作与学习平台:Pull Request(合并前提议改动并评审代码)、 Issues(跟踪 Bug、想法、改进)、提交历史(理解项目怎么演化)。 哪怕一个人开发,用 PR 也能让你慢下来、批判性地审自己的活28。

AI 介入 Git 工作流的四个提示(书里原样):「评审这次 commit 的 diff,我 push 前给点改进」 「帮我为这些改动写一条清楚的提交说明」「这个 PR 有没有引入隐藏风险?」 「给小 Python Web 应用建议一个分支策略」29。

被低估的一章:Git 作为学习工具。 翻旧提交你能看见自己的思考如何进步、 Bug 什么时候被引入、过去的设计决定长什么样——许多资深开发者把成长归功于版本控制, 不是因为工具本身,而是它强迫你有意地开发30。

3.4 未来方向:六条进阶路

书里最后一节把「接下来往哪走」铺成六条,每条都给了立刻可做的动作31:

  1. 加深 Python 基础:可复用的函数与模块;熟练操作列表、字典、类;读得懂别人的代码——基础强,后面每个话题都轻;
  2. 多建小的真实项目:任务管理器、存取数据的简单 API、展示输入的仪表盘、解决个人烦恼的小工具——小项目教你的大过永远不开的宏大计划;
  3. 深入测试与调试:先写测试再写逻辑(测试先行);学测 API 与用户输入;用报错、日志、测试三件套练调试——这是职业工程师思维的开端;
  4. 学基础后端架构:文件怎么组织、API 怎么与前端通信、逻辑/数据/表现怎么分层、环境变量与配置怎么工作——项目越大结构越要命;
  5. 把 AI 当长期学习伙伴:解释陌生报错、建议边界与改进、评审清晰性、帮项目分步规划——避免用 AI 跳过学习,用它加速理解;
  6. 开始分享:写短帖、把项目文档写清楚、用大白话讲概念、分享错误与教训而不只是成果——教是最快的成长方式之一,同时建立真实的可信度。

3.5 名词册:四个会被混用的词

收尾前把本章四个 Key Terms 的关系钉死——它们经常被混着用:

词它管什么一句话边界
Clean Code(干净代码)人读的状态目标:别人(和未来的你)读得懂
PEP 8排版的约定是共同语言,不是法律;理解为什么比背诵重要
Unit Testing(单元测试)行为对不对测单个函数;arrange → act → assert
Refactoring(重构)结构好不好不改行为,只改结构;动手前测试兜底

四个词正好覆盖两个维度:对不对(测试)与好不好(干净代码、PEP 8、重构)。 一个常见误区是把它们当一个东西:「代码能跑就是干净」「测过了就是重构过」——都不对。 书末 Points to Remember 里那句「代码被读的频次远高于被写的频次」, 就是为什么「好不好」值得单独花一章32。

3.6 与前面九章的接口:这一章在全书里的位置

最后一章没有新代码,它的价值在「收口」。把三条支柱接到前面九章:

支柱前面哪章练过本章升级成什么
干净代码第 2 章(读法)、第 4 章(重构)从「AI 帮你改」升级为「AI 评审、你裁判」的常态
测试第 4 章(六步流程的测试环节)从「调试用」升级为「日常安全网」
Git第 4 章(实验分支)从「防爆」升级为「项目记忆与学习工具」

三条接口指向同一个转变:从「写代码」到「维护代码」。 书里的原话:这一章标志着从「写能跑的代码」到「写能活的代码」的转变—— 专业主义不只是功能,还有清晰、结构、安全与协作33。

3.7 一个职业习惯的启动清单(本周就能做的五件事)

书里六条未来方向偏长期,这一节给一份本周可执行的五件事清单 (我们的拆解,挂在那六条方向之下):

  1. 挑一段你写过的代码,让 AI 当队友评审一次,逐条写采纳/拒绝理由(第 3.1 节);
  2. 给一个你觉得「不能再改了」的函数补三个边界测试(空/极值/错型)(第 3.2 节);
  3. 给一个旧项目 git init,把当前状态作为第一个 commit,commit message 写「为什么」(第 3.3 节);
  4. 把第 9 章的 Flask 应用讲给一个不懂代码的人听,卡住的地方回炉(全书);
  5. 写一篇 300 字的笔记,记录一次「AI 建议错了」的经历(第 3.4 节的教是最好的学)。

五件事的共同点是都产生外部产物:评审记录、测试、commit、讲述、笔记。 没有外部产物的练习会在记忆里蒸发——这是「成长来自一致练习,而非完美」 那句 Points to Remember 的操作化34。

3.8 AI 用法的最后界线(全书的总纪律)

第十章给 AI 的角色画了最后的界线,三条「别用」与三条「该用」:

别用 AI 来:替你做最终决策(采纳与否永远是你);吞掉你不理解的错误; 跳过你自己本该经历的学习曲线35。

该用 AI 来:解释陌生报错;建议边界用例;评审清晰性;帮你把项目分步规划36。

界线的一句话版本:AI 加速理解,不替代理解。 这与第一章「协作者,不是拐杖」 首尾呼应——全书十章,变的是场景(读码/提示/调试/自动化/游戏/NLP/报告/Web/工程), 不变的是这条界线。判断自己有没有越界的最简指标,第一章就给过: 拿到 AI 的方案后,你能讲给别人听吗?能,就没越界。

3.17 测试风格的两极(书里的好坏对照展开)

§3.2 给了好坏测试的对照,这里把它展开成可以自查的风格细则:

好测试长什么样:

def test_average_of_single_item_is_itself():
    assert average([5]) == 5.0

def test_average_of_empty_list_returns_zero():
    assert average([]) == 0
  • 名字是一句完整的话:读测试名就知道在验什么断言;
  • 一个测试只验一件事:test_average_normal_and_empty 这种名字就是危险信号;
  • 三拍清楚:第一行备输入,第二行调函数,第三行断言。

坏测试的三个信号(书里的对照表37):想一次测所有事(断言摞了三层); 测试之间互相依赖(测试 B 依赖测试 A 创建的临时文件——单独跑 B 就红); 读起来费劲(setup 比断言还长)。

AI 在这个环节的正确站位: 让它列出边界(出题),让它解释失败的原因(陪练), 但断言的期望值必须你写——因为期望是「你对需求的理解」,这是全章唯一不能外包的部分。

3.18 提交信息的写法(书里的一个细节放大)

书里的例子:git commit -m "Add data validation for user input"—— 注意这条信息说的是为什么/加了什么能力,不是「改了哪些文件」38。

两类写法的对照:

写法例子问题
文件视角"update report.py"三个月后看不出动机
决策视角"Add data validation for user input"读历史如读设计记录

AI 可以帮你把文件视角翻译成决策视角——书里的提示:「帮我为这些改动写一条清楚的提交说明」39。 但素材仍然是你:diff 里改了什么是机器看得见的,为什么改只有你记得。养成「commit 前写一句为什么」 的肌肉记忆,Git 才真正成为书末说的那种「学习工具」:翻自己的提交历史, 能看到思考是如何一步步变清楚的40。

3.9 全书的总收口:五条 Points to Remember

原书最后一章的收尾五条,是全书的总账,照录41:

  1. 可读的代码比聪明的代码值钱——代码被读的频次远高于被写;
  2. 测试是安全网不是负担——它让你敢改、在用户之前抓 Bug;
  3. AI 最好的角色是评审与教练——改进结构、建议测试、解释错误,而不是替你想;
  4. 性能意识随经验增长——先写清楚,必要时凭证据优化;
  5. 成长来自一致的练习,不是完美——小项目、常复盘、持续学,胜过任何单一工具。

五条里前四条各对应本章一根支柱(或一个方向),第五条对应那六条进阶路。 注意没有一条落在「记住更多语法」上——全书十章,没有任何一条收尾落在语法; 落的全是判断、验证、结构、协作。这就是这本书对「学编程」这件事的重新定义, 也是它作为「AI 时代编程教育样本」的核心证据。

3.12 全书的最后一瞥:书的结构本身就是论点

收尾前把一个全书级的观察说透:这本书的目录排列,本身就是它最重要的论点。

十章的顺序是:心态 → 读 → 说 → 调 → 杂务 → 游戏 → 语言 → 数据 → 应用 → 工程。 把动词抽出来:想 → 读 → 说 → 验 → 省 → 玩 → 析 → 报 → 交 → 护。 「写」在哪?写被拆散嵌进了每一章(生成代码从来只是各章的一步,从来不是一章的主角)。

对比传统编程教材的目录:变量 → 控制流(决定程序执行顺序的语句,如 if 和循环) → 函数 → 类 → 文件 → 异常…… 动词全是「语言构件」。两种目录的差别,就是「学语言」与「学编程」的差别—— 也是这本书对「编程语言与系统研究」最有价值的提醒:当生成代码不再稀缺, 教学的组织轴会从「语言构件」滑向「工程动作」。 研究编程教育的人, 光对比这两张目录,就能得到一整篇论文的素材。42

3.12 一个 Watson 式的对照(我们的补充,挂在全书主张下)

想体会本章方法论的轮廓,可以做一次思想实验:把同一个 Bug 交给两个开发者——

开发者甲(前 AI 时代): 读报错 → 凭记忆猜 → 翻文档/Stack Overflow → 试修 → 再跑。 循环一圈几分钟到几小时;知识在每次循环里靠记忆积累,随人走、随离职散。

开发者乙(本章方法): 读报错 → 写失败测试 → CCG 问 AI → 应用 → 测试绿 → 固化。 循环一圈几分钟;知识沉淀在测试与提交说明里,留在仓库,任何人可读。

两个对照的差别不只在速度,更在知识的落点:甲的知识在人脑,乙的知识在仓库。 书里那句「Git 是项目的记忆」43说的正是这个转移——当生成被 AI 接管, 工程师之间的竞争从「谁知道得多」变成「谁把知道的东西留得规整」。 这是第十章对「编程语言与系统研究」最实际的一条贡献。

判断(我们的,不是书里的): 第十章是全书真正的「论点章」—— 它不教新东西,而是回头给前九章的做法盖章(命名、测试、提交说明,每条都「原来如此」)。 这种把方法论收拢为职业习惯的收尾,正是这本入门书高出同类教材半头的地方: 多数教材的最后一章是「接下来学什么的广告」,这本是一条可以明天就用的纪律清单。 如果错,会错在: 对已经职业化多年的读者,这五条清单会显得像常识复读; 它们的价值与读者当前的工程肌肉量成反比——肌肉越薄,收获越厚。

4. 作者的判断与证据

有依据的判断:

  • 「结构比注释更能制造可读性」「命名是最快改进」——软件工程通识,与书中示例自洽6;
  • 「测边界是新手与专家的分水岭」——测试文献的共识,书中列的四种边界(空/意外/极值/错型)是对的20;
  • 「提交说明解释为什么」——Git 社区的通行规范27。

经验之谈:

  • 「AI 当评审者优于当作者」——本书全书的实践总结,与第 1 章「协作者心态」首尾呼应11;
  • 「六条进阶路」的顺序——合理但不是唯一路径;想进数据方向的人显然应先深 pandas 而非后端架构。

推测:

  • 「许多资深开发者把成长归功于 Git」——轶事级证据,当激励读30。

5. 边界与局限

  • 性能优化名不副实:章名带 Optimization,但正文几乎没有性能内容——只有 「先写清晰,必要时凭证据优化」一句带过(Points to Remember 里「性能意识随经验增长」)。 想找剖析(profiling)、算法复杂度、缓存的读者会落空;
  • pytest 深度止步于门口:没讲 fixture(测试夹具)、parametrize(参数化)、mock(模拟外部依赖);
  • Git 只给了最小集:合并冲突、变基(rebase)、版本回退的操作都没有;
  • 协作流程理想化:PR 评审在真实团队里有代码所有权、CI 门禁等制度层,本章纯个人视角。

6. 可带走的

本章主线例子,一行写完: calc(x, y) → AI 建议改名 calculate_discount(price, discount_rate) → 拆成小函数 → AI 以「队友视角」评审 → 你取舍 → 补 arrange-act-assert 单测(含空/零/负数) → git add . && git commit -m "说明为什么" → 用 PR 自审一遍再合并。

  1. 干净代码三品质:易读、易推理、易改;命名是最快的改进;
  2. 小函数胜过大聪明;结构比注释更能制造可读性;
  3. PEP 8 是共同语言:问「为什么有这条规则」,不问「规则是什么」;
  4. AI 当评审不当作者:它建议,你裁判;
  5. 测试三拍:备输入 → 调函数 → 验结果;测试名说清在测什么;
  6. 边界四怪:空、意外、极值、错型——测它们是新手到专家的分水岭;
  7. AI 当出题人:「列出边界情况」「什么输入能打破这个逻辑」;
  8. 修 Bug 先写复现它的测试;
  9. Git 四概念:仓库、提交、分支、远端;提交说明写「为什么」;
  10. 下一步六条路:基础、小项目、测试、架构、AI 伙伴、分享——教是最快的成长。

7. 原文地图

主题原书章原文位置
长寿定位Best Practices and Optimizationtext/22-ch10-10-best-practices-and-optimization.txt:21(搜「longevity」)
三品质与名单上没有的同上text/22-ch10-10-best-practices-and-optimization.txt:66(搜「easy to reason」) · text/22-ch10-10-best-practices-and-optimization.txt:73(搜「clever tricks」)
命名对照同上text/22-ch10-10-best-practices-and-optimization.txt:82(搜「calc(x, y)」)
小函数拆分同上text/22-ch10-10-best-practices-and-optimization.txt:109(搜「more than one thing」)
结构比注释同上text/22-ch10-10-best-practices-and-optimization.txt:182(搜「makes explanations unnecessary」)
PEP 8 三条为什么同上text/22-ch10-10-best-practices-and-optimization.txt:218(搜「Line length」)
AI 当评审同上text/22-ch10-10-best-practices-and-optimization.txt:243(搜「as if you were a teammate」)
测试四好处同上text/22-ch10-10-best-practices-and-optimization.txt:288(搜「Catch bugs」)
三拍与测什么同上text/22-ch10-10-best-practices-and-optimization.txt:343(搜「Arrange」)
好坏测试对照同上text/22-ch10-10-best-practices-and-optimization.txt:380(搜「small and focused」)
边界四怪与分水岭同上text/22-ch10-10-best-practices-and-optimization.txt:410(搜「happy paths」)
AI 出题四提示同上text/22-ch10-10-best-practices-and-optimization.txt:446(搜「edge cases for this function」)
测试失败时问 AI同上text/22-ch10-10-best-practices-and-optimization.txt:477(搜「Why would this assertion fail」)
Git 是记忆、无 Git 四脆同上text/22-ch10-10-best-practices-and-optimization.txt:513(搜「memory of your project」) · text/22-ch10-10-best-practices-and-optimization.txt:520(搜「overwrite working code」)
四概念与提交说明同上text/22-ch10-10-best-practices-and-optimization.txt:540(搜「Repository」) · text/22-ch10-10-best-practices-and-optimization.txt:577(搜「why the change exists」)
GitHub 三件套与 PR 自审同上text/22-ch10-10-best-practices-and-optimization.txt:588(搜「Pull Requests」)
Git 当学习工具同上text/22-ch10-10-best-practices-and-optimization.txt:627(搜「underrated benefit」)
六条未来方向同上text/22-ch10-10-best-practices-and-optimization.txt:665(搜「Deepen Your Python」) · text/22-ch10-10-best-practices-and-optimization.txt:783(搜「skip learning」)
代码被读远多于被写同上text/22-ch10-10-best-practices-and-optimization.txt:837(搜「read far more often」)
Key Terms 四词同上text/22-ch10-10-best-practices-and-optimization.txt:816(搜「Clean Code」)

Footnotes

  1. 出处:「Best Practices and Optimization」第 21 段(text/22-ch10-10-best-practices-and-optimization.txt:21,搜「longevity」)。 ↩

  2. 出处:「Best Practices and Optimization」第 24 段(text/22-ch10-10-best-practices-and-optimization.txt:24,搜「support collaboration」)与结论段(text/22-ch10-10-best-practices-and-optimization.txt:653,搜「reviewer, mentor」)。 ↩

  3. 出处:「Best Practices and Optimization」第 53 段(text/22-ch10-10-best-practices-and-optimization.txt:53,搜「Why did I do it like this」)。 ↩

  4. 出处:「Best Practices and Optimization」第 63 段(text/22-ch10-10-best-practices-and-optimization.txt:63,搜「easy to read」)。 ↩

  5. 出处:「Best Practices and Optimization」第 73 段(text/22-ch10-10-best-practices-and-optimization.txt:73,搜「clever tricks」)。 ↩

  6. 出处:「Best Practices and Optimization」第 9–10 段(text/22-ch10-10-best-practices-and-optimization.txt:82,搜「calc(x, y)」)。 ↩ ↩2

  7. 出处:「Best Practices and Optimization」第 12–13 段(text/22-ch10-10-best-practices-and-optimization.txt:109,搜「more than one thing」)。 ↩

  8. 出处:「Best Practices and Optimization」第 182 段(text/22-ch10-10-best-practices-and-optimization.txt:182,搜「makes explanations unnecessary」)。 ↩

  9. 出处:「Best Practices and Optimization」第 218 段(text/22-ch10-10-best-practices-and-optimization.txt:218,搜「Line length」)。 ↩

  10. 出处:「Best Practices and Optimization」第 231 段(text/22-ch10-10-best-practices-and-optimization.txt:231,搜「which ones are optional」)。 ↩

  11. 出处:「Best Practices and Optimization」第 243 段(text/22-ch10-10-best-practices-and-optimization.txt:243,搜「as if you were a teammate」)。 ↩ ↩2

  12. 出处:「Best Practices and Optimization」第 269 段(text/22-ch10-10-best-practices-and-optimization.txt:269,搜「Before refactoring」)。 ↩

  13. 出处:「Best Practices and Optimization」第 278 段(text/22-ch10-10-best-practices-and-optimization.txt:278,搜「non-negotiable」)。 ↩

  14. 出处:「Best Practices and Optimization」第 288 段(text/22-ch10-10-best-practices-and-optimization.txt:288,搜「Catch bugs」)。 ↩

  15. 出处:「Best Practices and Optimization」第 313 段(text/22-ch10-10-best-practices-and-optimization.txt:313,搜「testing behavior」)。 ↩

  16. 出处:「Best Practices and Optimization」第 319 段(text/22-ch10-10-best-practices-and-optimization.txt:319,搜「popular」)。 ↩

  17. 出处:「Best Practices and Optimization」第 343 段(text/22-ch10-10-best-practices-and-optimization.txt:343,搜「Arrange」)。 ↩

  18. 出处:「Best Practices and Optimization」第 369 段(text/22-ch10-10-best-practices-and-optimization.txt:369,搜「empty values」)。 ↩

  19. 出处:「Best Practices and Optimization」第 380 段(text/22-ch10-10-best-practices-and-optimization.txt:380,搜「small and focused」)。 ↩

  20. 出处:「Best Practices and Optimization」第 410 段(text/22-ch10-10-best-practices-and-optimization.txt:410,搜「happy paths」)。原文:「Testing edge cases is what separates beginners from experts.」 ↩ ↩2

  21. 出处:「Best Practices and Optimization」第 439 段(text/22-ch10-10-best-practices-and-optimization.txt:439,搜「guide reasoning」)。 ↩

  22. 出处:「Best Practices and Optimization」第 477 段(text/22-ch10-10-best-practices-and-optimization.txt:477,搜「Why would this assertion fail」)。 ↩

  23. 出处:「Best Practices and Optimization」第 497 段(text/22-ch10-10-best-practices-and-optimization.txt:497,搜「as soon as a function works」)。 ↩

  24. 出处:「Best Practices and Optimization」第 513 段(text/22-ch10-10-best-practices-and-optimization.txt:513,搜「memory of your project」)。 ↩

  25. 出处:「Best Practices and Optimization」第 33–34 段(text/22-ch10-10-best-practices-and-optimization.txt:520,搜「overwrite working code」)。 ↩

  26. 出处:「Best Practices and Optimization」第 540 段(text/22-ch10-10-best-practices-and-optimization.txt:540,搜「Repository (repo)」)。 ↩

  27. 出处:「Best Practices and Optimization」第 577 段(text/22-ch10-10-best-practices-and-optimization.txt:577,搜「why the change exists」)。 ↩ ↩2

  28. 出处:「Best Practices and Optimization」第 588 段(text/22-ch10-10-best-practices-and-optimization.txt:588,搜「Pull Requests」)。 ↩

  29. 出处:「Best Practices and Optimization」第 611 段(text/22-ch10-10-best-practices-and-optimization.txt:611,搜「Review this commit diff」)。 ↩

  30. 出处:「Best Practices and Optimization」第 627 段(text/22-ch10-10-best-practices-and-optimization.txt:627,搜「underrated benefit」)。 ↩ ↩2

  31. 出处:「Best Practices and Optimization」第 41–46 段(text/22-ch10-10-best-practices-and-optimization.txt:665,搜「Deepen Your Python」)与第 783 段(text/22-ch10-10-best-practices-and-optimization.txt:783,搜「skip learning」)。 ↩

  32. 出处:「Best Practices and Optimization」Points to Remember(text/22-ch10-10-best-practices-and-optimization.txt:837,搜「read far more often」)。原文:「The code is read far more often than it is written, so clarity should always come first.」 ↩

  33. 出处:「Best Practices and Optimization」结论段(text/22-ch10-10-best-practices-and-optimization.txt:650,搜「code that lasts」)。 ↩

  34. 出处:「Best Practices and Optimization」Points to Remember(text/22-ch10-10-best-practices-and-optimization.txt:852,搜「consistent practice」)。 ↩

  35. 出处:「Best Practices and Optimization」第 783 段(text/22-ch10-10-best-practices-and-optimization.txt:783,搜「skip learning」)。 ↩

  36. 出处:「Best Practices and Optimization」第 770 段(text/22-ch10-10-best-practices-and-optimization.txt:770,搜「Explain unfamiliar errors」)。 ↩

  37. 出处:「Best Practices and Optimization」第 380 段(text/22-ch10-10-best-practices-and-optimization.txt:380,搜「small and focused」)。 ↩

  38. 出处:「Best Practices and Optimization」第 574 段(text/22-ch10-10-best-practices-and-optimization.txt:574,搜「Add data validation」)。 ↩

  39. 出处:「Best Practices and Optimization」第 614 段(text/22-ch10-10-best-practices-and-optimization.txt:614,搜「clear commit message」)。 ↩

  40. 出处:「Best Practices and Optimization」第 627 段(text/22-ch10-10-best-practices-and-optimization.txt:627,搜「underrated benefit」)。 ↩

  41. 出处:「Best Practices and Optimization」Points to Remember(text/22-ch10-10-best-practices-and-optimization.txt:836,搜「Readable code is more valuable」至 :852,搜「consistent practice」)。 ↩

  42. (我们的全书级观察;目录次序依据 library/prompting-python/chapters.json 的章序。) ↩

  43. 出处:「Best Practices and Optimization」第 513 段(text/22-ch10-10-best-practices-and-optimization.txt:513,搜「memory of your project」)。 ↩

AI Web 应用 — 跨过脚本与应用之间那条线

Previous Page

Python Made Easy — 全书拆解

Next Page

On this page

最佳实践 — 让代码活得比今天久1. 这一章讲什么2. 顶层全景:三个支柱 + 一个方向3. 核心原理3.1 干净代码:三个「胜过」3.2 测试:安全网,不是负担3.3 Git 与 GitHub:项目的记忆3.4 未来方向:六条进阶路3.5 名词册:四个会被混用的词3.6 与前面九章的接口:这一章在全书里的位置3.7 一个职业习惯的启动清单(本周就能做的五件事)3.8 AI 用法的最后界线(全书的总纪律)3.17 测试风格的两极(书里的好坏对照展开)3.18 提交信息的写法(书里的一个细节放大)3.9 全书的总收口:五条 Points to Remember3.12 全书的最后一瞥:书的结构本身就是论点3.12 一个 Watson 式的对照(我们的补充,挂在全书主张下)4. 作者的判断与证据5. 边界与局限6. 可带走的7. 原文地图Footnotes