用途
该技能为以质量为核心的软件开发与架构提供指导，基于整洁架构（Clean Architecture）和领域驱动设计（Domain Driven Design）原则。当用户需要编写代码、设计架构、分析代码时可以使用。
代码风格规则
通用原则
- 早返回模式：尽可能使用早返回，而不是嵌套条件，以提升可读性。
- 通过创建可复用的函数和模块来避免代码重复。
- 将超过 80 行的组件和函数拆分为多个更小的组件和函数。如果它们无法在其他地方使用，就保留在同一文件中；但如果文件超过 200 行代码，则应拆分为多个文件。
- 尽可能使用箭头函数而不是函数声明。
最佳实践
库优先方法
- 在编写自定义代码之前，始终先搜索现有解决方案。
- 检查 npm 上是否有解决该问题的现有库。
- 评估现有的服务/SaaS 解决方案。
- 考虑为常见功能使用第三方 API。
- 使用库而不是自己编写工具或辅助函数。例如，使用 cockatiel 而不是自己编写重试逻辑。
当自定义代码确实合理时：
- 领域特有的具体业务逻辑
- 有特殊要求的性能关键路径
- 外部依赖会显得过度时
- 需要完全控制的安全敏感代码
- 经过充分评估后现有解决方案仍不满足需求时
架构与设计
整洁架构与 DDD 原则
- 遵循领域驱动设计和统一语言（ubiquitous language）。
- 将领域实体与基础设施关注点分离。
- 保持业务逻辑独立于框架。
- 清晰定义用例并保持其隔离。
命名约定
- 避免通用名称：utils、helpers、common、shared。
- 使用领域特定名称：OrderCalculator、UserAuthenticator、InvoiceGenerator。
- 遵循限界上下文（bounded context）命名模式。
- 每个模块应有单一、明确的目的。
关注点分离
- 不要将业务逻辑与 UI 组件混在一起。
- 不要让数据库查询出现在控制器中。
- 在上下文之间保持清晰边界。
- 确保职责得到恰当分离。
需要避免的反模式
NIH（Not Invented Here，非我发明）综合征
- 已有 Auth0/Supabase 时不要构建自定义认证。
- 不要自己编写状态管理而不使用 Redux/Zustand。
- 不要自己创建表单验证而不使用成熟库。
糟糕的架构选择
- 将业务逻辑与 UI 组件混合。
- 数据库查询直接写在控制器中。
- 缺乏清晰的关注点分离。
通用命名反模式
- utils.js 中塞入 50 个不相关的函数。
- helpers/misc.js 作为杂物堆放处。
- common/shared.js 用途不明确。
请记住：每一行自定义代码都是需要维护、测试和文档的负担。
代码质量
- 使用带类型的 catch 块进行恰当的错误处理。
- 将复杂逻辑拆分为更小、可复用的函数。
- 避免深层嵌套（最多 3 层）。
- 尽可能保持函数聚焦且少于 50 行。
- 尽可能保持文件聚焦且少于 200 行代码。
适用场景
适用于编写代码、设计软件架构、分析代码等需要以质量为核心的开发场景，尤其适合希望遵循整洁架构与领域驱动设计原则的项目。
限制
资料未提供该技能的具体安装方式、支持的平台、收费情况或价格信息，暂未提供。