Good Enough Code. ч.4 — поради чи догмат?
[ч.3]

Зі сторони може здаватися, що Good Enough Code базується на якихось догмах, яких треба неухильно дотримуватися, і тоді код буде good enough сам по собі. Але насправді це зовсім не так — це не набір обов’язкових принципів, а радше філософія балансу.

Проте існує декілька орієнтирів, які добре знайомі розробникам і можуть допомогти не збитися з курсу, і як приклад можна узяти найвідоміші з них: YAGNI, KISS, DRY, Pareto.

Вони не є визначальними для GEC, але часто слугують найзручнішою рамкою для перевірки власних рішень.

Втім, важливо пам’ятати: сліпе застосування цих принципів може зашкодити не менше, ніж повне їх ігнорування. Тут, як і завжди в інженерії, все вирішує контекст.

YAGNI (You Aren’t Gonna Need It)
Цей принцип каже нам: «Не реалізовуй функціональність “про запас”, якщо в ній нема потреби просто зараз».

Але якщо ти реально впевнений, що за місяць це знадобиться і зробити потім буде в рази дорожче — можна і варто трошки попрацювати на майбутнє. YAGNI — не табу на передбачення, а швидше захист від безпідставних фантазій.

KISS (Keep It Simple, Stupid).
Простота — найбільша чеснота коду. Але простота без структури швидко перетворюється на хаос.

Бізнесу часто краща структурована складність, ніж хаотична простота, де “ніби все просто”, але підтримувати неможливо. KISS не примушує нас до відмови від архітектури, радше пропонує розумне спрощення.

DRY (Don’t Repeat Yourself). «Не дублюй без потреби — це рятує від багів».
Водночас не варто передчасно абстрагувати, створюючи нечіткі ієрархії там, де простий повтор був би зрозумілішим і дешевшим.

Будь-який код перестає бути універсальним через кілька ітерацій, і часто надмірна абстракція призводить до того, що модуль перетворюється на монстра, що вміє усе, але не може нічого. DRY має працювати на прозорість, а не на штучну універсальність.

Pareto principle (80/20 rule): 80% ефекту дають 20% зусиль — чудова ідея, якщо дозволяє контекст.
Але для критичних компонентів навіть дрібні недопрацювання можуть мати катастрофічні наслідки, тож тут Pareto працює значно обережніше.

Важливо розуміти: надмірне слідування будь-якому одному принципу майже гарантовано порушить інший. Спробуєш фанатично уникати повторів — постраждає простота; спростиш усе до мінімуму — втратиш масштабованість; поженешся за Pareto — ризикуєш пропустити критичні баги.

Нашою метою як розробників має бути розумний баланс, бо викрутити усі показники на 100% неможливо фізично. Важливо завжди тримати в голові: усі ці принципи — не закон, а інструмент мислення. Вони дозволяють перевіряти себе:

– Чи я не перестарався із ускладненням?
– Чи справді варто так абстрагувати?
– Чи достатньо цей код вирішує задачу тут і зараз?

Good Enough Code — це не догмат, не заповіді. Він радше покладається на вміння балансувати між простотою, якістю і контекстом, а головне питання, яким треба задаватися в пошуку цього балансу — «Для кого і навіщо цей код?»

#good_enough_code #мислення_розробника

@babichdev