【Code Review】AI时代的CR还有意义么？一起看一个模板解析库

【Code Review】AI时代的CR还有意义么？一起看一个模板解析库 — 码农高天

码农高天

AI-assisted summary of 【Code Review】AI时代的CR还有意义么？一起看一个模板解析库 — original source. Check the original for full context.

Source published:

Key ideas

  • 码农高天通过 Review 微型模板解析库 tempparse 指出，AI 时代 Linter 与大模型已能扫除低级语法 Bug，Code Review 的核心重心必须转向 API 接口一致性、直觉设计与系统架构。 (5:00)
  • tempparse 巧用 Python 3.14 的 t-string 拆解 raw string 与 interpolations，省去手写分词器，并通过预编译正则与 property 缓存提升了多轮匹配性能。 (0:00)
  • 库中设计的 Conversion 装饰器仅包含 __init__ 与 __call__，既未增加静态检查信息也未提供额外校验逻辑，属于过度设计，完全可以直接传函数替代。 (5:00)
  • 该项目在 CI 中仅设置了打包发布任务，缺少自动化测试运行、覆盖率统计与静态 Lint 检查，暴露出工程化基础设施的明显短板。 (10:00)

Detailed notes

## Background 本视频由“码农高天”于 2026 年 10 月 3 日发布在 YouTube 平台。视频简介指出，在许多人认为 AI 时代 Code Review（代码审查）已无意义的背景下，本期内容通过一起审视一个小巧的模板解析库，探讨在看似“规整”的代码之下依然值得深入讨论的设计与工程话题。

## TL;DR 码农高天通过对微型开源项目 `tempparse` 的代码审查，展示了其巧妙利用 Python 3.14 的 `t-string` 特性与预编译正则缓存实现数据提取的亮点，同时也指出了参数命名为 `i` 等可读性瑕疵。他重点剖析了该库在接口设计上的硬伤：不仅生造了毫无逻辑增强价值的转换装饰器，还在模板中特化引入 `json` 模块破坏了参数一致性，并存在类型输入冗余与违背占位符直觉等问题。此外，项目还暴露出缺乏测试覆盖率统计与自动化 CI 校验等工程化短板。高天借此得出结论：AI 虽然能扫除低级语法 Bug，但系统架构的合理性、API 的人机工程直觉与接口自洽性，依然是 AI 时代代码审查不可替代的核心价值。

## Atmosphere & style 视频展现出资深工程师从容且犀利的审视风格，开场带着兑现社区挑战承诺与调侃库名谐音的轻松闲聊感，随后迅速切换至严谨挑剔的架构分析。高天在指出代码冗余与特例破坏时直言不讳、观点鲜明，既有对浮点数比较等细节的即兴吐槽，又有对 API 交互设计逻辑的深度推敲。整场 Review 节奏紧凑而层次分明，呈现出一种资深技术专家在白板前层层剖析代码本质、追求工程设计美感与自洽性的浓厚技术探讨氛围。

## Bulletin - [05:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=300s) 码农高天通过 Review 微型模板解析库 tempparse 指出，AI 时代 Linter 与大模型已能扫除低级语法 Bug，Code Review 的核心重心必须转向 API 接口一致性、直觉设计与系统架构。 - [00:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=0s) tempparse 巧用 Python 3.14 的 t-string 拆解 raw string 与 interpolations，省去手写分词器，并通过预编译正则与 property 缓存提升了多轮匹配性能。 - [05:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=300s) 库中设计的 Conversion 装饰器仅包含 __init__ 与 __call__，既未增加静态检查信息也未提供额外校验逻辑，属于过度设计，完全可以直接传函数替代。 - [10:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=600s) 该项目在 CI 中仅设置了打包发布任务，缺少自动化测试运行、覆盖率统计与静态 Lint 检查，暴露出工程化基础设施的明显短板。

