Питання Чому мені потрібно використовувати популярні рамки?


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

Нещодавно я подивився на CodeIgniter, і виявив, що вони мають багато класів і допоміжних програм, які допомагають розвиватися, але не бачив нічого в прикладах, які я не міг зробити так само легко з власними інструментами. Прості речі, такі як абстракції БД, помічники електронної пошти тощо. Існував якийсь цікавий код, пов'язаний з маршрутами - відстеження адрес на правильні контролери; але навіть це не особливо важко кодувати себе, якщо ви коли-небудь написали веб-додаток стилю MVC з досить URL-адресами.

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

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

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


18
2017-11-10 21:09


походження


Якщо ви вирішите упаковувати свої рамки, додайте посилання. Код google або git проект легко налаштувати. Мені цікаво. - Till


Відповіді:


Рамки мають кілька переваг:

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

  • Рамки забезпечують стандартизовані та перевірені способи виконання речей. Чим більше користувачів є певної рамки, тим більше решти випадків, які були виявлені та закодовані. Ваш власний код може або не може бути жорстким боєм так само.

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

EDIT:

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

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

Великі перемоги з невеликими зусиллями мають важливе значення для усиновлення (ці перемоги спонукають людей піти далі в рамки). Ruby on Rails на прикладі структури, яка дає такі великі перемоги з невеликими зусиллями, а потім має приховані шари функцій, які могли б перевантажити когось, тільки почавши роботу. (Питання про якість додатків RoR не має сенсу, мова йде про швидкість прийняття).

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

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


34
2017-11-10 20:13





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

Ви бачили скільки веб-структур для Java? Надднім днем ​​для будь-якого напівпристойного розробника / архітектора було модно написати власну веб-структуру. І наприкінці дня 95% з них виглядали як спеціальна реалізація Struts (найпопулярніша веб-структура Java у той час). Таким чином, вони в основному створили клоп Struts, який був: 1) фірмовий; і 2) не дуже добре документовані та випробувані.

Подивимось на це - написання нашої власної клієнтської системи весело, але що буде далі? Це стає тягарем до супроводу, який несе відповідальність за себе (або бідну душу, яка вас замінить). І підтримка програмного забезпечення набагато, набагато дорожче, особливо якщо мова йде про спеціальні рамки. Чи є компанія, що займається бізнесом, вирішувати проблеми, пов'язані з доменом, або у справі підтримки структур?

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


12
2017-11-10 21:40





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

ТАКЕ

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

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

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


10



Великі пальці для "..Я завжди піду на найлегшу, найтоншу, обгортку я можу знайти, що зробить те, що мені потрібно" - pimbrouwers
@pimbrouwers, звичайно, дух цього, як і раніше, є вірним, але я написав це десятиліття йти, і в ці дні я навряд чи використовую PHP без структури. Laravel, якщо проект помірно або складніший, але все одно CodeIgniter, якщо я хочу щось просте та швидке (наприклад, API в базі даних), я все ще сприймаю скептичні погляди щодо Javascript-структур, але в той же день немає ніяких структур для чого-небудь але найпростіші скрипти PHP закінчені - Cruachan
Я з тобою 100%. Я віддаю перевагу слайду & idiorm для проектів у php. У парі з nginx / php-fpm / apache на стороні інфраструктури з високими показниками продуктивності та безпеки. Але це, звичайно, особистий смак! На фронті JavaScript перевірка Knockout.js. Це неймовірно. Це відновило мою любов до кодування JavaScript. - pimbrouwers
@pimbrouwers Knockout.js - я обов'язково перевірив це. - Cruachan


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

І врятувати будь-який час це добре. Ліниво окупається в програмуванні.


7





Одна справа, яку ви втратите, - це все перевірка, яка переходить у популярну основу.

Ваша програма просто не має такої ж експозиції, яку мають популярні бібліотеки.


5





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

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


4





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


3





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

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


2





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


2





Три причини, про які я можу подумати відразу:

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

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


2





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

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

Ви згадали CodeIgniter - я особисто відчуваю, що це гарне середовище - він не набагато більше баребонів, ніж це.


2