Сегодня в моде фреймворки с архитектурой типа MVC. Программисты в большинстве случаев гонятся за всем новым. Новыми версиями языков, новыми паттернами, новыми библиотеками, ну или новыми языками 🙂

Все это прикрывается благими намерениями: скорость, безопасность, эффективность.

Хотя на самом деле, если вдуматься, то в 99% случаев реальных причины две:

  • мысль о том что там где нас нет — трава зеленее
  • плохому танцору яица мешают

Хрупкость и Антихрупкость

Вся эта ситуация влечет такой феномен как Хрупкость систем. В понимании Нассима Талеба, которое он озвучил в своей книге — Антихрупкость.

Вкратце попробую передать базовую идею тезисами:

  • Хрупкость систем — это их плохая предрасположенность переносить изменения. Изменения ломают систему. Влекут деградацию.
  • Идея Антихрупкости часто является антогонизмом идеи Эффективности. Чем лучше эффективность, тем выше хрупкость. Чем лучше антихрупкость, тем ниже эффективность.
  • Нельзя сказать какая система Хрупкая, а какая Антихрупкая в вакууме. Можно лишь сравнивать 2 похожие системы относительно одного события и говорить о том какая из них переживет это событие с наименьшими потерями и наибольшей пользой для целей ее существования. Какая более Антихрупкая, а какая более Хрупкая.

Как вся эта философия связана с MVC, фреймворками и т. д?

А связана она очень просто, если взять это понимание Хрупкости и Антихрупкости, то все системы которые строятся на современных фреймворках — тотально Хрупкие.

Да они эффективные, да при грамотном подходе они могут быть быстрыми. Но они крайне плохо поддаются изменениям, стрессам и обновлениям. В этом суть их Хрупкости.

Мы гонимся за Эффективностью, делая системы Хрупкими. В общем то программисты не одни в этом намерении и если прочитать книгу Антихрупкость, то станет ясно что весь мир летит туда же. Большинство людей, отраслей, экономик, социальных и технических системы — в погоне за Эффективностью, становятся Хрупкими. От сюда кризисы, войны, проблемы, болезни, плохая переносимость стрессов и т. д.

Однако во всех правилах есть исключения:

  • IKEA
  • Ford (при жизни Генри Форда)
  • WordPress

 

Что объединяет эти разные организации?

  1. Они не экономят на качестве
  2. Они не гонятся за эффективностью (прибылью)
  3. Они стали лидерами своих рынков

 

Вообще тема Антихрупкости крайне глубока и интересна.

Но тут возьмем для примера лишь один аспект — обновление ядра сайта или веб-приложения. Ни для кого не секрет, что время от времени ядро платформы нужно обновлять. Сравним фреймворки с WordPress.

И далее есть 2 веселых сценария:

  • мир молодых и хрупких фреймвоков (laravel, symfony, yii, nodejs …) — даже для мелких систем обновление часто превращается в ад. длится месяцами. для крупных систем обновления часто просто проваливается и система остается жить на старом ядре. до тех пор пока ее не перепишут вообще с нуля.
  • мир WordPress — зачастую обновление просто случается 🙂 Пользователь случайно нажал кнопочку, обновился, не заметил этого и пошел пить чай. Для средней сложности бывает нужно привлечь среднего программиста на пару часов. для крупных систем (на 50-100 модулей каждый размером с Laravel) где есть программисты с кривыми руками — бывает надо потратить пару недель на чистку кривого кода.

Про Скалолазание

Почему так происходит? Ответ как раз в Антихрупком подходе и отсутствии гонки за Эффективностью.

Есть правило известное среди Скалолазов — как минимум 3 точки опоры при изменении положения 1 конечности. Нельзя резко изменять свое положение на Скале, из 4х конечностей в один момент времени можно менять только одну. А остальные 3 должны крепко держаться. Иначе будет срыв и Game End.

В мире программистов оно известно как Обратная совместимость. Его многие программисты очень не любят. Потому что это не весело. Это очень скучно. Еще и очень сложно. Задачи этого типа способны выдержать только очень сильные программисты. Слабые изноются.

