Good Enough Code. ч.2
GEC ≠ халтура
[ч.1 | ч.3]

Часто можна почути: мовляв, “достатньо хороший код” — це просто красива назва для того, щоб зробити абияк. Проте, це не так.

Good Enough Code — це не про недбалість. Це про свідомий, зважений вибір з розумінням наслідків та прийняттям відповідальности за ці наслідки.

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

Good Enough Code, навпаки, спирається на здоровий інженерний розрахунок. Це рішення, яке працює на користь продукту: виконує свою задачу, не створює проблем у майбутньому й дозволяє рухатися далі. Без надмірної витрати часу на деталі, що не принесуть суттєвої додаткової цінності.

Як відрізнити достатній код від халтури?
Ключ — у мотивації та наслідках. Халтура — це “аби відчепилися”, без розуміння впливу. GEC — це “зроблено достатньо добре для цієї задачі”, з розрахунком на підтримку, ризики й фокус на результат.

І ось тут треба зрозуміти найголовніше: "достатньо добре" не існує без контексту.

GEC це не універсальний стандарт якості, це про відповідність якості обставинам:

– Якщо це скрипт, який разово пройде по CSV-шці для маркетологів — “достатньо” може означати “працює, не падає, зроблено за 20 хвилин”.

– Якщо це MVP — enough це коли ви можете за дві хвилини показати користувачеві цінність.

– Якщо ж ви пишете код для кардіостимулятора — “достатньо” означає верифікацію, сертифікацію та бездоганність.

Good Enough Code — це не компроміс заради компромісу. Це розуміння, де саме пролягає межа між "ще треба доробити" та "вже не має сенсу".

Цей підхід не про зменшення відповідальності, навпаки, він про її збільшення. Він про конкретний фокус в конкретний момент, але при цьому і про усвідомлення ширшої картини та розуміння, де так як можна зрізати кути, а де — не можна у жодному разі.

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

***
Наступного разу ми поговоримо про найбільшого ворога розробника — diminishing returns та чому більше часу далеко не завжди значить більше якості.

@babichdev
.