Мода на веб-фреймворки - тези

1. Назва доповіді
2. тези
3. Припустимо, вам потрібно створити інтернет-проект ⌘⌘ %%
4. Проблема моди ⌘⌘
5. Треба було думати, коли вибирали! ⌘⌘ %%
6. Введення: проблема моди
7. CMS
8. Що таке CMS? ⌘⌘
9. визначення CMS
10. Стандартна фраза: ⌘⌘ %%
11. Сенс саме в спільності застосування ⌘⌘
12. Теоретично ... ⌘⌘ %%
13. Такі CMS - монстри ⌘⌘
14. Оплачувати вам це ... ⌘⌘
15. А вся справа в тому, що ... ⌘⌘ %%
16. Wenger Giant Knife
17. Коли реально застосовувати CMS? ⌘⌘ %%
18. Коли реально застосовувати CMS? (А серйозно?) ⌘⌘
19. Що ж залишається? ⌘⌘
20. Гарна цитата з приводу призначення CMS
21. WARNING! ⌘⌘ %%
22. Дайте проекту шанс вирости великим і гарним! ⌘⌘
23. Ви запитаєте, а якщо сайт робить НЕ програміст? ⌘⌘
24. Додаткові проблеми ⌘⌘
25. ЕТАЛОН УжОс ⌘⌘ %%
26. Приклади «УжОс» ⌘⌘
27. Про жахи Бітрікс
28. Зате «ми стали більш краще одягатися!» * ⌘⌘
29. Бітрікс - не єдиний приклад проблем ⌘⌘
30. Проблемними є майже все CMS
31. фреймворки
32. Для початку: що таке фреймворк? ⌘⌘ %%
33. Різниця в повсюдної інверсії управління ⌘⌘ %%
34. склад фреймворків
35. Проблема - Over-Engineering ⌘⌘
36. шаблони проектування
37. Фреймворки і SAPI ⌘⌘ %%
38. Фреймворки і функціонал ⌘⌘
39. Про повноту PHP і слабкою нужді під фреймворками
40. Що ж залишається PHP-фреймворк? ⌘⌘
41. Мінуси і плюси фреймворків
42. Область застосування фреймворків ⌘⌘
43. Плюси фреймворків ⌘⌘
44. Про інших плюсах і мінусах фреймворків
45. Закриті, внутрішні, малопопулярні фреймворки ⌘⌘
46. Внутрішні фреймворки - окрема пісня ⌘⌘
47. Про внутрішні фреймворками
48. висновки ⌘⌘
49. додаткові думки

Автор Віталій Філіппов Додатковий нижній колонтитул Мода на коробки і фреймворки в інтернеті - доки?

Назва доповіді

«Мода на коробки і фреймворки в інтернеті - доки?» (Лікнеп для менеджерів)

тези

• Як часто для розробки веб-проекту (не найбільш простого!) Вибирається коробочки CMS, а потім, поки програмісти люто намагаються впоратися з її недоліками, а за хостинг щомісяця відстібаються мільйони, менеджери, незважаючи ні на що, продовжують захищати свій вибір, аргументуючи це тим, що «інструмент відмінний» і його всього-то треба «трохи підкрутити, і мета точно буде досягнута»?
• А як часто вибирається жирний фреймворк (що, звичайно, краще CMS), який відразу починає нестримно обростати милицями, бо цілі, під які він розроблявся, не зовсім відповідають цілям проекту?
• Що спільного в цих підходах? По-перше, обидва підходи народжуються з одного бажання - бажання створити (а часто і продавати!) Продукт, який Начебто-Б може вирішити ... абсолютно ВСЕ завдання. А по-друге, і те, і інше настільки «увійшло в моду», що люди майже не замислюються про купу проблем, які отримають з вибором таких інструментів.
• Міркування саме про цю моду і про типові проблеми, одержуваних людьми разом з нею, і хотілося б донести в рамках доповіді.

план

