Pro фреймворки

Часто та ж категорія програмістів що сваряться на ORM, так само сваряться і на фреймворки, мовляв, повільно працюють, обмежують гнучкість і взагалі все можна зробити самому.

Я люблю фреймворки.

Фреймворки знімають з мене когнітивне навантаження щодо організації коду та дають найкоротший шлях до реалізації задачі.

Rails має купу конвенцій, завдяки яким відразу відпадає умовних 95% питань щодо того що куди класти й де писати.

Spring має інструменти під майже всі задачі. Бери доку ChatGPT та й пиши анотації, все вже зроблено до тебе.

Звісно, коли треба утнути щось нестандартне, то ти можеш бути обмеженим, але це треба робити нечасто, а якщо й городити з базових елементів (веб-серверу, роутеру, ORM) щось своє, де та гнучкість буде, то вийде одне на одне.

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

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

Як і з ORM, головний аргумент опонентів це те що на фреймворках виростають люди які не знають що таке HTTP заголовки та не вміють програмувати ні на чому іншому. Така проблема дійсно є, особливо зараз, коли з затишної коробочки спрінга вилазити зовсім не потрібно.

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

☝️Практична порада

👉Щоб не бути фреймворкодебілом запустіть дебаг і подивіться через що проходить реквест перед тим як дійти до вашого бізнес коду.


Сподобалось? Долучайтеся до мого телеграм каналу: https://t.me/full_of_hatred