🧠 13 законів розробки

Друзі, погодьтесь, іноді здається, що розробка це лише про код. Але якщо подивитись чесно, більшість складнощів виникає не в рядках коду, а в часі, очікуваннях і плануванні.

Тому запускаємо невелику серію – про закони, які програмісти й менеджери проживають щодня, навіть якщо не завжди називають їх вголос.

Сьогодні – один із найвідоміших 👇 І ви точно про нього чули

Закон Паркінсона

“Робота заповнює весь час, відведений на її виконання.”

Що це означає для розробки?
Якщо на задачу дали 5 днів – є великий шанс, що вона займе всі 5, навіть якщо технічно могла бути готова за 2.

👨‍💻 Для розробників
• починається зайвий рефакторинг “бо є час”;
• з’являється overengineering;
• дедлайн здається далеким і старт відкладається.

📊 Для менеджерів
• оцінки розтягуються;
• складно зрозуміти реальну швидкість команди;
• roadmap стає менш прогнозованим.

💡 Живий приклад
Задача: “додати простий фільтр”.
Оцінка – 3 дні.
Факт:
день 1 – дослідження,
день 2 – переписати сервіс “бо можна краще”,
день 3 – власне фільтр 🙂

Як з цим працювати:
✔️ дробити задачі на менші
✔️ ставити проміжні чекпоінти
✔️ домовлятись про definition of done, а не “ще трохи покращу”

Цікаво, чи ловили ви себе на Законі Паркінсона в реальних проєктах? 👀
Далі буде ще цікавіше – у серії попереду 12 законів розробки

TikTok | Instagram | Telegram

Rails magic: чому “воно саме працює” – найдорогоцінніша пастка 😈

👉 Rails люблять за швидкість і комфорт. І так, частина магії – це реально сила: conventions, генератори, ActiveRecord, автозавантаження – усе це економить час.

👉 Але є момент, який майже кожен проходив: спочатку Rails “все робить сам”, а потім одного дня ти ловиш баг/гальма/дивну поведінку і розумієш, що не знаєш що саме він робить під капотом.

І це норм. Ми всі так робили 🙂

Де “магія” найчастіше б’є по проєкту:
1. N+1 та eager loading
Запитів у базу стає 200 замість 2 і це не “повільний сервер”, а типова історія з асоціаціями.

2. Callbacks з побічними ефектами

after_save

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

3. Validations без гарантії в БД

validates :email, uniqueness: true

виглядає як гарантія, але без

unique index

це лише “майже завжди”.

4. Time zones / serialization / params
Rails може дуже зручно кастити дані… і так само зручно створити “невидимі” баги на межі типів/часу/форматів.

Як тримати Rails під контролем?
• Дивись у SQL:

ActiveRecord

крутий, але істина – у запитах.
Звичка: інколи відкривати логи або використовувати

EXPLAIN

• Менше магії там, де болить: критичні флоу роби максимально явними (особливо фінанси, доступи, інтеграції).

• Тестуй поведінку, а не “віру”: тести мають ловити не лише “працює”, а й “не робить зайвого”.

• Пам’ятай піраміду тестів: більше unit/інтеграційних, менше UI-E2E і менше ілюзії, що “все під контролем”.

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

TikTok | Instagram | Telegram

Друзі, час від часу, ми просимо у вас дати зворотній зв‘язок з приводу контенту в каналі.

Щоб ви порадили додати/прибрати? Чи можливо все влаштовує?

Ми намагаємося робити контент різним: поради, підбірки, розбір тем, трохи розваг для девів… але нам важливо розуміти, що саме корисно для вас.

Будемо дуже вдячними за зворотній зв’язок в коментарях!

TikTok | Instagram | Telegram

Рубісти, прийом-прийом 📡💎
Як чути?

На зв’язку Codica з новим Ruby Digest — наш СЕО Дмитро, як завжди, зібрав для вас найкращі апдейти зі світу Ruby 🚀

У випуску:
📌 реліз JRuby 10.0.3.0
📌 оновлення RubyGems 4.0.7
📌 хвиля AI-інструментів у Ruby
📌 апдейти в інструментах і бібліотеках
📌 статті про продуктивність і безпеку

Якщо на зв’язку — тоді саме час читати 😉👇
📥 [посилання]

#codica_tech

TikTok | Instagram | Telegram