Чи ставлять рамки занадто великі абстракції? [зачинено]

Я програмую трохи менше року і маю певний досвід написання системних додатків, веб-додатків та сценаріїв для підприємств / організацій. Однак одне, чого я ніколи не робив, - це робота з такою рамкою, як Django, Rails або Zend.

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

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

2. Робить код важко зрозумілим через безліч доступних фреймворків та модулів та всіх їхніх ідіосинкразій,

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

4. Складно перемикати між структурами важко і нудно. Переключення між мовами - це вже складна задача, але це керовано, якщо ви досить добре розумієте їх основні функціональні можливості / філософію. Переключення між рамками, здається, є більшою мірою запам'ятовуванням підрядних каналів, що певним чином спонукає до неефективності цих фреймворків.

Чи дійсно нам потрібно розміщувати як 50 шарів абстракції поверх чогось такого простого, як запит MySQL? Чому б не використати щось на зразок інтерфейсу PDO для PHP, де обробляються підготовлені оператори / вхідні тестування, але універсально зрозумілий SQL-запит все ще є частиною функції?

Чи справді ці абстракції корисні? Невже функція "блат" не робить їх марними, робить додатки складнішими порівняно з аналогічними програмами, написаними без використання рамки?

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

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

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

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

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

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

Ви також повинні розрізняти технічні абстракції та абстракції "бізнес-правил" . Програмування на мові вищого рівня - це абстракція, яку ви, мабуть, не хочете пропустити (Python, PHP, C # vs. C vs. Assembler; Менше проти CSS), тоді як "абстрагування бізнес-правил" може бути важким, якщо вони цього не роблять. точно відповідати вашим потребам (автентифікація одним клацанням миші та файли cookie вручну).

Це тому, що технічні абстракції рідко "просочуються", тобто вам навряд чи доведеться налагоджувати машинний код під час написання програм на Python. Однак абстракції бізнес-правил працюють на одному технічному рівні і справді є лише «кодовими пакетами». Можливо , вам доведеться налагодити встановлений файл cookie або створений хеш паролів, який створюється в якийсь момент, а це означає, що ви будете переглядати безліч кодів сторонніх сторін.

Мені здається, ви неправильно розумієте абстракції та повторне використання коду.

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

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

Ви отримуєте це, використовуючи в першу чергу PHP або Ruby, у вас вже є величезна кількість абстракцій, чи не так? Найбільш очевидні:

1. Операційна система, мова програмування та компілятор забезпечують величезну абстракцію щодо Assembler і апаратних засобів,

2. Веб-сервер забезпечує абстракцію сокетів, відмову, протокол HTTP тощо,

3. SQL забезпечує абстракцію щодо того, як дані зберігаються на постійній підтримці зберігання та зберігаються в пам'яті для швидшого доступу, забезпечує ACID, дзеркальне відображення тощо.

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

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

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

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

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

Ще один фактор - читабельність вашого коду. Уявіть, що ви створили веб-сайт електронної комерції. Пізніше ви покинули проект, і інший розробник повинен його підтримувати.

• Якби ви використовували візок, наданий рамкою, ваш колега буде полегшений: він повинен підтримувати невеликий фрагмент коду, який спирається на надійну, сильно задокументовану рамку. Ще краще: цей розробник, можливо, використовувався для роботи з цим фреймворком і йому знайомий. Якщо ні, він може задати питання щодо Stacka Overflow: напевно, хтось уже використовував рамки.

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

Використовуючи рамки, ви покладаєтесь на код, який:

• Автор досвідчених розробників,

• Часто переглядають пару,

• Тестування одиниці,

• Широко документовані,

• Використовується роками тисячами розробників,

• Часто підтримується, тому ви можете повідомити про помилку і побачити, що вона фактично виправлена,

• Відомий багатьма розробниками, які знають можливі застереження та проблеми та можуть допомогти на таких сайтах, як Stack Overflow.

• Доступно для вас прямо зараз, безкоштовно.

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

Hmmm Одним з аспектів LedgerSMB, над яким ми багато працювали, був наш підхід до фреймворку. Існують дві основні проблеми, які виникають із таким абстрагуванням. Це:

1. Вибух залежності і

2. Неправильна абстракція

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

Давайте розглянемо, наприклад, ORM. Я уникаю використання ORM, тому що дуже часто трапляється, що db в кінцевому підсумку призначений для об’єктної моделі програми, оскільки в кращому випадку вони є герметичними шарами абстракції. Це не обов'язково так. Я зустрів розробників, які встигають зберегти гарний дизайн БД і гарне додаток під час використання ORM, але вони вдаються до багатьох речей, за якими скажіть, що не рекомендується.

Основна проблема, звичайно, полягає в тому, що чим сильніше автоматизований код, особливо коли він також непрозорий, тим складніше зрозуміти, що йде не так. Це пункт про ORM, який @jhewlett робить вище (див. Https://softwareengineering.stackexchange.com/a/190807/63722 ).

Гарною паралеллю може стати передова авіоніка як основа для пілотування літального апарату. Вони були розроблені для надійності і є фактором підвищення безпеки польоту. Однак стільки ж статей у IEEE Spectrum зазначають, це пояснюється вартістю виправлення помилок поза межами того, що вважається прийнятним з точки зору автоматизації. Те саме стосується налагодження. Один варіант налагодження SQL-коду у вашій програмі. Дуже інша справа налагодження частини вашої програми, яка пише SQL-код для вашої програми.

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

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

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

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

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

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

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

Розгляньте об'єктно-реляційні картографи (ORM). Вони чудові тим, що піклуються про безліч нудних кодів для вас. Вони можуть навіть створити для вас ваші об’єкти. Однак, абстрагуючись від SQL, набагато складніше міркувати про ефективність та оптимізувати вузькі місця.

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

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

Для мене найважливішим моментом є те, що я повинен отримати більше ресурсів, ніж вимагає від мене інвестицій. Або, під іншим кутом зору, я б сказав, що як тільки потреби рамки перевищують наявну нагороду (і), вся перевага відсутня. Так це "Так!" Будь ласка! І дякую! ' для всіх, хто заробляє активи, які випадуть прямо і функціонують за потребою в моїх власних html / CSS / PHP та SQL.

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

Деякі люди кажуть, що це Голлівудський принцип рамок: "Не дзвоніть нам, ми зателефонуємо вам". На відміну від цього, кожен раз, коли ви використовуєте бібліотеку, ваш код викликає бібліотеку , а не навпаки.

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

Є аргументи «за» і «проти», і коли я бачу такі нескінченні дискусії, я схиляюсь до того, що це має бути питання смаку, а не об'єктивно вирішуваного питання. Інакше було б вирішено вже.

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

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

Я не думаю, що було б розумно вирішити, що краще бути схожим на колишнього чи останнього.

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

...

А ще конкретніше, якщо вам не подобаються такі фреймворки, як Django, перейдіть до пошуку таких мікрофреймів як Flask :)