← Asztali alkalmazás fejlesztők adatlapja

Skill · 1.0.0 verzió

Duplikációk és absztrakciók vizsgálata

Közös segédfüggvény előtt megkülönbözteti az ismételt üzleti szabályt a véletlen kódhasonlóságtól.

duplication-abstraction-review

Ezt a skillt használó csapattagok

Nézd meg, miben segít

Mikor hasznos?

Akkor használd, ha hasonló függvények vagy képernyők összevonásáról döntesz.

Miben segít neked?

  • Megvizsgálja, ugyanazon üzleti okból kell-e együtt változniuk a másolatoknak.
  • Megkeresi az eltérő számítást vagy jogosultságot okozó szabályismétlést.
  • Külön hagyja az önálló folyamatokat, ha a megosztás sok kapcsolót igényelne.

Például ezt kérheted

Hasonlítsd össze az ajánlat- és számlaszámítást, csak a valóban közös szabályokat emeld ki. Kis próbában módosítsd a közös kerekítési szabályt. Mutasd meg, mely fogyasztóknak kell tényleg együtt változniuk, és melyek csak szerkezetileg hasonlóak.

Részletes dokumentáció

Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.

Részletek…Összecsukás

Duplication & Abstraction Review

Not all code repetition is the same, and not every abstraction improves maintainability. Follow Sandi Metz's maxim: duplication is far cheaper than the wrong abstraction. Before extracting a shared helper or base class, determine whether the repeated code represents a single domain rule or merely a temporary coincidence of shape.

1. Essential vs. Accidental Duplication

Classify repeated code by why it changes (Single Source of Truth), not just how similar the lines look today:

  • True (Essential) Duplication — Consolidate:
    • The same business calculation, permission check, state transition rule, tax/discount formula or retry policy is copy-pasted across multiple places.
    • Whenever that business rule changes, every copy must change identically or the system becomes inconsistent.
    • Action: extract into a single, well-named domain function or policy module and route all call sites through it.
  • Accidental (Coincidental) Similarity — Keep Separate:
    • Two forms, DTOs, controllers or view components happen to have three similar-looking fields or steps today, but belong to independent workflows or domain concepts that evolve on different schedules.
    • Action: keep them independent. Coupling two unrelated features through a shared abstraction forces every future change in one feature to thread conditional flags through the other.

2. Rule of Three & Evidence-Driven Extraction

  • Wait for concrete cases: resist building a generic framework, plugin registry or multi-layer inheritance hierarchy from a single use case or two slightly different callers.
  • Extract what is genuinely shared: when three or more concrete occurrences share an invariant, extract the pure common mechanism (as a composable function or narrow collaborator) while letting each caller pass its specific policy or configuration explicitly.
  • Prefer composition and data over inheritance: favor plain functions, parameter objects and small strategy callbacks over deep base-class hierarchies (BaseController -> AbstractCrudController -> AuditedResourceController) that hide control flow across parent/child methods.

3. Healing the Wrong Abstraction

When you encounter an existing shared function or class that has accumulated boolean mode flags (processItem(data, isLegacy, skipValidation, forExport, useV2)), caller-type switches and partial overrides:

  1. Re-inline (Unroll) the abstraction: copy the relevant code back into each caller or specialized path and delete the branches that do not apply to that specific caller.
  2. Simplify each path independently: remove dead parameters and redundant conditionals once each caller only contains the logic it actually executes.
  3. Re-extract narrow, honest helpers: if a smaller, genuinely identical pure calculation remains across the simplified paths, extract just that cohesive helper without the conditional tangle.

Csomagban lévő fájlok 1

  • SKILL.md