Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

11.05.2024

YAGNI

✂️ Трохи рідше ніж DRY або KISS можна почути мантру YAGNI - вам це не знадобиться. Мантра нагадує, що зайві функції ускладнюють проєкт, та на варто витрачати час на те, що не є підтвердженою потребою користувачів.

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

Наведу приклад з проєкту, на який я витратив пару років, але так і не запустив. Це був застосунок на React Native з власним ORM на основі PouchDB; на кожному пристрої — власна база, з синхронізацією через CouchDB. Тут поки все прийнятно. Але… база, як завжди, потребує оказійних змін схеми — міграцій.

Міграції в розподіленій базі — набагато цікавіше, ніж в традиційній; як бути, коли клієнт зі старою версією застосунку отримує нові дані? А коли продовжує писати стару схему в спільну базу? Як уникнути конфліктів?

Я витратив багато часу на розробку (теоретично) надійного механізму, а також убезпечення кожної міграції — хоча в мене був лише один користувач з одним пристроєм. Я міг би редагувати дані вручну в базі, якби так було зручно. Але ні, запас на майбутнє мене змушував робити абсолютно зайву роботу (бо проєкт не був опублікований.)

Думаю, тут має значення те, що програмістів приваблюють складні задачі. Часто розробка чергової “системи міграцій” нас захоплює, в той час, як важливі для продукту задачі потребують рутини.

Засновник екстремального програмування висловив цей принцип ще екстремальніше: Вам потрібний гетер для змінної. Добре, пишіть. Але не пишіть сетер “бо теж знадобиться”. Не пишіть гетери для інших змінних “бо теж знадобляться.” Кращий спосіб писати код швидко це писати його менше.