• صفحه اصلی
  • درباره من
  • مهارت‌های ایجنت
  • پروژه‌ها
  • بلاگ
  • مشاوره
  • تماس با من
مشاورهرزومه
مهارت‌های ایجنت‌های برنامه‌نویسی/معماری/بازبینی Over-Engineering و Abstractionهای اضافی

بازبینی Over-Engineering و Abstractionهای اضافی

کد TypeScript/React را برای abstraction زودهنگام، wrapperهای بی‌ارزش و pattern abuse بررسی کن و با حفظ رفتار، ساختار را بر اساس YAGNI و Clean Code ساده کن.

typescriptreactclean-codeyagnirefactoringarchitecture

راهنمای نصب Skill

فایل SKILL.md را دانلود کنید و در مسیر مخصوص ایجنت موردنظرتان قرار دهید. پیشنهاد می‌کنیم پیش از فعال‌سازی، محتوای کامل فایل و سطح دسترسی آن را بررسی کنید.

Codex

~/.codex/skills/abstraction-overengineering-review/SKILL.md

Claude Code

.claude/skills/abstraction-overengineering-review/SKILL.md

Cursor

.cursor/skills/abstraction-overengineering-review/SKILL.md

GitHub Copilot

.github/skills/abstraction-overengineering-review/SKILL.md
</>مشاهده محتوای خام SKILL.mdفقط دستورالعمل‌هایی را ببینید که ایجنت برنامه‌نویسی دریافت می‌کند؛ بدون عنوان، تگ و متادیتای کاتالوگ.
فایل منبع: abstraction-overengineering-review/SKILL.md
---
name: "abstraction-overengineering-review"
description: "کد TypeScript/React را برای abstraction زودهنگام، wrapperهای بی‌ارزش و pattern abuse بررسی کن و با حفظ رفتار، ساختار را بر اساس YAGNI و Clean Code ساده کن."
---

# بازبینی Over-Engineering و Abstractionهای اضافی

این Skill را وقتی فعال کن که codebase برای تغییرات ساده به لایه‌ها، factoryها، genericها یا wrapperهای زیادی نیاز دارد و باید بدون بازنویسی نمایشی ساده شود.

## Workflow

1. مسیر واقعی یک use case را از UI تا dependency نهایی دنبال کن.
2. هر لایه را با مسئولیت و ارزش مستقل آن ثبت کن.
3. wrapperهایی را پیدا کن که فقط نام API زیرین را تکرار می‌کنند.
4. abstractionهایی را که فقط یک implementation و یک مصرف‌کننده دارند بررسی کن؛ وجود یک مورد به‌تنهایی دلیل حذف نیست، اما باید ارزش مشخص داشته باشد.
5. genericهایی را که inference و خوانایی را بدتر کرده‌اند علامت بزن.
6. ساده‌ترین مسیر مستقیم را طراحی کن و behavior را حفظ کن.
7. refactor را مرحله‌ای انجام بده و بعد از هر مرحله type-check/test کن.

## شواهد معتبر برای حذف abstraction

- تغییر ساده باید همزمان در چند لایه pass-through انجام شود؛
- interface هیچ policy یا contract مستقلی ایجاد نمی‌کند؛
- wrapper فقط argumentها را بدون معنا forward می‌کند؛
- generic برای سناریوهای فرضی ساخته شده و مصرف واقعی ندارد؛
- pattern فهم جریان داده را سخت‌تر از implementation مستقیم کرده است.

## Guardrail

کد مشترک سالم، boundary امنیتی، adapter واقعی سرویس خارجی یا contract تست‌پذیر را فقط برای کم‌کردن تعداد فایل‌ها حذف نکن. هدف کمترین تعداد لایه نیست؛ هدف کمترین پیچیدگی لازم برای نیاز واقعی است.

## خروجی

برای هر finding بنویس:

```text
Abstraction:
Current value:
Observed cost:
Keep / Simplify / Remove:
Smallest safe change:
Validation:
```

در پایان تعداد abstractionهای حذف یا ساده‌شده، behavior حفظ‌شده و مواردی را که عمداً نگه داشته‌ای توضیح بده.

این Skill را وقتی فعال کن که codebase برای تغییرات ساده به لایه‌ها، factoryها، genericها یا wrapperهای زیادی نیاز دارد و باید بدون بازنویسی نمایشی ساده شود.

Workflow

  1. مسیر واقعی یک use case را از UI تا dependency نهایی دنبال کن.
  2. هر لایه را با مسئولیت و ارزش مستقل آن ثبت کن.
  3. wrapperهایی را پیدا کن که فقط نام API زیرین را تکرار می‌کنند.
  4. abstractionهایی را که فقط یک implementation و یک مصرف‌کننده دارند بررسی کن؛ وجود یک مورد به‌تنهایی دلیل حذف نیست، اما باید ارزش مشخص داشته باشد.
  5. genericهایی را که inference و خوانایی را بدتر کرده‌اند علامت بزن.
  6. ساده‌ترین مسیر مستقیم را طراحی کن و behavior را حفظ کن.
  7. refactor را مرحله‌ای انجام بده و بعد از هر مرحله type-check/test کن.

شواهد معتبر برای حذف abstraction

  • تغییر ساده باید همزمان در چند لایه pass-through انجام شود؛
  • interface هیچ policy یا contract مستقلی ایجاد نمی‌کند؛
  • wrapper فقط argumentها را بدون معنا forward می‌کند؛
  • generic برای سناریوهای فرضی ساخته شده و مصرف واقعی ندارد؛
  • pattern فهم جریان داده را سخت‌تر از implementation مستقیم کرده است.

Guardrail

کد مشترک سالم، boundary امنیتی، adapter واقعی سرویس خارجی یا contract تست‌پذیر را فقط برای کم‌کردن تعداد فایل‌ها حذف نکن. هدف کمترین تعداد لایه نیست؛ هدف کمترین پیچیدگی لازم برای نیاز واقعی است.

خروجی

برای هر finding بنویس:

Abstraction:
Current value:
Observed cost:
Keep / Simplify / Remove:
Smallest safe change:
Validation:

در پایان تعداد abstractionهای حذف یا ساده‌شده، behavior حفظ‌شده و مواردی را که عمداً نگه داشته‌ای توضیح بده.

مشخصات Skill

نسخه
1.0.0
آخرین تغییر
2026-09-10
دسته‌بندی
معماری
سطح پیچیدگی
پیشرفته
مجوز
MIT
نویسنده
Naser Rasouli

سطح دسترسی و اجرا

امکان اجرای اسکریپتندارد
دسترسی شبکهندارد

مقاله منبع

برای توضیح عمیق‌تر مفاهیم، زمینه و مثال‌ها، مقاله‌ای را بخوانید که این Skill از آن ساخته شده است.