17370845950

Python可通过封装、配置分离、协议抽象和结构化输出等习惯自然预留扩展空间：函数/类拆分逻辑、关键字参数、配置外置、鸭子类型+Protocol、日志/异常/返回值设计均服务于“改得少、错得少、读得懂”。

Python 本身不强制要求你为未来需求做设计，但通过合理的习惯和结构，可以自然地预留扩展空间。关键不是预测未来，而是让代码在变化来临时，改得少、错得少、读得懂。

用函数和类封装行为，而不是写一长串脚本

把逻辑拆成小单元，比如“读配置”“发请求”“存结果”，每个功能独立成函数或方法。未来要加新格式支持（如从 JSON 改成 YAML），只需改一个函数，不影响其他部分。

• 避免把所有逻辑堆在 if __name__ == "__main__": 里
• 函数参数尽量用关键字参数（def process(data, timeout=30, retry=True)），方便以后加新选项而不破坏调用
• 类的接口保持稳定：内部实现可换，但方法名和输入/输出约定别轻易动

配置与代码分离

把可能变的东西（如 API 地址、重试次数、路径）抽到配置文件（config.py 或 settings.toml）或环境变量里。下次要换环境或调试，不用翻代码，直接改配置。

• 用 os.getenv("API_TIMEOUT", "30") 代替硬编码 30
• 配置项命名清晰，比如 MAX_RETRY_ATTEMPTS 比 retry 更易理解意图
• 加个简单校验（如类型、范围），提前暴露配置错误，而不是运行到一半才崩

留好接口缝：鸭子类型 + 协议（Protocol）或抽象基类（ABC）

当不确定未来会接入什么数据源或处理器时，先定义“它该能做什么”，而不是“它必须是什么类”。Python 的鸭子类型天然支持这点，配合 typing.Protocol 可让 IDE 和类型检查器也帮上忙。

• 例如定义 class DataReader(Protocol): def read(self) -> dict: ...，之后无论是 CSVReader 还是 DBReader，只要实现 read 就能传进去
• 不用一开始就写 ABC，等真出

  

  现两个以上相似实现时再抽象，避免过早设计
• 函数参数类型注解用协议而非具体类，比如 def load(reader: DataReader)

日志、异常和返回值留出观察点

未来需求常来自“出了问题怎么查”或“要统计什么”。提前打点日志、区分异常类型、让函数返回结构化结果（比如字典或 dataclass），比事后补救容易得多。

• 关键步骤加 logger.info("Fetched %d items from %s", count, source)，而不是只在出错时才记
• 自定义异常（如 class ValidationError(Exception)），比全用 ValueError 更利于后续捕获和处理
• 函数别只返回 True/False，考虑返回 {"success": True, "data": ..., "warnings": [...]}，给后续加字段留余地