2.5 KiB
2.5 KiB
BlogFlare 项目规则
包管理器
- 统一使用
pnpm,禁止使用npm或yarn。 - 运行一次性脚本时,使用
pnpm dlx而不是npx。 - 安装依赖时,使用
pnpm install或pnpm add。
质量保障与 CI 检查
- 修改代码后必须运行本地检查,尤其是 Svelte 组件或 TypeScript 文件。
- 必须运行
pnpm run check && pnpm run lint,并确保 0 错误、0 警告。 - 没有实际运行并通过这些检查,不得宣布任务完成。
核心原则
- 渐进式开发优于大爆炸式开发:小步提交,每次都能编译通过和测试通过。
- 从现有代码学习优于重新发明:先研究和规划,再开始实现。
- 务实而非教条:适应项目实际情况。
- 明确意图优于聪明代码:选择简单明了的解决方案,不使用聪明技巧。
- 保持简单:不要过度设计,避免过早抽象;如果需要额外解释,说明设计已经太复杂。
- 单一职责:每个函数/类只承担一项职责。
- 控制复杂度:注意圈复杂度,代码尽可能复用。
- 遵循 RESTful 原则:涉及 API 的地方要遵循 RESTful 设计。
- 使用中文:始终使用中文回复,代码注释也一律使用中文。
新需求流程
- 首次沟通不急于编码:当用户提出新需求时,先进行方案讨论。
- 使用 ASCII 图表:必要时绘制多个方案对比图,让用户选择最佳方案。
- 用户确认后再开发:只有用户明确确认方案后,才开始具体的开发工作。
实施过程
- 理解现有模式:研究代码库中的 3 个相似功能/组件。
- 识别通用模式:找出项目约定和模式。
- 遵循现有规范:使用相同的库/工具,遵循现有测试模式。
- 分阶段实现:将复杂工作分解为 3-5 个阶段。
卡住时(关键规则)
最多尝试 3 次后必须停止:
- 记录失败内容(尝试了什么、具体错误、失败原因)。
- 研究替代方案(找 2-3 个类似实现)。
- 质疑基本假设(抽象层次对吗?能分解成更小问题吗?)。
- 尝试不同角度(不同库/框架?不同架构模式?移除抽象?)。
决策框架优先级
- 可测试性:是否容易测试?
- 可读性:6 个月后还能理解吗?
- 一致性:是否符合项目模式?
- 简洁性:是否是最简单的可行方案?
- 可逆性:后续修改的难度?