## Key takeaways - [00:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=0s) 项目 tempparse 基于 Python 3.14 的 t-string 特性构建，利用模板字符串自动拆解 raw string 与插值变量，免去了手写词法解析器的复杂度。 - [00:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=0s) 对于多次执行的正则匹配，必须使用 re.compile 预编译并结合 property 缓存，避免重复开销以提升运行效率。 - [00:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=0s) 核心转换函数的参数命名应避免使用如 i 这类具有强烈循环索引心智暗示的单字母，以免严重损害代码可读性。 - [05:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=300s) AI 时代 Code Review 的重心已不再是抓缩进和简单拼写错误，而应聚焦于设计合理性、抽象层级与人机工程接口直觉。 - [05:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=300s) 类名小写的 parse 是为了模拟函数调用并赋予泛型提示所作的妥协性 Hack，因当前 Python 版本尚未正式支持函数级显式泛型传递。 - [05:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=300s) Conversion 与 FormatConversion 类装饰器属于无价值的冗余封装，运行时反射完全可以判定参数签名，装饰器反而增加了使用负担与命名不一致。 - [10:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=600s) API 设计应恪守最小输入原则，在外部泛型已明确指定返回类型且无歧义的情况下，不应强迫用户在模板大括号内重复声明类型。 - [10:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=600s) 在 t-string 语境下，大括号内直接放置转换规则违背了代表目标变量的直觉，更合理的方案是复用 format spec 冒号语法（如 {:percent}）。 - [10:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=600s) 大括号内允许传入 json 模块破坏了整体接口自洽性，因为模块并非可调用函数或类，属于生造特例的糟糕接口设计。 - [10:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=600s) 极度强调泛型提示的库如果缺失运行时类型断言与检查，类型安全体系便无法真正形成闭环。 - [10:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=600s) 仅配置 Wheel 打包发布而缺少单测执行、代码覆盖率统计和 Lint 扫描的 CI 流程形同虚设，难以保证工业级软件交付质量。 - [10:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=600s) AI 不会自动为开发者补齐高维度的接口审美与严谨的工程化标准，架构把控与审视设计依然是程序员不可替代的核心竞争力。

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=0s) 项目初探：基于 Python 3.14 t-string 的模板解析库

码农高天在视频开篇提到，这次 Code Review 是兑现之前 PyCon Taiwan 挑战视频欠下的内容，并顺便预告 PyCon Taiwan 还有一个月就要开始。这次 Review 的是一个名为 `tempparse`（视频中提到发音读起来很像“Temp Earth/临时的屁股”）的微型 Python 项目。

该项目的核心功能是从一个给定的字符串中，按照提供的模板提取结构化数据。例如给出一个模板，并在需要提取的部分用大括号指定目标类型（如 `str` 保持原样，`int` 则转换成整数），传入待解析字符串后即可提取出对应的数值。该项目还引入了泛型（Generics），能在调用时提示并约束返回值类型，对静态类型检查非常友好。

```mermaid flowchart LR accTitle: tempparse 核心解析流程 accDescr: 展示从模板字符串通过 t-string 与正则表达式拆解并最终转换为结构化数据的过程。

subgraph Input ["输入定义"] T["模板 t-string\n(如 t'year: {int}')"] S["目标字符串\n(如 'year: 2010')"] end

subgraph Engine ["解析引擎"] TS["Python 3.14 t-string\n(拆分 raw string 与 interpolations)"] RE["预编译正则 Match\n(带属性缓存 cache)"] CV["成对调用 convert(str, interpolation)"] end

subgraph Output ["最终输出"] RES["类型转换结果\n(如 2010: int)"] end

T --> TS S --> RE TS --> RE RE --> CV CV --> RES ```

在具体实现细节上： - **单文件架构**：整个项目不到 170 行，所有代码都塞在 `__init__.py` 里面。虽然在极小项目中可以跑通，但正常情况下依然更推荐拆分到不同模块。 - **巧用 Python 3.14 特性**：代码取巧地借助了 Python 3.14 新引入的 string template（即 `t-string`）。`t-string` 自带解析能力，能自动将模板拆分成 raw string 与 interpolations，作者直接省去了手写模板分词器的麻烦。 - **性能优化亮点**：解析核心采用了预编译正则表达式（`re.compile`），并且利用 property 进行了结果缓存（cache）。高天指出这是非常值得借鉴的技巧：“就如果我们需要把某一个 Regular Expression 做很多次的 Match 的时候，我们不要一直傻傻的去玩命做 match，我们要把这个 regex 先 compile 一下，然后拿 compile 出来的东西去 match，这家伙省你不少时间。” - **命名小瑕疵**：核心转换函数 `convert` 接收两个参数：一个是 match 到的子字符串，另一个是模板里的 interpolation 对象。作者将第二个参数命名为 `i`，高天建议不要用 `i`，因为 `i` 在编程习惯中绝大多数时候代表循环变量索引（index）或整数，阅读代码时每次看到 `i.value` 都需要反应半天，极度影响可读性。内部使用 `match case` 对 `i.value` 进行匹配，如果是 `int` 就转整型，是 `float` 就转浮点数。