• титульний слайд
• Про що ця презентація?
  • Потрібно зробити сайт. Варіанти: CMS, фреймворки, кастом.
  • Що ви виберете? CMS? FW? А кастом - «Фууу, лунапарк з БДЖ & Ш ??!», Так?
  • ⇒ 1 і 2 увійшли в моду, найчастіше люди не думають про наслідки.
  • А істина в тому, що кожен інструмент має область застосування. У CMS вона дико завищена, у FW частково теж.
• CMS
  • Що таке CMS? + Приклади.
  • Мінуси (дуже багато) і плюси (дуже мало), область застосування (вузька)
  • Приклад: пройтися вогнем по Бітрікс (жесть бляшана).
• фреймворки
  • Що таке фреймворк? + Приклади.
  • Спочатку загальні плюси (мало) і мінуси (багато), ідентичні оним Opensource-фреймворків.
  • Доп. мінуси платних фреймворків (яких під PHP майже немає)
  • Доп. мінуси внутрішніх фреймворків
  • Область застосування
• Спеціалізована розробка на основі бібліотек
• висновки

презентація

Мода на коробки і
фреймворки в інтернеті - Доки ?! ⌘⌘ %%

(Лікнеп для менеджерів)

Віталій Філіппов, CUSTIS

Припустимо, вам потрібно створити інтернет-проект ⌘⌘ %%

Що ви виберете?

Проблема моди ⌘⌘

• «Писати самим? Та ви що? Все вже написано до вас! »
• Є ж коробкові CMS! Поставив, і сайт готовий! Супер-підтримка від компанії-виробника!
• А також купа модних фреймворків! Zend, CI, Yii! Патерни, все і разом!

А потім ... ⌘⌘

• «Хостинг коштує мільйони!»
• «Сайт гальмує!»
• «Повільно впроваджуються доопрацювання!»
• «Постійно щось відвалюється!»
• «Все обросло милицями!»

… і при цьому:

«Ні, треба ще трохи докрутити, і мета буде досягнута!»

Треба було думати, коли вибирали! ⌘⌘ %%

... а не сліпо слідувати моді.

Бо (!)

Бо у кожного інструменту є своя область застосування

Введення: проблема моди

Отже, про що ця доповідь?

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

Звичайно, все залежить від конкретного проекту, але я майже впевнений, що знаю реакцію на третій варіант: «так ви що? знову створювати свій лунапарк з блекджек і повіями? все написано до вас! »І ви схиліться до CMS або фреймворку, майже не замислюючись про наслідки.

А потім РАПТОМ підуть скарги (особливо в разі вибору CMS) на те, що за розміщення серверів віддається сила-силенна грошей, сайт, незважаючи на це, гальмує і не витримує самого банального навантажувального тестування, все обростає милицями, а підрядники повільно впроваджують доопрацювання, які ще і постійно відвалюються ...

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

CMS

Що таке CMS? ⌘⌘ %%

* Just for Lulz: http://lurkmore.to/CMS

Що таке CMS? ⌘⌘

• C ontent M anagement S ystem
• Движок (ПО) сайту
• ;-) ... На якому можна зробити будь-сайт
• ;-) ... Причому без єдиного цвяха (рядки коду)

;-)

визначення CMS

CMS - це «Система Управління контентом» сайту. Хтось може розуміти під цим взагалі будь-движок будь-якого веб-додатки, але зазвичай, кажучи «CMS», мають на увазі CMS «загального призначення», що не заточені на вирішення однієї конкретної задачі. Наприклад, баг-трекер (Bugzilla, Jira, Mantis, Trac), хоча і мають якогось виду можливості динамічного управління вмістом, нікому не приходить в голову називати CMS'камі.

ОК, на основі баг-трекера не зробиш «звичайний» сайт. Але це не означає, що поділ явне - є ще один приклад: MediaWiki. На ній цілком можна зробити сайт, причому, якщо використовувати розширення - майже будь-хто. Однак MediaWiki теж не називають CMS. Так у чому ж справа?

А справа виключно в позиціонуванні системи, пропонованому її розробниками. Якщо позиціонування і мета розвитку - «можливість зробити все», перед нами, мабуть, дійсно CMS. Простий приклад - WordPress: спочатку це була блог-платформа і там були тільки пости, а потім хтось зрозумів, що якщо трохи її докрутити, то «постом» можна буде назвати широкий клас об'єктів з різноманітною структурою. І тепер WordPress став CMS'кой.

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

