Good Enough Code. ч.1
Код на відчепись, чи відчепіться від мого коду?
У кожного був цей момент: задачу закрито, ревʼю пройдено, усе працює — але щось свербить. Може, ще трохи підчистити? Перейменувати функцію? Винести шматок у модуль? Просто, щоб було "красивіше".
Так ось це і є зіткнення перфекціонізму з "достатністю" — і саме тут починається наша розмова про Good Enough Code.
Good Enough Code — це не "аби працювало". Це не код "на відчепись". Це підхід, у якому рішення достатньо хороше, щоб працювати, не створювати надмірний технічний борг і не витрачати зайві дні на причесування уже робочого коду. Це про точку, за якою зусилля на покращення вже не виправдані вигодою.
У реальності більшість задач — це не архітектурні шедеври, а практичні компроміси. І намагання зробити "ідеально" часто шкодить більше, ніж допомагає. Час іде на дрібниці, фідбек затримується, команда буксує в ревʼю. Продукт стоїть. Користувач чекає.
Парадоксально, але заради якості ми нерідко жертвуємо користю. І саме підхід GEC повертає фокус туди, де він має бути — на цінність.
Хороший код — це той, що вирішує задачу по суті, читається та підтримується без пояснювальної бригади, не ламається при зміні й дозволяє рухатися далі. Не ідеальний, а достатньо хороший, щоб не зупиняти розробку.
В той же час це не виправдання ліні. Це усвідомлений вибір, коли ти розумієш, де точка diminishing returns, що вигідніше бізнесу, і куди справді варто спрямувати свою енергію.
Бо в щоденній розробці виграє не той, хто пише красиво. А той, хто доставляє результат — і вміє вчасно зупинитись.
І якщо цей допис набере понад 150 реакцій та 1000 переглядів, то у наступних дописах ми з вами обовʼязково розглянемо:
– Як відрізнити достатній код від халтури?
– Які критерії “good enough”?
– Чому перфекціонізм — це теж технічний борг?
– Як впровадити цей підхід у команду й не перетворити все на безконтрольну лінь?
#good_enough_code #мислення_розробника
100 гривень на РЕБ — квиток на fwdays
@babichdev
Код на відчепись, чи відчепіться від мого коду?
У кожного був цей момент: задачу закрито, ревʼю пройдено, усе працює — але щось свербить. Може, ще трохи підчистити? Перейменувати функцію? Винести шматок у модуль? Просто, щоб було "красивіше".
Так ось це і є зіткнення перфекціонізму з "достатністю" — і саме тут починається наша розмова про Good Enough Code.
Good Enough Code — це не "аби працювало". Це не код "на відчепись". Це підхід, у якому рішення достатньо хороше, щоб працювати, не створювати надмірний технічний борг і не витрачати зайві дні на причесування уже робочого коду. Це про точку, за якою зусилля на покращення вже не виправдані вигодою.
У реальності більшість задач — це не архітектурні шедеври, а практичні компроміси. І намагання зробити "ідеально" часто шкодить більше, ніж допомагає. Час іде на дрібниці, фідбек затримується, команда буксує в ревʼю. Продукт стоїть. Користувач чекає.
Парадоксально, але заради якості ми нерідко жертвуємо користю. І саме підхід GEC повертає фокус туди, де він має бути — на цінність.
Хороший код — це той, що вирішує задачу по суті, читається та підтримується без пояснювальної бригади, не ламається при зміні й дозволяє рухатися далі. Не ідеальний, а достатньо хороший, щоб не зупиняти розробку.
В той же час це не виправдання ліні. Це усвідомлений вибір, коли ти розумієш, де точка diminishing returns, що вигідніше бізнесу, і куди справді варто спрямувати свою енергію.
Бо в щоденній розробці виграє не той, хто пише красиво. А той, хто доставляє результат — і вміє вчасно зупинитись.
Зацікавило? Тоді ставте вподобайки і діліться з друзями!
І якщо цей допис набере понад 150 реакцій та 1000 переглядів, то у наступних дописах ми з вами обовʼязково розглянемо:
– Як відрізнити достатній код від халтури?
– Які критерії “good enough”?
– Чому перфекціонізм — це теж технічний борг?
– Як впровадити цей підхід у команду й не перетворити все на безконтрольну лінь?
#good_enough_code #мислення_розробника
100 гривень на РЕБ — квиток на fwdays
@babichdev
❤200🔥49🤔4👏3
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
.
GEC ≠ халтура
[ч.1 | ч.3]
Часто можна почути: мовляв, “достатньо хороший код” — це просто красива назва для того, щоб зробити абияк. Проте, це не так.
Good Enough Code — це не про недбалість. Це про свідомий, зважений вибір з розумінням наслідків та прийняттям відповідальности за ці наслідки.
Халтурний код — це той, що погано читається, складний для змін, не має тестів і не витримує навіть базових вимог до якості. Він створює ризики, накопичує технічний борг і гальмує команду та продукт.
Good Enough Code, навпаки, спирається на здоровий інженерний розрахунок. Це рішення, яке працює на користь продукту: виконує свою задачу, не створює проблем у майбутньому й дозволяє рухатися далі. Без надмірної витрати часу на деталі, що не принесуть суттєвої додаткової цінності.
Як відрізнити достатній код від халтури?
Ключ — у мотивації та наслідках. Халтура — це “аби відчепилися”, без розуміння впливу. GEC — це “зроблено достатньо добре для цієї задачі”, з розрахунком на підтримку, ризики й фокус на результат.
І ось тут треба зрозуміти найголовніше: "достатньо добре" не існує без контексту.
GEC це не універсальний стандарт якості, це про відповідність якості обставинам:
– Якщо це скрипт, який разово пройде по CSV-шці для маркетологів — “достатньо” може означати “працює, не падає, зроблено за 20 хвилин”.
– Якщо це MVP — enough це коли ви можете за дві хвилини показати користувачеві цінність.
– Якщо ж ви пишете код для кардіостимулятора — “достатньо” означає верифікацію, сертифікацію та бездоганність.
Good Enough Code — це не компроміс заради компромісу. Це розуміння, де саме пролягає межа між "ще треба доробити" та "вже не має сенсу".
Цей підхід не про зменшення відповідальності, навпаки, він про її збільшення. Він про конкретний фокус в конкретний момент, але при цьому і про усвідомлення ширшої картини та розуміння, де так як можна зрізати кути, а де — не можна у жодному разі.
#good_enough_code #мислення_розробника
***
Наступного разу ми поговоримо про найбільшого ворога розробника — diminishing returns та чому більше часу далеко не завжди значить більше якості.
@babichdev
.
🔥70❤21🤔4👏2
Good Enough Code, ч.3 — Diminishing returns
[ч.2] | [ч.4]
Що найбільше заважає нам у розробці? Звісно, ми самі. Але сьогодні мова про більш конкретного ворога — diminishing returns.
До прикладу, вам до рук потрапляє якийсь модуль, який вам за першу ітерацію вдається оптимізувати, припустимо, на 50% — з 400мс до 200мс. Наступні дві ітерації дають ще 10% — з 200мс до 180, потім ще 10%, вже до 162. Але зусиль — утричі більше.
Вигода, очевидно, занадто мала, тенденція ж — очевидна. А якщо рахувати загальну вигоду, то від початкового стану ви виграли за першу ітерацію цілих 50%, а за усі три ітерації разом — 59,5%. Тобто в результаті додаткових зусиль ви не виграли й десяти відсотків.
Звісно, цей приклад досить спрощений, однак чудово ілюструє принцип diminishing returns. Ви вкладаєте усе більше часу, отримуючи усе менше реального результату. Ба більше, на практиці часто якраз ось ці додаткові зусилля привносять ще й нестабільність до системи, збільшуючи її схильність до помилок та вартість подальшої підтримки.
Як зловити себе? Ви витрачаєте непомірно більше часу на удосконалення рішення, аніж на саме рішення. Більш явна ознака — команда не розуміє доцільність вашого затягування (це вже навіть не дзвіночок, це великодній дзвін). Або ж ви просто не можете зупинитись і починаєте полірувати заради самого полірування — впадаючи в азарт, попри мізерний ефект.
Ось тут вперше й прозвучить головна ідея усієї концепції Good Enough Code:
"Час від часу випускайте на волю свого внутрішнього Януковича, який казатиме вам “АСТАНАВІТЄСЬ“".
Вкрай важливо розуміти, коли ваше пакращення уже не буде пакращенням. Якщо ви намагаєтесь досягти прискорення вашого алгоритму на 2мс у фінансовому застосунку — це абсолютно виправдано. Там це може означати втрачені мільйони. Але якщо ви третій тиждень поліруєте форму на п’ять полів, щоб кнопка Submit спрацьовувала на 20мс швидше — це марно згаяний час. Користувач не помітить різниці.
Оцінюючи diminishing returns надзвичайно важливо брати до уваги не лише конкретні цифри, метрики й показники, а й доцільність покращень. Доречність витрати часу. Не кожне покращення — виправдане. Однак кожна зайва складність має ціну.
Не все потребує покращення. Я знаю, цю думку складно прийняти. Ще раз: не все потребує покращення. Але усе потребує стабільности. Про що ми й поговоримо наступного разу.
Якщо вам дуже сподобався цей допис, звичайно.
@babichdev
Дуже цікаво дізнатися вашу думку щодо diminishing returns — згодні, не згодні, вважаєте це проблемою чи вигадкою? Ласкаво прошу до дискусії!
#good_enough_code
[ч.2] | [ч.4]
Що найбільше заважає нам у розробці? Звісно, ми самі. Але сьогодні мова про більш конкретного ворога — diminishing returns.
До прикладу, вам до рук потрапляє якийсь модуль, який вам за першу ітерацію вдається оптимізувати, припустимо, на 50% — з 400мс до 200мс. Наступні дві ітерації дають ще 10% — з 200мс до 180, потім ще 10%, вже до 162. Але зусиль — утричі більше.
Вигода, очевидно, занадто мала, тенденція ж — очевидна. А якщо рахувати загальну вигоду, то від початкового стану ви виграли за першу ітерацію цілих 50%, а за усі три ітерації разом — 59,5%. Тобто в результаті додаткових зусиль ви не виграли й десяти відсотків.
Звісно, цей приклад досить спрощений, однак чудово ілюструє принцип diminishing returns. Ви вкладаєте усе більше часу, отримуючи усе менше реального результату. Ба більше, на практиці часто якраз ось ці додаткові зусилля привносять ще й нестабільність до системи, збільшуючи її схильність до помилок та вартість подальшої підтримки.
Як зловити себе? Ви витрачаєте непомірно більше часу на удосконалення рішення, аніж на саме рішення. Більш явна ознака — команда не розуміє доцільність вашого затягування (це вже навіть не дзвіночок, це великодній дзвін). Або ж ви просто не можете зупинитись і починаєте полірувати заради самого полірування — впадаючи в азарт, попри мізерний ефект.
Ось тут вперше й прозвучить головна ідея усієї концепції Good Enough Code:
"Час від часу випускайте на волю свого внутрішнього Януковича, який казатиме вам “АСТАНАВІТЄСЬ“".
Вкрай важливо розуміти, коли ваше пакращення уже не буде пакращенням. Якщо ви намагаєтесь досягти прискорення вашого алгоритму на 2мс у фінансовому застосунку — це абсолютно виправдано. Там це може означати втрачені мільйони. Але якщо ви третій тиждень поліруєте форму на п’ять полів, щоб кнопка Submit спрацьовувала на 20мс швидше — це марно згаяний час. Користувач не помітить різниці.
Оцінюючи diminishing returns надзвичайно важливо брати до уваги не лише конкретні цифри, метрики й показники, а й доцільність покращень. Доречність витрати часу. Не кожне покращення — виправдане. Однак кожна зайва складність має ціну.
Не все потребує покращення. Я знаю, цю думку складно прийняти. Ще раз: не все потребує покращення. Але усе потребує стабільности. Про що ми й поговоримо наступного разу.
Якщо вам дуже сподобався цей допис, звичайно.
@babichdev
Дуже цікаво дізнатися вашу думку щодо diminishing returns — згодні, не згодні, вважаєте це проблемою чи вигадкою? Ласкаво прошу до дискусії!
#good_enough_code
🔥73❤19👏1
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
[ч.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
❤45🔥16👏1