By Piotr Sikora

  • Development

  • 28 January 2026

DRY, WET, AHA: Znajdowanie właściwej równowagi w ponownym użyciu kodu

Każdy developer uczy się "Don't Repeat Yourself" (Nie powtarzaj się) na początku kariery. Ale jak większość zasad, stosowanie jej dogmatycznie może przynieść więcej szkody niż pożytku. Przyjrzyjmy się trzem filozofiom wokół duplikacji kodu i kiedy każda ma sens.

DRY: Don't Repeat Yourself

Zasada DRY mówi, że każdy fragment wiedzy powinien mieć pojedynczą, jednoznaczną reprezentację w twoim systemie. Kiedy zauważasz zduplikowany kod, wyciągasz go do współdzielonej funkcji, klasy lub modułu.

// Przed: powtórzenie
function calculateUserTotal(user) {
  return user.items.reduce((sum, item) => sum + item.price * 1.23, 0);
}

function calculateGuestTotal(guest) {
  return guest.items.reduce((sum, item) => sum + item.price * 1.23, 0);
}

// Po: DRY
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price * 1.23, 0);
}

Korzyści: Mniej bugów (napraw raz, naprawione wszędzie), łatwiejsze utrzymanie, mniejsza baza kodu.

Pułapka: Developerzy często łączą kod, który wygląda podobnie, ale służy różnym celom. Kiedy wymagania później się rozjeżdżają, abstrakcja staje się splątanym bałaganem warunków.

WET: Write Everything Twice

WET jest czasem żartobliwie rozwijane jako "We Enjoy Typing" (Lubimy pisać) lub "Write Every Time" (Pisz za każdym razem), ale jego prawdziwe znaczenie jest bardziej subtelne: nie abstrahuj, dopóki nie zobaczysz wzorca co najmniej dwa razy.

Idea jest prosta — duplikacja jest tańsza niż zła abstrakcja. Za pierwszym razem, gdy coś piszesz, nie wiesz, czy będzie ponownie użyte. Za drugim razem zaczynasz widzieć wzorzec. Dopiero wtedy powinieneś rozważyć wyciągnięcie współdzielonej logiki.

// Pierwsze wystąpienie: po prostu to napisz
function processOrder(order) {
  const tax = order.subtotal * 0.23;
  // ...
}

// Drugie wystąpienie: nadal OK zduplikować
function processRefund(refund) {
  const tax = refund.amount * 0.23;
  // ...
}

// Trzecie wystąpienie: teraz rozważ abstrakcję
function calculateTax(amount) {
  return amount * 0.23;
}

Korzyści: Unika przedwczesnej abstrakcji, utrzymuje kod prostym, łatwiej zrozumieć każdą funkcję w izolacji.

AHA: Avoid Hasty Abstractions

Wymyślone przez Kenta C. Doddsa, programowanie AHA idzie dalej niż WET, podkreślając że powinieneś optymalizować pod zmiany, nie pod redukcję duplikacji.

Kluczowy wgląd: zduplikowany kod jest łatwy do zrefaktoryzowania później, ale zła abstrakcja jest bolesna do cofnięcia. Kiedy przedwcześnie łączysz dwa podobne fragmenty kodu, sprzęgasz ich ewolucję. Kiedy jeden musi się zmienić niezależnie, albo dodajesz brzydkie warunki, albo boleśnie rozplątasz abstrakcję.

AHA sugeruje, żebyś zadał sobie pytanie: "Czy te naprawdę muszą zmieniać się razem?" Jeśli nie, duplikacja może być lepszym wyborem.

// Wygląda podobnie, ale służy różnym celom biznesowym
function validateUserRegistration(data) {
  if (!data.email) return { valid: false, error: 'Email wymagany' };
  if (!data.password) return { valid: false, error: 'Hasło wymagane' };
  if (data.password.length < 8) return { valid: false, error: 'Hasło za krótkie' };
  return { valid: true };
}

function validateNewsletterSignup(data) {
  if (!data.email) return { valid: false, error: 'Email wymagany' };
  return { valid: true };
}

// Nie łącz ich! Będą ewoluować różnie w miarę zmian reguł biznesowych.

Praktyczne wskazówki

Oto jak zdecydować:

  1. Pierwsze wystąpienie — Po prostu napisz kod. Nie myśl jeszcze o ponownym użyciu.

  2. Drugie wystąpienie — Zauważ duplikację, ale oprzyj się pokusie. Copy-paste jest OK.

  3. Trzecie wystąpienie — Teraz oceń: Czy te przypadki dzielą ten sam powód do zmiany? Jeśli tak, abstrahuj. Jeśli nie, trzymaj je osobno.

  4. W razie wątpliwości — Preferuj duplikację. Łatwiej połączyć zduplikowany kod później niż rozdzielić złą abstrakcję.

Prawdziwy wróg: Złe abstrakcje

Sandi Metz ujęła to najlepiej: "Duplikacja jest znacznie tańsza niż zła abstrakcja."

Zła abstrakcja nie tylko nie oszczędza czasu — aktywnie kosztuje czas. Każdy developer, który jej dotyka, musi zrozumieć dziwactwa abstrakcji. Każde nowe wymaganie musi obejść jej założenia. W końcu ktoś przepisuje ją od zera.

Podsumowanie

DRY to użyteczna heurystyka, nie prawo. WET przypomina nam, że pewna duplikacja jest akceptowalna. AHA uczy nas czekać, aż naprawdę zrozumiemy wzorzec, zanim będziemy abstrahować.

Celem nie jest eliminacja całej duplikacji — to budowanie kodu, który jest łatwy do zmiany. Czasami to oznacza współdzielenie logiki. Czasami to oznacza trzymanie rzeczy osobno. Mądrość to wiedzieć, w której sytuacji się znajdujesz.

Categories

Recent Posts

About Me

Piotr Sikora - Process Automation | AI | n8n | Python | JavaScript

Piotr Sikora

Process Automation Specialist

I implement automation that saves time and money, streamlines operations, and increases the predictability of results. Specializing in process automation, AI implementation, and workflow optimization using n8n, Python, and JavaScript.

n8n Workflows

n8n workflow automation templates

Explore my workflow templates on n8n. Ready-to-use automations for blog management, data collection, and AI-powered content processing.

3Workflow Templates

• Auto-Categorize Blog Posts with AI

• Collect LinkedIn Profiles

• Export WordPress Posts for SEO

Jeśli ktoś oferuje Ci niesamowitą okazję, ale nie jesteś pewien, czy dasz radę, powiedz 'tak' – i naucz się, jak to zrobić później!
Richard Branson
Zobacz więcej cytatów

Podobne artykuły

Odkryj więcej powiązanych treści

Dlaczego nie powinieneś upychać wielu webhooków w jednym workflow n8n

Ukryte koszty łączenia webhooków i dlaczego osobne workflow oszczędzą ci bólu głowy

API vs Webhook: Zrozumienie różnicy

Dowiedz się, kiedy pobierać dane przez API, a kiedy pozwolić webhookom je do ciebie wysyłać

Hands On Tech - Internet Rzeczy (IOT)

Hands On Tech - Internet Rzeczy (IOT)

To było świetnie być na spotkaniu Hands On Tech w Kielcach.