При цьому не всі CMS стовідсотково універсальні. Є і заточені під конкретний вид сайтів - наприклад, спеціалізовані CMS інтернет-магазинів - Magento, osCommerce. Але так як клас сайтів «інтернет-магазин» теж досить широкий (явно ширше класу «блог»), а дані системи намагаються їх охопити повністю - це знову-таки CMS'кі.

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

Стандартна фраза: ⌘⌘ %%

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

Сенс саме в спільності застосування ⌘⌘

наприклад,

• MediaWiki , MoinMoin і т. п. - Чи не CMS, а вики-движки (хоча сайт на них зробити можна)
• PhpBB , IPB - движки форумів

В той же час,

• WordPress - був движком для блогів, а став CMS
• osCommerce, Magento - спец. CMS, движки інтернет-магазинів
• Joomla, Drupal, MODx, NetCat, Бітрікс, UMI.CMS - це все CMS

Теоретично ... ⌘⌘ %%

... Можна будь-движок сайту називати CMS,
і лише розрізняти ступінь спеціалізації.

Але зазвичай говорять саме про CMS загального призначення.

Такі CMS - монстри ⌘⌘

• Складні і Неефективні
• З кривої архітектурою оптимізувати для всього ні для чого
• З купою зайвого функціоналу

А оплачувати все це вам (якщо раптом оберете)

Оплачувати вам це ... ⌘⌘

• Грошима продавцеві коробки
• Грошима хостера 1
• Грошима підрядникам при доработках2
• Репутацією в очах клієнтів

1 «Кому спам, а кому і трафік!» 2 дешевий - зазвичай кілька разів

А вся справа в тому, що ... ⌘⌘ %%

Універсальні інструменти несамовиті!

* Wenger Giant Knife

Wenger Giant Knife

Причому що характерно - скільки б ви думали він коштує? 100 $? 200 $?

А ось хрону з два! 2149.95 $.

Закон природи, такий же як і у випадку з CMS: потворність ще й коштує дорого.

Коли реально застосовувати CMS? ⌘⌘ %%

- Де можна виправдано використовувати Бітрікс?
- В анекдотах.

* Твіт з CodeFest-2012,> 200 ретвітів

Коли реально застосовувати CMS? (А серйозно?) ⌘⌘

Проект простий? ⇒ CMS не потрібна, бо це з гармати по горобцях Проект складний? ⇒ можливостей CMS напевно не вистачить,
а погана архітектура ускладнить їх реалізацію Проект відвідуваний? ⇒ упретеся в низьку продуктивність

Що ж залишається? ⌘⌘

Сіра масовка *

• шаблонні,
• не особливо відвідувані,
• бидло проектики.

* Які-небудь «портали» з копі-пі ** ерамі новин ...

Гарна цитата з приводу призначення CMS

Звідси

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

• Чи не володієте спеціальними навичками, але плануєте створювати посередні сайтики.
• Чи маєте навички, але плануєте серійно підгортати не мають навичок замовників посередній сайтик.
• Чи плануєте писати плагіни / аддони і т. П. З метою вилучення тонн слави і подальшого поневолення світу.

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

WARNING! ⌘⌘ %%

Формулювання розпливчаста!

Дайте проекту шанс
вирости великим і гарним! ⌘⌘

• Якщо сумніваєтеся в CMS - відмовтеся!
• Якщо вам продають сайт на CMS - відмовтеся!

При чому тут вирости?

Формулювання «посередній бидлопортальчік» дуже розпливчаста. Ви можете помилитися з оцінкою реального потенціалу проекту - і йому буде потрібно рости.

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

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

Простий приклад: багато CMS, наприклад Magento, використовують EAV «Entity-Attribute-Value» тріплетное сховище. Воно тупо загнеться, коли товарів в магазині стане багато, а атрибутика ускладниться.

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

Так що, якщо вам продають сайт на основі CMS - відмовляйтеся сміливо. Таким пропозицій місце в папці «СПАМ», з темою «бізнес-сайти за 5999 рублів» і очевидним будь-якій людині думкою про те, що контора - одноденка.

