#代码优化

OpenAI 写了一个PDF,分享内部成员,如何用Codex,场景不局限于编程。 包括笔记整理、画原型、时间管理等等。 PDF下载: 核心场景 ① 代码理解:快速定位核心逻辑、服务关系、数据流,帮新人快速上手和查Bug。 ② 重构与迁移:批量修改、结构优化、迁移依赖,提升一致性和可维护性。 ③ 性能优化:发现瓶颈、优化循环和数据库操作,减少技术债务。 ④ 测试覆盖:自动生成单元测试、边界Case测试。 ⑤ 开发提速:自动生成脚手架、API、配置文件。 ⑥保持专注:发现没完成的工作、转笔记为原型,碎片化时间管理。 ⑦ 探索与创意:尝试不同实现方案,验证设计决策,发现潜在问题。 最佳实践 ① 结构化提问:像写 GitHub Issue 或 PR 一样描述需求,包含文件路径、组件名、差异、文档片段等。 ② 分步迭代:先用 Ask Mode 生成计划,再用 Code Mode 写代码,减少错误。 ③ 环境配置:设置启动脚本、环境变量、联网权限,持续优化 Codex 开发环境。 ④ 任务队列:用 Codex 记录灵感、工作清单等,无需一次性完成全部任务。 ⑤ 上下文维护:维护 文件,补充命名规范、业务逻辑、依赖等,提升 Codex 理解力。 ⑥ 多方案对比:一次生成多种解决方案,挑选或组合最佳结果。 典型提问示例 “这个仓库的认证逻辑在哪里实现?” “把所有回调式数据库访问改为 async/await。” “优化这个循环的内存效率,并解释原因。” “为这个函数生成包含边界情况的单元测试。” “根据这个产品反馈生成初步实现代码。”
WquGuru🦀
1个月前
分享一个Claude Code全局提示词(也适用于Augment/Cursor等等),有架构师附身之奇效: ## Code Architecture - 编写代码的硬性指标,包括以下原则: (1)对于 Python、JavaScript、TypeScript 等动态语言,尽可能确保每个代码文件不要超过 200 行 (2)对于 Java、Go、Rust 等静态语言,尽可能确保每个代码文件不要超过 250 行 (3)每层文件夹中的文件,尽可能不超过 8 个。如有超过,需要规划为多层子文件夹 - 除了硬性指标以外,还需要时刻关注优雅的架构设计,避免出现以下可能侵蚀我们代码质量的「坏味道」: (1)僵化 (Rigidity): 系统难以变更,任何微小的改动都会引发一连串的连锁修改。 (2)冗余 (Redundancy): 同样的代码逻辑在多处重复出现,导致维护困难且容易产生不一致。 (3)循环依赖 (Circular Dependency): 两个或多个模块互相纠缠,形成无法解耦的“死结”,导致难以测试与复用。 (4)脆弱性 (Fragility): 对代码一处的修改,导致了系统中其他看似无关部分功能的意外损坏。 (5)晦涩性 (Obscurity): 代码意图不明,结构混乱,导致阅读者难以理解其功能和设计。 (6)数据泥团 (Data Clump): 多个数据项总是一起出现在不同方法的参数中,暗示着它们应该被组合成一个独立的对象。 (7)不必要的复杂性 (Needless Complexity): 用“杀牛刀”去解决“杀鸡”的问题,过度设计使系统变得臃肿且难以理解。 - 【非常重要!!】无论是你自己编写代码,还是阅读或审核他人代码时,都要严格遵守上述硬性指标,以及时刻关注优雅的架构设计。 - 【非常重要!!】无论何时,一旦你识别出那些可能侵蚀我们代码质量的「坏味道」,都应当立即询问用户是否需要优化,并给出合理的优化建议。