Коли НЕ використовувати рамку [закрито]

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

Однак, я думаю, що в будь-якій структурі є мінус у тому, що програмісти, як громада, можуть настільки залежати від обраних рамок, що більше не розуміють основні розробки, або у випадку нових програмістів ніколи не навчаються базових робіт почати з. Неважко стати спеціалізованим настільки, що ви вже не "PHP-програміст" (наприклад), а "програміст Drupal", виключаючи будь-що інше.

Кого хвилює, правда? У нас є рамки! Нам не потрібно знати, як це зробити вручну! Правильно?

Результатом цієї втрати базових навичок (іноді настільки, що програмісти, які не використовують фреймворки, розглядаються як "застарілі"), полягає в тому, що звичайною практикою стає використання рамки там, де це не потрібно або доцільно. Особливості каркасні полегшує Смотать плутати з тим, що основна мова здатний. Розробники починають використовувати рамки для виконання навіть найосновніших завдань, так що те, що колись вважалося рудиментарним процесом, тепер включає в себе великі бібліотеки з власними примхами, помилками та залежностями. Те, що колись було виконано в 20 рядках, зараз здійснюється шляхом включення рамки 20 000 рядків І написання 20 рядків для використання рамки.

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

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

"Має бути хороший показник, щоб визначити, коли доцільно використовувати рамку."

Не зовсім. Якби були хороші показники для визначення відповідного використання будь-якої технології, ви б не бачили святих воєн мови, редактора та методології.

Групи, з якими я працював, роблять те саме: гадають про витрати та вигоди, вибирають найпродуктивніший маршрут та сподіваються, що вони вірні. Це не страшно науково - одна частина інтуїції, досвід роботи з трьох частин, одна сприйнятливість до маркетингу, одна частина хитра і п'ять частин оцінюють думку.

Рамки - це лише інструменти. Я не думаю, що це вина, якщо вона не є надмірно використаною, а не людиною, яка її зловживає. Стара приказка «якщо у тебе молоток, все схоже на цвях» показує, що такий спосіб мислення існував задовго до того, як навіть комп’ютери.

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

Щоб відповісти на ваше конкретне запитання, я не думаю, що для цього є метрика. Я вважаю за краще використовувати рамку, коли це спрощує вирішення проблем. Якщо використання рамки допоможе мені вирішити проблему з 2 рядками коду замість 20, я, очевидно, буду її використовувати. Але навіть якщо його 20 рядків проти 20, я можу вирішити використовувати рамку, якщо це дає мені кращі абстракції, ближче до проблемної області, що полегшує розуміння та підтримку коду.

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

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

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

Я також збираюся використовувати "фреймворк", синонімічний з "бібліотека".

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

№1. Чи заощадить рамки час та зусилля?

Відповідь на це питання майже завжди - так . Рамки, як правило, будуються для вирішення конкретних проблем та їх вирішення дуже добре. Наприклад, такі структури, як EntityFramework, можуть повністю врятувати вас від написання SQL-коду. Що може бути фантастично, якщо ваша команда програмування не вільно володіє SQL.

Каркаси побудовані або, а) додати програміст зручного інтерфейсу до іншого складним компонентам або б) додати абстракцію вже добре відомо (або встановленої) компонента.

Останні (або навіть перші в деяких випадках) насправді можуть стати на шляху розвитку. Особливо це стосується, коли ви або ваша команда програмування збираєтеся реалізувати нові рамки, в яких вони ніколи раніше не працювали.

Це потенційно може уповільнити ваш процес розробки, що може бути дорогим.

№2 Масштаб вашої заявки

Кажуть, що "все, що варто робити, варто перестаратися" , але зазвичай це не так. Напевно, немає вагомих причин застосовувати рамки надмірного розміру, якщо суть вашої заявки полягає у друкуванні "картоплі" .

Коли ви розробляєте додаток (будь то веб-, настільний, мобільний або будь-який інший можливий тип додатків) - якщо ви вважаєте, що розмір вашої рамки "гномів" вашої (можливо, майбутньої) реалізації цього, то це може бути великим попереджувальний знак, що ваша рамка може просто роздути вашу програму. Хорошим анекдотом було б, якби ви включили jQuery, просто додати «завантажений» -клас до свого тегу body, коли документ буде готовий. Робити це за допомогою просто рідного JavaScript може бути трохи складніше , але це не роздуває вашу програму.

З іншого боку, якщо фреймворк виконує багато брудної роботи зсередини (тобто рамки бази даних), то це може бути реально реалізувати, навіть якщо ви лише "частково" використовуєте фреймворк. Хорошим анекдотом було б не намагатися створити власний драйвер ADO.NET або MongoDB, тільки тому, що вам не потрібно використовувати всю бібліотеку.

Іноді рамки поставляються з відкритим кодом (і з ліцензіями "робити все, що ти хочеш"). Це відкриває нову можливість, коли команда програмування може вибрати лише частини фреймворку.

Це врешті-решт повертається до питань №1 та №3.

№3 Вплив.

Іноді реалізація рамки може безпосередньо впливати на кінцевого користувача. Це особливо стосується веб-додатків, оскільки наявність великих кадрів на стороні клієнта може негативно вплинути на роботу кінцевого користувача. Користувачі з повільнішими машинами можуть відчувати повільну візуалізацію, проблеми з роботою з javascript або подібні проблеми, викликані машинами під номіналом. Користувач із повільними зв’язками може відчувати повільний (принаймні початковий) час завантаження.

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

Рамки на стороні сервера (ще більш конкретні для Інтернету), швидше за все, не вплинуть на ваших кінцевих користувачів, але це вплине на вашу інфраструктуру . Деякі рамки мають самі залежності, які можуть зажадати від вас перезапустити веб-сервер, або лише сервіс або сервер повністю.

Деякі структури можуть також бути дуже ресурсозберігаючої важкою.

Звичайно, це пов'язано з пунктами №1 та №2.

Це все лише велике «коло міркувань», і немає реального наукового методу для вирішення питання про те, чи слід реалізувати рамки чи ні.

Корбін Марч дуже добре підсумував це:

Групи, з якими я працював, роблять те саме: гадають про витрати та вигоди, вибирають найпродуктивніший маршрут та сподіваються, що вони вірні. Це не страшно науково - одна частина інтуїції, досвід роботи з трьох частин, одна сприйнятливість до маркетингу, одна частина хитра і п'ять частин оцінюють думку.

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

Усі рамки мають випадки використання, це лише питання їх реалізації у правильних цілях.

Чи знають інші розробники рамки?

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

Щодо вашої заяви про новіших програмістів, які не знають основ, ви набагато співчутливіші, ніж я! Так, це соромно, але чи я буду витрачати свій час на занепокоєння про чужу невміння? Нуп. (Виходячи з припущення, що ці нові члени спільноти не відразу працюють з вами.)

Я б використав рамку, якщо (і ТІЛЬКИ, якщо) виконуються такі умови:

Здається, рамки будуть підтримуватися деякий час. У мене раніше вони закінчували життя, і це дійсно дратує. Тим більше, коли ти 9 місяців займаєшся своїм проектом, і переключення вже не є варіантом. І якщо фреймворк ЗАВЖДИ не підтримується, подумайте три рази, перш ніж написати щось нове, використовуючи цей фреймворк. Як би добре ви це вже не знали.

Проект фактично відповідає рамці. Як досить старий приклад, чи бачили ви речі, з яких MFC робився? Люди не закінчували дивних речей, щоб змусити це працювати для типів програм, де це просто не було сенсу. Зазвичай витрачають більше часу на побиття MFC, ніж витратили б просто на написання програми, яку хотіли.

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