mcpField
S
simple-engineering

simple-engineering

github.com/robot-inventor开发371 次安装2 天前更新
代码仓库

关于 simple-engineering

一项引导开发者采用简单且必要实现的软件工程技能,强调比较方案、复用现有代码或库,并检查改动以剔除无谓复杂性。

主要功能

  1. 01优先选择清晰精简的方案
  2. 02避免多余验证与错误处理
  3. 03复用项目代码和依赖
  4. 04遵循 YAGNI 并控制范围
  5. 05逐行审查差异
  6. 06重构并移除过时代码

适用场景

  1. 01为功能选择更简单的实现方式
  2. 02避免添加重复验证逻辑
  3. 03确认依赖是否已有所需功能
  4. 04交付前精简不必要的改动

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/robot-inventor/agent-skills --skill simple-engineering

安装后在 Claude Code 中输入/simple-engineering确认已加载。

详细介绍

简洁工程

保持简单优雅

过度设计是一种可耻又愚蠢的行为,因此始终追求简单优雅的解决方案至关重要。

在实现功能或修复错误之前,请考虑所有选项。不要只罗列相似的选择,也不要受先入之见和以往思路的束缚,而应考虑所有选项,包括截然不同的方法。在可用选项中,选择最清晰、最简单、代码行数最少且满足用户需求的方案。修补破衣服没必要用铁板和钉子。选择恰到好处的简单方案,而不是规模过大、过于复杂的方案。

还要避免给代码带来不必要的复杂性。仔细检查相关处理,确保不存在不可能执行的条件分支或不必要的 try-catch 块。检查类型定义和实际处理逻辑,移除任何不可能执行的条件分支。如果异常在正常情况下不太可能发生,或者被调用的函数内部已经有 try-catch,就没必要再用新的 try-catch 块包裹代码。

指出过度验证、过度防御式实现、不必要的中间表示,以及不符合代码预期用途的多余复杂性。例如,用于打开特定网站商品链接的函数可能只需验证主机名。检查路径名可能会增加复杂性,却无法提升安全性。你也可以将函数参数定义为 https://example.com/product/{string} 这样的类型来减少验证,或者只接受商品 ID,并在函数内部构造链接。这些只是示例,但你应寻找同类功能更简单的实现方式。想想代码的用途是什么,以及实现是否只包含该用途所需的内容。

避免重复造轮子

应避免重复造轮子。添加代码之前,先检查项目中的现有代码或项目依赖是否已提供覆盖全部或部分处理需求的功能。实现复杂处理时,调查是否存在能够实现同等功能且广受欢迎、维护良好的库;如果有,应向用户建议使用它。

只保留必要的更改

牢记 YAGNI(你不会需要它)原则。不要仅仅因为将来可能用到,就引入复杂性。对于尚未发布的功能,也没必要维护向后兼容性。

最终交付给用户的代码应确保每一行改动都是必要的,不留任何多余代码。仔细逐行而不是逐文件检查差异,确保所有更改都确有必要。

保持代码库整洁

编写代码不等于只是在现有代码上添加内容。移除不再需要的代码。避免将语义不同的代码强行添加到现有代码中;应根据需要拆分代码并进行重构,包括重新设计,以保持代码整洁。

不要只在特殊时期才进行重构;如果当前更改范围内存在设计不佳的部分,且可在日常工作中通过小规模重构解决,就应主动重构。不过,进行大规模重构之前,应先征得用户明确许可。

DRY 原则与可修改性

牢记 DRY 原则和可修改性。避免重复定义同一内容,而应力求让代码易于修改,使单处更改就能自动更新所有相关处理。例如,在 i18n 方面,理想做法是将可用语言及其标签统一管理在一处,这样添加或移除语言时,只需更新该处并添加或移除相应的翻译文件。

评论

支持 Markdown