---

[05:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=300s) 探讨：AI 时代还需要 Code Review 吗？从装饰器设计谈接口价值

高天指出，在当前 AI 编程工具与 Linter 普及的环境下，常规代码细节错误（如缩进混乱、拼写错误、低级 Bug）几乎被扫荡一空。但 Code Review 并没有失去意义，审查的重心应该转向设计（Design）与接口（Interface）。

```mermaid flowchart TD accTitle: parse 与 conversion 类的设计分析 accDescr: 分析 parse 模拟函数与 Conversion/FormatConversion 装饰器在设计上的冗余。

subgraph ParseClass ["parse 类设计"] P1["小写类名 parse"] -->|作者意图| P2["让用户直觉上当成函数使用"] P3["当前 Python 无法为函数直接添加泛型"] -->|PEP 尚未落地| P1 end

subgraph DecoratorDesign ["装饰器设计权衡"] C1["大写类 Conversion / FormatConversion"] C2["实际只定义了 __init__ 与 __call__"] C3["未做额外校验，仅持有原函数"] C1 --> C2 --> C3 end

ParseClass -.->|设计合理: 属于妥协性 Hack| DecoratorDesign DecoratorDesign -.->|冗余: 增加认知负担| R["结论: 压根不需要此类装饰器"] ```

在审视 `tempparse` 的核心类与装饰器设计时，发现了几个关键分歧： - **小写类名 `parse`**：`parse` 明明是个类，名字却小写。这是作者的有意妥协：他希望用户把它当成一个普通函数来调用；但由于目前的 Python 版本无法直接为普通函数指定泛型参数（Guido van Rossum 提出的相关 PEP 尚未正式接受），作者必须使用带有泛型的类来模拟函数。高天认同这种为了保证类型提示（type hints）而采取的妥协性 Hack。 - **风格不一致的装饰器**：与小写 `parse` 相对，作者定义的转换装饰器却恢复了大写命名 `Conversion` 和 `FormatConversion`，在命名风格上缺乏统一。 - **装饰器存在的必要性存疑**：作者提供了一个自定义浮点数百分比转换器 `percent` 的例子（此处顺带吐槽在浮点数世界里尽量不要直接使用 `==` 做比较）。但深入思考后，这个装饰器根本没有存在的意义： - 它只定义了 `__init__` 和 `__call__`，在内部没有对被修饰函数做任何额外验证或逻辑增强。 - 在大括号里解析时，完全可以在运行时（Runtime）直接反射检查传入函数的参数个数或是否存在格式说明符（format spec），根本不需要装饰器进行标记。 - 函数本身已具备完整的类型注解，经过装饰器包装反倒未增加任何静态检查信息。 - 高天在此处给出明确判断：“所以我个人的观点是这个 conversion 跟 format conversion 在设计的时候压根就不应该存在，他们俩没有给这个项目带来足够多的价值，完全可以让用户写一个 conversion 函数，然后直接传出去就可以了。”

---

[10:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=600s) 接口一致性、直觉违背与正式项目的工程化短板

在深入探讨模板语意与 API 交互设计时，高天指出了库中存在的多处接口反直觉与不一致问题，并对比了工业级项目的必备规范：