В мире WordPress понимают что такое Антихрупкость, что такое Обратная совместимость. Что очень важно не делать резких изменений, нужно оставлять мосты для старых систем. Старые механики сразу не удаляются, остаются в системе. Новые добавляются очень осторожно. Дается время системе измениться в глобальном масштабе. Часто на изменение одной функции уходит 3-4 года, пока все сайты в мире отпустят старую функцию и перейдут на новую. И вот только тогда старую функцию удаляют. А таких изменений может быть огромное количество.

И это тяжело. Дорого. Скучно. На такое нужно потратить колоссальное количество времени очень сильных программистов (как сказано выше слабые такое не тянут).

WordPress себе такое может позволить. Точнее у него нет выбора если он хочет стать №1 в мире. А так он и есть №1 в мире? Хорошо. Тогда если он хочется остаться №1 в мире — он должен и дальше соблюдать это правило.

Большинство фреймворков соблюдать это правило не могут. Потому что сообщество таких фреймворков состоит из слабых программистов, которые чуть что начинают ныть. Заниматься чем то новым — всегда интересно. А вот сохранять мосты и обратную совместимость — очень тяжело. Слабые выбирают простые пути. Потому что силы воли не хватает выбрать сложный путь.

Если вернуться к Скалолазанию, то представьте Скалолаза, который меняет свое положение прыжками. Ну типа вот закрепился на Скале, ему надо чуть вверх и вправо. Он берет, отталкивается от текущего положения и прыгает в следующее… как долго проживет такой Скалолаз?

Ровно так и живут большинство Фреймворков. Они напрочь сжигают мосты от версии к версии, ломая к чертям обратную совместимость. Когда то улетел вниз Yii, потом Ruby on Rails — громко зашел на сцену и тоже улетел вниз. Очередь за Laravel и Symfony?

Работают с такими инструментами только начинающие или слабые программисты. Сильные и опытные, кто повидал уже провалы проектов и имеет опыт создания больших систем на длительном горизонте планирования, понимают что такие прыжки это очень плохо. И с опытом начинают понимать суть и силу WordPress.

Про WordPress 

И вдруг становится ясно реальная причина по которой WordPress стал №1 в мире. Причина не в том что он был первый (он был далеко не первый). А в том что там сумели понять философию Антихрупкости, осознают важность Обратной совместимости. Ну и потому что там есть программисты с яицами. Которым ничего танцевать не мешает.

Да, конечно никто не отменяет факт что большинство начинающих WP-программистов очень слабы, но воронка конверсии на входе очень большая, архитектура и политика очень грамотная и потому на выходе те кто остался жив — это очень крутые ребята. В книге Антихрупкость кстати тоже есть описание этого феномена и называется он «Стратегия Штанги». Описывать не буду. А то мозг вскипит 🙂 Просто добавлю что если мне надо найти реально крутых программистов, то искать их буду в сообществе WordPress.

Ну и причем тут MVC? О которой была речь в начале 🙂 А при том что современное понимание MVC и есть причина Хрупкости. Да она легко понимается. Она решает часть мелких проблем тех кто писал на голых языках. Но это очень мелкий полет мысли, который и ведет к Хрупкости. Как говаривал Ален Кей — по истине большая идея это когда объекты обмениваются сообщениями, также он говорил что секрет создания больших систем — не думать как модули устроены внутри, а думать о том как модули будут взаимодействовать друг с другом. Вся фишка WP в том что там есть зрелая система обмена сообщениями между объектами (плагинами). Идея которую 40 лет назад озвучил Ален Кей, но которую до сих пор мало кто из программистов сумел услышать, осознать, понять и научится применять.

Так и что теперь не использовать фреймворки?

Не совсем. Просто надо понимать что фреймворки это про Эффективность и Скорость. Нужна скорость? Берем фреймворк. Главное понимать что на жертвенный алтарь вы кладете свою Антихрупкость. Вы и ваша система становится «хрупчее». В больших системах — это единственный путь развития. Там рано или поздно приходится разносить нагрузки на микросервисы. Главное не делать этого на старте и до тех пор пока не появились веские причины делать очередной микросервис.

Однако в большинстве случаев (не для всех) автор предпочтет WP. За его Антихрупкость и способность легко переносить изменения, легко обновляться и сохранять боевой дух на длинных дистанциях.

Важно выбирать инструменты адекватные задачи. И все будут хорошо 🙂

P.S. Статья не претендует на объективность и адекватность. Просто накрыл поток мысли и мне надо было куда то это записать 🙂