Що таке фреймоворк? Це програмне забезпечення, що полегшує розробку і об'єднання різних компонентів великого програмного проекту. На відміну від бібліотеки функцій, фреймворк накладає обмеження на структуру і логіку програмного продукту.
Визначення фрейморка (англ. Framework - каркас, структура) взято з Вікіпедії.
Веб-фреймворк служить для побудови веб-додатки, в нього включена логіка обробки HTTP запитів, робота з FTP, електронною поштою.
Навіщо потрібен веб-фреймворк?
У будь-якій мові програмування фреймворк є надбудовою над мовою. Часто це дуже складна надбудова, з дуже високим рівнем абстракції, з багатою функціональністю, що дозволяє конструювати додаток з сторонніх модулів, легко розширювати і модифікувати під свої потрібні. Також фреймворк вводить обмеження на структуру файлів, стиль оформлення коду, правила з розділення логіки. Навколо деяких з цих фреймворків виникають спільноти користувачів, пишуться книги про те, як їх використовувати. Мета більшості фреймворків - на скільки можливо більше економити час на початковому етапі розробки та на підтримку готових проектів. Але іноді через високу складності вони стають важкими у розумінні, вимагають довгого навчання, перш ніж їх можна буде почати використовувати найкращим чином. Я, наприклад, поки ще не подужав Django для мови Python.
Внутрішнє і функціональність пристрій фреймворків відрізняється, але можна сказати, що якась частина їх організована за схожими принципами, наприклад, MVC фреймворки або RESTfull мікро-фреймворки. Частина рішень є покращеною і розширеною версією старіших. З певною часткою впевненості скажу, що якщо знаєш як працює один з них, то зможеш розібратися і в іншому, а це дасть значну економію часу.
Ще слід зауважити, що наслідком високої складності фреймворків є повільна робота програми. Наприклад, складного додатку на базі Zend Framework потрібно завантажити близько сотні файлів з диска на кожен вхідний запит HTTP.
Чи можна обійтися без веб-фреймворку?
Приймаючи рішення використовувати фреймворк в розробці програмного забезпечення, програміст погоджується, що в результаті програмний продукт буде працювати повільніше, але процеси проектування і розробки будуть швидше, а технічний супровід - простіше. У разі складного проекту набагато дешевше купити більш потужний комп'ютер для веб-сервера, ніж дозволити кільком програмістам топтатися на одному місці, винаходячи свій велосипед.
При відмові від використання виникає ряд складнощів, які може обійти тільки той, хто вже розібрався, як те чи інше рішення реалізовано в існуючих фреймворками. Іноді розробка викликає відчуття «винаходу велосипеда». Або колеса. Постійно виникають питання «А як то чи це зробити, як воно повинно працювати, як його закодувати?». При цей немає ні спільноти, готового допомогти, ні прикладів, які можна було взяти за основу, ні сховища готових рішень, які можна було б підключити до проекту. Доводиться запозичувати рішення з відкритих джерел, часто - прямо з інших фреймворків.
Програмні рішення, прийняті групою розробників на проекті без фреймворку, несуть мало користі іншим розробникам - для них це просто інформація «у цього завдання є рішення». Дуже мало ентузіастів перенести рішення в існуючі фреймворки.
Розрахунок втрат в результаті відмови від фреймворка
Простий розрахунок втрат на сферичних конях в вакуумі:
Команда оцінила складність програми та видала такі терміни:
- випуск альфа-версії через 2 місяці
- бета-версія буде через 4 місяці
- реліз - через 6 місяців
Підсумкова вартість роботи: 6 місяців * 3 людини * $ 1000 = $ 18000
Продовження розрахунку буде після таблиці.
Розглядається з точки зору серверної розробки.
Так чи можна відмовитися від веб-фреймворку?
Так, можна, якщо проект досить простий.
Розрахунок втрат в результаті відмови від фреймворка
Повернуся до сферичним коням і вакууму.
Міняємо умови: Тепер наші програмісти вирішили робити програмний продукт без фреймворку, тому що а) вони про них нічого не знають, або б) читали про них тільки критичні статті (приклад).
проміжний підрахунок
* Через 2 місяці випущена альфа-версія, що коштувало 3 людини * 2 місяці * $ 1000 = $ 6000..
Припускаю, що від бети до релізу теж не два місяці вийшло, а чотири.
А найсумніше - це підтримка проекту. Припустимо, що цих трьох крутих програмістів перевели на інший проект або через рік вони звільнилися. Кожному, хто буде займатися підтримкою проекту в майбутньому, доведеться самостійно вивчити повністю весь код цього проекту, перш ніж змінювати його. Документації, швидше за все не буде. У кращому випадку підтримка зможе виправляти помилки, не ризикуючи робити значні зміни.
З особистого досвіду. З тих пір як я попрацював з декількома з них, я не рекомендую якийсь конкретний фреймворк або конкретну мову. Занадто великий вибір, щоб радити щось конкретне. Я пропоную написати просте застосування, наприклад Hello World або гостьову книгу, на декількох з них. Тільки тоді стане ясно, що зручніше.
webmentor.pro - твій надійний друг, досвідчений радник і підтримка
Програми підтримки при вивченні проектування і розробки веб-додатків, нових мов програмування і веб-технологій.
Опитувальник по стеку технологій для веб-розробника
Швидка оцінка поточного рівня знань. Графіки особистого професійного зростання. Віджети для портфоліо. Рекоментацій по ефективному підвищенню рівня знань.