Ви запитаєте, а якщо сайт робить НЕ програміст? ⌘⌘

Тим більше не пускайте його за кермо CMS!

Нехай краще заведе

• Блог - ЖЖ / blogger / тематичні (drive2.ru, ...)
• Wiki (наприклад, на wikia.com)
• Групу в соціальній мережі

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

Додаткові проблеми ⌘⌘

• Розрахунок на доопрацювання дешевим ресурсом ... з плачевними результатами ...
• Закрита CMS - політична повія «будь збочення за ваші гроші»
• У CMS можуть бути корисні ідеї та фичи але часто вони поховані під шаром непотрібних ...

Детально про додаткові проблеми

Ключовою перевагою CMS їх виробники зазвичай називають те, що сайт з їх використанням створити легко, а отже, дешево. Але сайти рідко повністю вкладаються в стандартний функціонал, отже, до CMS потрібно прикручувати доопрацювання, силами програмістів. Окей, але наша фішка - дешевизна! Значить, і доопрацювання повинні бути дешеві. Значить, програмістів треба дешевих наймати! А хто такі дешеві розробницькі контори і що вони наворотів? Прааавільно, ось вам і плачевний результат, тим більш жалюгідний, чим довше виробляються доопрацювання. «Рарус, порвали Рарус! ..»

У закритих, платних CMS є ще одна проблема - закрита базова система практично завжди йде на поводу у своїх клієнтів, будь вони зовнішні або внутрішні, і навряд чи будуть вчити їх життя і забороняти їм робити так, як вони хочуть. А клієнти CMS найчастіше будуть хотіти зробити який-небудь жах, див. Пункт 1.

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

ЕТАЛОН УжОс ⌘⌘ %%

1С Бітрікс

Приклади «УжОс» ⌘⌘

«У професійному середовищі в ходу жаргонізм" говнокод "»

• Стиль коду «онуча»: 2032 рядки, (!!!) 0 функцій
• Само-DOS по 404
• «Інфоблоки» - криве об'єктне ядро, в студію!
• MVC без моделі !, «супер компонент»

Про жахи Бітрікс

Незважаючи на те, що інтернети кишать критикою даної комерційної CMS, причому навіть у порівнянні з іншими, безкоштовними (відкрито-вільними) CMS, вона чомусь все ще популярна. Причина криється, напевно, хіба що в маркетингу, тому що нормальних програмістів у них, мабуть, немає. Регулярно відбуваються виступи на конференціях, на яких то розкажуть, що чергова маркетингова фішка - Web Application Firewall - народилася, коли зрозуміли, що навіть досвідчені програмісти у них часто не екранують параметри в SQL-запитах ... то про те, що на завдання «завести бітрікс в AWS »у них пішов рік ... Те ще про що-небудь.

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

Почати варто з дикого для 21 століття стилю коду (печерний стиль). Багато компонентів написані не те що не об'єктно-орієнтовано, а навіть не процедурно - так як в коді часто взагалі відсутні процедури, а просто йде длііііінная онуча де-небудь на 2000 рядків. Про якомусь структуруванні такого коду мови, звичайно, йти не може. О, скажімо, спадкуванні я взагалі мовчу - воно там реалізується тільки за допомогою копіпаст.

Конторою на прапор піднімається то, що у Бітрікс є MVC. При чому тут MVC - взагалі незрозуміло: M - модель бізнес-об'єктів, інкапсулює логіку роботи з ними ж - там повністю відсутня. Весь «MVC» полягає в тому, що код компонента розділили на два файли - компонент і шаблон. Причому незважаючи на тривіальність цього поділу, серед бітрікс-розробників знаходяться люди, яким воно не подобається; вони винаходять (а то і знаходять на просторах інтернету) досить популярний антипаттерн «супер компонент», тобто порожню обгортку для шаблону, і всю логіку пишуть прямо в шаблоні. Один такий «супер компонент», наприклад, винайшов такий собі Іван Лівий. Ну да - реально лівий, що з нього взяти.