- **输入冗余与消除歧义**：最基础的类型转换（如字符串转整数）中，用户在泛型类型注解里写了一次 `int`，在模板大括号内部又必须写一次 `{int}`。高天认为，既然外部泛型已经明确了期望返回的类型，在没有歧义的情况下，库完全应该提供默认处理逻辑，免去模板内部的重复输入。原则是“在没有歧义的选择情况下，让用户输入的东西越少越好，尤其是同样的数据，不要让用户输入两次”。 - **违背直觉的模板占位符**：在 `f-string` 或 `t-string` 的日常认知中，大括号 `{}` 内部放的应当是“被转换的变量名/数据目标”，而非“转换函数本身”。看到 `{percent}` 时，直觉会认为是提取名为 `percent` 的字段，很难第一时间意识到它是一个叫 `percent` 的转换规则。高天更推荐利用 `t-string` 原生自带的冒号格式规范（format spec）来设计，例如写成 `{:percent}`，让冒号后面承载转换函数或格式定义，这样既符合 Python 生态习惯又更加清晰明确。 - **点名批评 `json` 模块的特例破坏**： 作者在模板中支持直接写 `{json}`，内部使用 `json.loads` 将字符串转化为字典或列表。高天严肃指出这严重破坏了一致性（Consistency）： - 在此之前，所有大括号里的内容要么是一个 class，要么是一个 function，调用逻辑是将字符串“喂”给该可调用对象。 - 但 `json` 是一个 module（模块），字符串根本无法传给一个模块。作者在这里凭空发明了一个专属于 `json` 的特例规则，且模板里写 `list`、`dict` 和 `json` 的行为语义竟然完全等价。 - 如果允许写 `json.loads` 或者支持直接传入普通函数，整套体系依然保持自洽；而生造模块语义既难懂又突兀。 - **运行时类型检查（Runtime Type Check）的缺失**：既然项目在 API 设计上如此看重类型安全与泛型提示，那么在解析到 `list` 或 `dict`，乃至 `parse` 主流程输出结果时，更应该在运行时对其强制进行类型断言与检查（enforce type）。 - **工程化基础设施不健全**： - **单测无覆盖率**：项目虽然写了单元测试，但没有统计代码覆盖率（Coverage），无法衡量测试的有效性与盲区。 - **CI 流程形同虚设**：GitHub Actions workflow 里只有一个 `publish` 任务（打包上传 Wheel），没有设置任何自动跑测试、代码格式化（Format）与代码静态扫描（Lint）的步骤，代码出错难以及时拦截。

高天总结道，虽然 AI 可以帮你写出看起来工整无误的代码，但整体架构的合理性、API 设计的人机工程直觉、接口的一致性以及工程化 CI/CD 的完备度，AI 不会自动替你做全套。程序员必须在脑中始终保留这根弦，主动向 AI 提出这些高维度的架构考量，这才是 AI 时代核心竞争力的体现。

视频最后，码农高天再次热情呼吁大家参与下个月的 PyCon Taiwan，届时他将作为主题演讲（Keynote）嘉宾出席并全程在现场交流，欢迎观众前去互动。

## Notable quotes > [10:00](https://www.youtube.com/watch?v=lWbY9R8qR-w&t=600s) 在没有歧义的选择情况下，让用户输入的东西越少越好，尤其是同样的数据，不要让用户输入两次 — 码农高天

## Mentioned 码农高天, tempparse, Python, Python 3.14, t-string, PyCon Taiwan, Guido van Rossum, GitHub Actions, Wheel

## Video description 很多人会觉得AI时代，Code Review已经没有什么意义了。我们今天就一起来看一个小巧的模板解析库。研究一下在看似“规整”的代码之下，有什么是我们依然可以讨论的话题。