Прикольно реалізована сторінка помилки 404 «сторінка не знайдена» - якщо, не дай бог, вона обробляється Бітрікс, там буде 300 запитів в базу, і якщо, не дай бог, на головній виявиться розміщена бита посилання, на яку будуть заходити багато користувачів - сайт піде в «само-DOS» (само-відмова-в-обслуговуванні), бо обробка 404 з'їсть все ресурси. Та й в цілому, ~ 50 запитів на генерацію нескладної сторінки з включеним кешем і 500-600 з вимкненим - норма для цілком оптимізованого бітрікс-сайту. Тому робота даної CMS на разделяемом хостингу зазвичай приречена на провал.

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

Це були тільки обрані жахи, а в реальності їх куди більше. За критикою можна відправитися хоча б в російську Вікіпедію . До речі, там же згадується, що ніяких гарантій на роботу Бітрікс конторка не дає, і це чітко прописано в ліцензійній угоді. Також можна читати різні обговорення на різних Хабре, на кшталт такого: http://habrahabr.ru/post/152173/

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

Зате «ми стали більш краще одягатися!» * ⌘⌘

Зате Бітрікс24! І магазин компонентів!

І найкрутіша версія ~ 250000 рублів коштує!

:-( печаль і смуток.

* ... «Овочі там, жито!» © Світу з Іваново

Бітрікс - не єдиний приклад проблем ⌘⌘

ЖАХЛИВИЙ приклад. Але не єдиний.

☹

• Будь-які двигуни з EAV, наприклад:
• Та й інші CMS не блищать

... але вони хоча б Open Source.

Проблемними є майже все CMS

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

Всю ту ж лайка можна адресувати і до інших general-purpose CMS, до тих же WordPress, Joomla, специфічним Magento і osCommerce - з їх сумішшю верстки та коду і EAV-сховищем, яким сумно живеться за умови складної атрибутики і великий відвідуваності ... І використовувати їх в серйозному проекті - це так само курям на сміх.

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

фреймворки

Фреймворки (PHP) ⌘⌘ %%

ОК, CMS НЕ беремо.

Але PHP-фреймворки-то чим не догодили?

Для початку: що таке фреймворк? ⌘⌘ %%

Як і бібліотека, це

якийсь набір підключається функціоналу *

* Набір, але не простий

Різниця в повсюдної інверсії управління ⌘⌘ %%

визначення фреймворка

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

Однак є цілком зовсім різні - повсюдна інверсія управління (НЕ канонічний IoC, а інверсія в широкому сенсі):

• (Пряме управління) Ваш код запускається, а коли йому потрібно - викликає функції бібліотеки.
• (Зворотне управління) Запускається спочатку фреймворк, і ваш код викликає теж він - тоді, коли потрібно йому. Природно, всі ці «коли потрібно йому» задокументовані і при написанні коду ви зміцнюєте свої методи / класи на обрані точки розширення. Фактично, фреймворк - це в широкому сенсі «базовий клас» програми - ви можете від нього успадкувати і переопредіть частина його логіки - але зазвичай не можна переопредіть всю, чи не демонтуючи сам фреймворк.

Приклади PHP-фреймворків: Zend Framework, Code Igniter, Yii, Kohana, onPHP.

склад фреймворків

Фреймворки і патерни ⌘⌘

Чи корисно зводити в абсолют
патерни проектування? Ой не факт!

«You have a Problem and decide to use

Java . Now you have Problem, ProblemImpl, ProblemException and ProblemFactory. »Хабр: Всі використовують єдину фабрику фабрик фабрик інструментів щоразу, коли їм потрібен молоток? ...

Проблема - Over-Engineering ⌘⌘

Або ж, прагнення все надмірно узагальнити.

• ☹ Зайві шари абстракцій
• ☹ «Введення в конфіги всем.ру, том 2»
• ☹ Раннє впровадження зайвої розширюваності

Істинне зручність розширення: KISS, YAGNI *

* Keep It Simply Stupid, You Is not Gonna Need It.

шаблони проектування

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

У той же час розробляти з використанням фреймворку і ігнорувати патерни, в ньому закладені - зазвичай або незручно, або взагалі неможливо. Це-то і призводить до жартів про «фабриках проблем» і «фабрикам фабрик фабрик інструментів».

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

Можливо, проблема не в самих фреймворками, а в надмірній технологізації (Over-Engineering'е) - мається на увазі, коли творець системи, замість простої реалізації потрібного функціоналу відповідно до принципів KISS (Keep It Simply Stupid) і YAGNI (You Is not Gonna Need It), відразу починає надмірно його узагальнювати і закладати непотрібні точки розширення, результатом чого типово є:

• Зайві шари абстракції, в кращому випадку - просто зайві, а в гіршому - обмежують і роблять неоптимальним використання нижчих API.
• Відсутність точок розширення в потрібних місцях і наявність в непотрібних.
• Винесення в конфігурацію ВСЬОГО, надмірне узагальнення і як підсумок - складні (доменно-специфічні) мови конфігурації і опису функціоналу. Мем «введення в конфіги всем.ру, том 2» - коли я працював в Агаве над vsem.ru, конфіги там займали близько 470 кілобайт і 12000 рядків.

Фреймворки і SAPI ⌘⌘ %%

Серверів багато, API теж
(Модуль / CGI / SCGI / FastCGI / ...)

Немає стандарту? ⇒ народжується обгортка
Але в PHP SAPI вже є! Вельми повне, нехай і процедурне.

Фреймворки і функціонал ⌘⌘

Типові речі: шаблони, інтерфейс БД, сесії, завантаження файлів, SOAP ...

• У мовах загального призначення їх немає. ✓ Тема для фреймворка.
• Але в PHP є майже все × Фреймворк додає мало функціоналу.

Про повноту PHP і слабкою нужді під фреймворками

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

Запит від клієнта надходить до веб-сервера, який повинен його в якомусь вигляді передати в додаток. Вид передачі називається серверним API (SAPI), і в ньому вже виникає фреймворкоподобная «інверсія управління» - не ваше додаток викликає веб-сервер, а веб-сервер викликає додаток. Коли SAPI стає кілька, виникає потреба в абстракції - і це перша точка зародження фреймворка. Далі він доповнюється тим типовим функціоналом, якого так не вистачає в мові - і вуаля, фреймворк готовий!

Найпростіші приклади - Perl і Java. Веб починався з перла і CGI, і PHP в жарт називають «Pa`am Hayiti Perl», що в перекладі з івриту означає «колись я був Перлом», проте за весь час в Перлі так і не з'явилося стандартного SAPI. Є CGI, але він неповний - наприклад, для обробки завантажених файлів потрібен додатковий обробник. Є й інші API, я їх навіть розглядав у своїй вікі - Платформи для запуску Perl веб-додатків , Але стандарту все одно немає.

З приводу бібліотек - хоча у Перла є офігенний плюс - CPAN, на якому лежить купа бібліотек майже під всі потреби, які можна поставити однією командою - дивно, але на всьому CPAN'е немає нормального SOAP-клієнта! (Всі вони так чи інакше обмежені в можливостях)

А в PHP SOAP-клієнт, та й стандартне SAPI, і взагалі майже все інше, вбудовано прямо в інтерпретатор! У вигляді модулів. Так, це, може, і не дуже красиво, зате дуже зручно - не треба тягнути 100500 залежностей з CPAN'а, а поставив три з половиною модуля і все вже працює. Тим більше, що зазвичай майже всі модулі вже стоять.

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

Тому такий шлях зародження фреймворка в PHP «не котить». І тому ж сам PHP популярний - його дуже легко підтримувати.

Що ж залишається PHP-фреймворк? ⌘⌘

Відповідь: обгорткою!

• Для всього! іноді в кілька шарів.
• Бувають жорсткі, незмінні без патчінга.
• Крім обгорток - лише дрібні корисні фічі.

Мінуси і плюси фреймворків

Крім того ⌘⌘

Фреймворк - жирна залежність!

⇒ Для бібліотек не підходить ⇒ Доп. джерело багів і дірок ⇒ Проблеми глобальних оновлень ⇒ «Автобусний фактор»

Область застосування фреймворків ⌘⌘

• Проект простий? × ускладнить реалізацію.
• Проект складний? × Багато унікального прикрутити збоку. *
• Бібліотека? × Обмежить використання.
• Проекти, де багато однотипного функціоналу. ✓ Підходить! і це сильно ширше, ніж у CMS.

* Гнучкий (пермісивними) фреймворк хоча б не зашкодить.

Плюси фреймворків ⌘⌘

• Плюс для продажу піддалися моді менеджерам
• Для початківців розробників
  • Обмежувач застосування бурхливої ​​незміцнілої фантазії *
  • Підмога в навчанні

* Якщо фреймворк готувати за канонами.

Про інших плюсах і мінусах фреймворків

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

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

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

Жирна залежність - насправді мінус для будь-якого проекту. Ось перші прийшли на думку три причини, чому:

• Фреймворки теж пишуть люди, які теж роблять помилки. Будь-яка залежність - це потенційне джерело багів і дірок безпеки.
• У деяких фреймворків маленький «автобусний фактор», тобто кількість його розробників, яке може збити автобус без загрози серйозних проблем для проекту. Залежачи від такого фреймворка, ви залежите і від тих самих ключових сторонніх осіб.
• Фреймворк не стоїть на місці - його потрібно оновлювати. Це не мінус до тих пір, поки команда проекту не вирішить повністю переписати фреймворк і зробити його несумісним з колишньою версією. Практика показує, що це цілком відбувається - ось недавно зарелізілся Zend Framework 2.0, який «will look alien to you if you've worked significantly with ZF1».

У фреймворків, звичайно, є і плюси. Головний з них «рукотворний» - додаток, написане на основі фреймворку, зручно продавати піддалися моді менеджерам і / або піддалися моді клієнтам ( «фейшн», як каже наш співробітник Коля Гребньов). З огляду на те, що мода на PHP-фреймворки прийшла не так давно, приїстися вона ще не встигла, тому ... воно працює.

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

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

Закриті, внутрішні, малопопулярні фреймворки ⌘⌘

Мають додаткові мінуси:

• ☹ Погана документація (а то і відсутність)
• ☹ Дивні практики (PHP Jihad, аліментник)
• ☹ Політична проституція (закриті, внутрішні)
• ☹ Неможливість перевизначення

Внутрішні фреймворки - окрема пісня ⌘⌘

• ☹ Потребують підтримки
• ☹ Слабо конкурують з mainstream
• ☠ Схильні до вмирання

Звідси висновки:

• Або OpenSource, або не покладатися на них
• Обов'язково робити пермісивними, а не жорсткими

Про внутрішні фреймворками

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

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

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

Звідси можна зробити наступні висновки:

• Внутрішні фреймворки повинні бути максимально гнучкими, щоб вміти нормально співіснувати з зовнішніми, якщо таке знадобиться.
• Для захисту від вмирання фреймворк потрібно намагатися виводити в OpenSource - це найпростіший шлях до популярності (при цьому не такий простий сам по собі). Логічно - якщо це намагатися ще й продавати, воно взагалі нікому потрібно не буде. А спільнота може підказати правильний шлях розвитку.

висновки ⌘⌘

• Не піддавайтеся моді! Кожен інструмент має свою область застосування!
• Доля застосування CMS - бидлосайтікі.
• Доля фреймворків - середні за складністю проекти (+ продаж «модникам»).
• Чи погано, що вони є? Та ні. Природа любить різноманітність.

<МІСЦЕ ДЛЯ ВАШИХ ПИТАНЬ> ⌘⌘ %%

E-mail:

Наші OpenSource проекти: http://wiki.4intra.net/

$ This = http://yourcmc.ru/wiki/CMS-Frameworks

додаткові думки

• Спільність - ЛІНЬ, вічне бажання отримати результат, нічого не роблячи.
• http://ru-anticms.livejournal.com/3931.html
• http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
• Неправильне застосування псує навіть непоганий в цілому інструмент. Приклад - OpenX призначений для організації невеликої «банерної мережі», а, наприклад, не для показу 5 банерів на сайті.
• Головний плюс рукотворний: PHP-фреймворки - це мода, яка спрощує продаж менеджерам, які чули buzzword, але не розбиралися в питанні.