[Source](https://www.youtube.com/watch?v=lWbY9R8qR-w)

中文简报

【代码审查】AI时代代码审查还有意义吗？解析模板解析库案例 码农高天通过对微型开源项目 tempparse 进行代码审查，指出其巧妙利用 Python 3.14 的 t-string 特性与预编译正则缓存实现数据提取的亮点，同时也指出了参数命名为 i 等可读性瑕疵。他重点剖析了该库在接口设计上的硬伤：不仅生造了毫无逻辑增强价值的转换装饰器，还在模板中特化引入 json 模块破坏了参数一致性，并存在类型输入冗余以及违背占位符直觉等问题。此外，项目还暴露出缺乏测试覆盖率统计与自动化 CI 校验等工程化短板。高天借此得出结论：尽管 AI 能扫除低级语法漏洞，但系统架构的合理性、API 的人机工程直觉与接口自洽性，依然是 AI 时代代码审查不可替代的核心价值。 码农高天通过审查微型模板解析库 tempparse 指出，AI 时代的 Linter 与大模型已能扫除低级语法漏洞，代码审查的核心重心必须转向 API 接口一致性、直觉设计与系统架构。 (5:00) tempparse 巧妙利用 Python 3.14 的 t-string 拆解 raw string 与 interpolations，省去手写分词器，并通过预编译正则与 property 缓存提升了多轮匹配性能。 (0:00) 库中设计的 Conversion 装饰器仅包含 __init__ 与 __call__，既未增加静态检查信息也未提供额外校验逻辑，属于过度设计，完全可以直接传入函数替代。 (5:00) 该项目在 CI 中仅设置了打包发布任务，缺少自动化测试运行、覆盖率统计与静态 Lint 检查，暴露出工程化基础设施的明显短板。 (10:00)

Reading summary

码农高天通过对基于 Python 3.14 t-string 的开源项目 tempparse 进行 Code Review 指出，在 AI 与 Linter 能够解决基础编码错误的时代，代码审查的核心价值已转向整体设计、API 交互直觉、接口一致性与工程化完备度。 巧用新语言特性与性能优化技巧 (0:00) tempparse 是一个不足 170 行的微型解析库，其核心功能是根据模板字符串从目标文本中提取结构化数据，并借助泛型约束返回值类型。实现上，该项目巧妙利用了 Python 3.14 引入的 t-string 特性，直接由其内置解析器将模板拆分为原始字符串与内插对象（interpolations），省去了手写分词器的复杂度。解析引擎采用预编译正则表达式并结合 property 实现结果缓存，高天认为在需要反复匹配的场景下，预编译与缓存能大幅提升性能。不过代码也存在将所有逻辑挤在 __init__.py 中的单文件架构问题，且核心转换函数将内插对象命名为常用于循环变量的 i，影响了代码可读性。 类与装饰器设计中的权衡与冗余 (5:00) 在类与装饰器的结构设计上，作者采用了小写类名 parse。高天分析认为，由于当前 Python 尚未支持为普通函数直接标注泛型（相关 PEP 尚未落地），作者采用类来模拟函数是保证类型提示的合理妥协。然而，配套的 Conversion 与 FormatConversion 装饰器却显得多余且风格不一。这两个大写命名的装饰器仅定义了 __init__ 与 __call__，并未对传入函数增加校验或提供额外的静态类型信息。高天指出，模板解析完全可以在运行时反射检查函数的参数签名或格式说明符，无需强制用户使用无实质价值的装饰器包装函数。 API 交互直觉与一致性破坏 (10:00) 在用户交互层面，该库存在多处违背直觉的设计。用户在外部泛型声明了类型后，仍需在模板内重复写出相同类型（如 {int}），未能贯彻在无歧义时减少冗余输入的原则。同时，Python 开发者通常习惯在大括号内放置待提取的字段名，将转换规则直接写入大括号（如 {percent}）容易引起困惑，高天建议改用原生 format spec 语法（如 {:percent}）以符合生态惯例。更为严重的是特例破坏：库中支持直接传入 json 模块调用 json.loads，打破了原本占位符必须是 class 或 function 的调用规则；由于字符串无法传给模块，生造此类特例让模块与可调用对象的语义混杂，破坏了接口的一致性，且内部在输出 list 或 dict 时缺乏必要的运行时类型断言。 工程化交付标准的缺失 (10:00) 除了接口设计，高天指出了该项目在工程化基础设施上的短板。项目虽编写了单元测试，但未统计代码覆盖率，难以衡量测试的盲区与有效性；GitHub Actions 的持续集成（CI）流程仅配置了发包构建（publish），完全缺少自动化测试运行、代码格式化检查与静态代码扫描（Lint）环节，无法在代码合入前建立质量防线。 高天总结认为，AI 虽能迅速生成规范的基础代码，但无法主动规划合理的系统架构、良好的人机交互直觉、严格的接口一致性及完备的 CI/CD 流程；在 AI 编程时代，程序员必须在更高维度的架构设计层面为 AI 设定方向，这也是工程师不可替代的核心竞争力。

Source quotes

[10:00] 码农高天: 在没有歧义的选择情况下，让用户输入的东西越少越好，尤其是同样的数据，不要让用户输入两次

Original transcript

[0:00] 好,我们今天久违的做一个code review啊这个code review是上次拍抗台湾的挑战视频 欠大家的这里顺便说一下啊 拍抗台湾还有一个月就要开始了 感兴趣的同学们记得去买票今天我们要review的项目是一个很小小的项目 叫time parse首先这个名字我要稍微吐槽一下啊他这边介绍了一下这个名字是怎么来的我也可以理解但是这个名字怎么读 怎么觉得像Temp Earth就是临时的屁股就二次这个词冲击力还是太大了好 我们一样是从readme开始 看看他是干嘛的这个项目的核心就是从一个字符串里面提取一些数据我们看这里他给的例子他首先提供了一个模板在这个模板里有我们想要提取的内容然后我再提供一个字符串根据前面的模板 我把字符串里面这些内容给拿出来而在模板中大括号里的内容决定了我怎么从原始的字符串变到我想要的数据String就是保持原样Int就是把这个字符串要变成一个整数所以大家看下面提取的这个year 它就是一个数 而不是一个字不串这里他设计的比较有趣的地方是还加了一个范形啊你可以在这里去提示我返回的值是什么类型这样对类型检查之类的东西就非常友善好 那我们先看一下它的代码 然后我们回头来说一下在设计上我能想到的问题它的代码本身review起来非常轻松 因为只有一个文件他把所有的东西都放到了Init里在这个项目非常小的情况下这样做也不是不行但是我还是更推荐大家把他们分别放在不同的文件里不过市面上有一些项目也确实是这么干的在它的设计里最核心的class就是parser他这里是用了一个type variable他最后用你输入的这个类型来表示他输出的类型大家可以看到这里 这是它输出的类型这个就是一个非常经典的generics啊这样就可以规定啊我输出的类型是一个string一个int然后你把它们拆包的时候就有利于type checker去检查这类型对不对然后在这里设计的时候 它取了一个桥他用了3.14版本新引入的 string template也就是t string这个t string 它会自己先帮你parse一下parse 成 raw string 跟 interpolations也就是他把一部分parser的工作交给t string去完成了比如说例子里的这个t-string他可以直接从拍档端拿到哪些是这种raw screen哪些是你需要替换的这些模板 包括大括号里面的STR本身 他也能拿到然后它这里的选择是用regular expression去做一个整个string的match这里他提前compile了一下还把这个property给catch了这都是我们值得学习的啊就如果我们需要把某一个Regular Expression做很多次的Match的时候我们不要一直傻傻的去玩命做match我们要把这个regex先compile一下然后拿compile出来的东西去match这家伙省你不少时间Parse的部分其实也很简单他就是把每一个match的string和这个match对应的那个interpolation也就是那个模板把这两个东西成对传给convert那这个convert是什么东西呢convert在这里啊他一共take两个argument第一个是已经match上了那个string也就是刚才例子里的 Tokyo还有2010第二个就是这个 interpolation也就是原来模板是长什么样的这里我有一个建议啊这个argument最好不要叫I 用s来表示string这个事很常见但是 i 这个字母 它太常被用来做index了有些时候还被当成Integ用所以我每一次后面看那个爱点什么的时候 我脑子都要反应半天这里为了可读性 建议改一下啊那这个I点value是什么就是大括号里面的东西做完evaluation的那个值在这个例子里就是string class 注意还有就是int class 下面用了一个match case然后int对应的就是这个 如果origin是int他就把这个string给变成一个integer下面这些简单的case也是如果是float就变float对吧 complex就变complex整个代码就不到170号完成了一个挺有趣的小功能说实话现在在AI的加持下我们已经很难像原来的code review那样去找很多细节上的小问题因为现在AI加Lint [5:00] 很多细节上那种比较蠢的问题它都不存在了但是有了AI之后code review就没有意义了吗我们在code review的时候还能找出来什么东西去值得聊今天我们就从项目的角度来看一看code review还能review什么首先我们看一下刚才没有提到的这个parse class肯定有的朋友一看这里就觉得不对这个parse为什么是小写呢它是一个class这里其实应该是作者故意设计成这样的因为作者希望用户的概念里把这个parse当成一个函数当成一个function我们也可以看作者提供的用法实际上这个parse完全就是一个function那为什么还要把它设计成一个class呢这里作者其实提到了原因就是在现在的python版本里我们没有办法给函数直接加范形那这个功能像有一个pip是硅度本人提出的这个PAP应该还没有被接受所以为了实现上面这样的用法他就必须把这个PARSE变成一个class那他这种形式实际上我是认同的就他为了保这个type in去做一些看起来有点奇怪的这个hack好 那问题来了这个conversion它是个decorator对吧为什么到了decorator这块又变成了一个正常的大写开头的class了呢就我觉得这个东西好像还是应该小写比较合适当然如果你这块压根就没看懂它这个decorator是怎么工作的你就应该翻一下我们之前去讲decorator的视频啊就你会发现他整个这套东西的设计非常简单好像跟decorator毫无关系他只定义了一个init和一个call这个class是怎么变成一个decorator的呢那只要你能成功的把我圈起来的这个部分改写一下你就知道他是怎么工作的了那下面还有一个format conversion专门针对这种带format的情况好看到这你可能觉得这两个设计有点意思它的核心用法也给出了一个例子比如他这定义了一个percent函数就是我把这种百分号的string可以转换成这种float看起来没有问题对吧除了这个等号等号不太好就我们在福点数的世界里尽量不要写等号等号但是抛去这个我们看这个设计好像挺有趣的但是我们现在退一步我们从一个design或者interface的角度去看这个问题这个decorator给我带来了任何东西吗我们如何转换完全是由大括号里面这个东西决定的大括号里面是percent我就会在全局找一个叫percent的函数然后我把30%这个string给进percent用percent这个函数转换成float再拿到这个float在这个过程中conversion起到任何作用了吗那在我能想到的空间里面它起到了两个作用第一它显示的规定了这个percent是一种convert的方式这样在我们真的做convert的时候我们可以去match这个case第二和这个format conversion相比它规定了函数这个argument的数量有没有spec但是我们注意一下我们其实根本就不需要显示的规定这个函数是一个conversion呢我这给了什么函数拿什么函数转换不就行了吗因为你这的conversion函数里也没有做任何的检查它单纯的就是把原始的函数保留住了然后等会再扔出来那从type check的角度这样其实它也没有给出任何额外的信息因为你原来这个函数就是有type check的那至于一个函数argument的数量或者是有没有给这个format我们都完全可以在运行时的时候直接知道我们是可以看这个函数有几个argument的所以我个人的观点是这个conversion跟format conversion在设计的时候压根就不应该存在他们俩没有给这个项目带来足够多的价值完全可以让用户写一个conversion函数然后直接传出去就可以了好那我们回头再看这个最简单最基础的例子我们会发现这个string出现了两次这个int也出现了两次也就是我要把这个数转换成整数这么常见的情况我竟然要写两次int前面的这个generics它是为了type checker服务的它可能是必须要有的但是里面这个东西也必须要有吗我既然已经在type pin上面写了我要返回什么值我可不可以有一个默认的方式大家看如果我的输入是这个样子的是不是应该也没有奇异而这个是一个非常常见的案例我们在设计interface的时候就应该想在没有奇异的选择 [10:00] 情况下让用户输入的东西越少越好尤其是同样的数据 不要让用户输入两次然后自定义转换的这个部分说实话 如果是我的话 不太会这么设计因为我们在F-String也好 T-String也好这个大括号里面的内容 一般是表示我们要转换什么变量不管是正着来还是反着来我们总觉得这个大括号里面的东西对应的就应该是这个street就如果我不熟悉你的这个library我脑海中的直观印象一定是 30%对应的是一个percent我不会想到的是percent是转换30%的方式这个其实是对语言的敏锐程度直觉是什么样的所以我刚开始在读readme的时候这大括号里面是什么东西我其实一直没搞明白我是读了半天code之后我才知道是这么回事那我相信可能有些朋友视频看到现在其实也没在搞明白大括号里面为什么是这么个东西如果是我设计的话我可能会设计成这个样子因为t string这个东西本身已经提供了format spec了就是它自动会把这个冒号后面的东西给parse出来冒号后面这个东西是代表格式的转换的它可以是某一个字母代表某种转换也可以是你自定义的任何的东西那你就可以定义一下 这样就代表我用这个函数来转换这个string然后你可以自己再设计一些小的东西 让它更明确一些比如你这后面加个括号什么的这可以自己想啊我会觉得把percent直接扔在这块稍微点怪那最后呢 我还想说一个他支持相关的问题啊 这个是consistency的问题也很重要就是你这个interface提供的用户之后它的一致性要好就当用户好不容易理解了你这套逻辑的时候他顺着你的逻辑应该能明白你这东西是怎么回事在这里我就需要点名批评JSON这个JSON什么意思呢 我给大家写一下它大概是这么个意思就他把JSON扔到大括号里然后他用JSON loadS来把这个string变成一个dictionary或者变成一个list那这里大家就会看得非常懵对不对因为之前你设计的所有方案这个大括号里面都是一个class或者是一个function我在脑海里我把这个字符串直接喂给class或者喂给function就得到了我想要的那个东西我们不管这个设计的方案好与不好它最起码是一致的是consistent的但现在这个JSON是什么这个JSON是一个module对不对你是没有办法把一个Stream feed 到这个module里的这个设计就相当于你自己重新又开辟了一个语意这个语义是哪都没有的 自己发明的你就说我把JSON这个module放在这儿就相当于要变成一个dict或者list我觉得这里如果你是用JSON.loads都会好非常多你甚至不用专门给他规定一个语义如果你用了我刚才那个干掉conversion的那个decorator的那个方案的话你直接把这项点漏的S写在这就可以了他就会自动的把这个string feed 进去对不对就我们回过头看他这段原代码你就会觉得非常奇怪 对吧它跟前面代码长得都不一样它是一个完全自己编出来的特例而且list dict和json的语义一模一样 也是稍有点奇怪这里我觉得如果你支持List和Dict的话你还是应该做一些run time的type check我们说到这个Runtime的TypeCheck其实我觉得Parse应该也做一下type check你既然都这么在意type这个事情了这里inforce一下type我觉得可能是更好的我们最后再说一点一个正式项目还需要什么作为一个小项目来说它在根目录下的东西差不多差不多测试是有的 但是没有coverage如果你没有coverage data 你就不知道你的测试写的够不够GitHub workflow这边只有一个publishpublish就是上传这个wills也是没有任何的测试啊 lint啊format都没有万一你这个程序出错了其实你就压根不知道对吧所以如果你是想做一个正经的项目你的CI肯定还是要做起来所以大家可以看到 现在有了AI的存在 确实我们编程小细节上的问题越来越少了比如什么缩近有问题 变量名的格式不对就这些零七八错的问题已经很少了你的代码看起来都是挺靠谱的代码但是从项目的角度说 我们依然有大量可以review的问题我们的design 我们的interface 我们的CI 有很多东西是我们可以去思考 可以去改进的 [15:00] 这些东西AI能做吗或许能做 但他肯定不是自动做的就不是你说给我写一个这个项目他就把我刚才说的那些东西全都给做了你依然脑子里面却有这根弦你需要不断的跟他去沟通 不断的去提示他他可能会在这方面有有价值的见解但是你有没有这个意识去跟他沟通这件事情这个就是作为程序员值得培养的能力了那在视频的最后依然提醒一下大家啊这个PACON台湾下个月就要开始了感兴趣的一定要记得美票这次拍康台湾我会作为Keynote的嘉宾去然后也全程都会在现场跟大家沟通交流也是欢迎大家来找我玩啊好 那这期视频这里 希望大家介绍关注 别忘了一件 再见咯