Размер имеет значение

    И черт меня дернул написать материал «Фреймворки — больше минусов чем плюсов». Точнее назвать материал именно так. Пылился он себе, пылился в песочнице, но вот в прошлом месяце его оттуда извлекли и… такого количества комментариев я не ожидал.

    Сразу стало понятно, что ответить всем не получится. Честно попытался сделать, но быстро сообразил, что проще написать еще один материал. Чем сейчас и занимаюсь. И так.

    Ответы


    Ответ на первый вопрос.

    Нет, я не пытаюсь никого учить. Как минимум мне за это не платят. А делать столь тяжелую и, зачастую, неблагодарную работу бесплатно я не намерен. Так что здесь я просто высказывают своем мнение, с которым каждым может либо соглашаться, либо нет.

    Ответ на второй вопрос.

    Наши проекты. Не уверен, что здесь можно размещать подобные ссылки. Потому, если интересно, напишите мне в личку, скину их там.

    И третий вопрос — самый интересный.

    Наши инструменты. Ответ на этот вопрос, как мне кажется даст ответы и на все остальные. Потому здесь поподробнее.

    Как правильно сказал Dinver, под те требования, что я пытался выдвинуть в отношение инструментов, для WEB разработки, подходят 90% микрофреймворков. Да именно так! Я не против вообще всех фреймворков. И не против инструментов, облегчающий разработку и снижающих ее время. Собственно об этом я писал в первой статье, но почему-то большинству бросился в глаза только заголовок. И более того — мы сами используем такой инструмент.

    Откуда ноги растут


    Не буду сейчас углубляться в сравнение существующих микрофрейворков. Это тема для отдельного большого материала. Хочу лишь сказать — писать свой нас заставило не то, что в существующих чего-то не хватает, а то, что на момент, когда в них возникла необходимость, а было это уже больше 10 лет назад, стоящих мы найти не могли. Сейчас положение вещей изменилось, но это уже, как мертвому припарка. Теперь то, что есть у нас, мы считаем ни чуть не хуже, а во многом даже лучше, аналогов. Конечно это дело вкуса, но то что для нас наш инструмент более удобен – наше мнение на которое мы тоже имеем право. А вот почему он нас устраивает, постараюсь продемонстрировать.

    Суть


    Во-первых, в основе всего лежит написанный нами gem для Ruby. И написан он на чистом Си.
    Да именно так. Когда количество законченных проектов было уже достаточно существенным и пришло понимание, что 50% кода просто кочует из проекта в проект, мы решили не просто систематизировать свои наработки, а сделать их лучше и быстрее. А, что работает быстрее, чем код на Си? И, что может быть более дружелюбно к программисту, чем язык Ruby, созданный Matz-ом именно с целью облегчить наш труд?

    Как следствие, сейчас с одной стороны производительность работы выросла в разы. А с другой, время отклика любой страницы написанных нами проектов укладывается в 300-500 mc при любых нагрузках. При этом, конечно, нужно упомянуть, что мы используем и своей application server, так же написанный на Си.

    Для примера привожу скрин страницы одного из наших проектов. Это crn для типографий, позволяющая управлять, как процессом приема заказов, так и всем производственным циклом. На скрине страница списка заказов. Весь список не видно, но поверьте он достаточно внушительный. При этом по каждой записи выдается не только название и дата, но и краткая статистика. А именно: сумма оплат, перечень продукции, стоимость материалов по каждой, данные покупателей. Одним словом для формирования этой страницы приходится выполнять больше полусотни запросов. При этом время отклика 395 mc, а размер gem-a меньше метра

    image

    Подробности


    Если Вас все выше изложенное не заинтересовало, то дальше можно не читать. Дальше будет просто небольшое описание. Совсем, совсем краткое. Если же кого-то оно заинтересуют, готов предоставить полную документацию. Здесь это вряд ли уместно.

    И так. В gem-e, о котором я упомянул, собраны классы и функции, что мы используем чаще всего.
    Главный класс носит название Vdcgi. При его инициализации происходит:

    1. парсинг HTML заголовков. Все параметры, переданные безразлично каким методом, а так же coocki, становятся доступны через массив «param» экземпляра класса. Если были преданы файлы, то ссылки них можно получить из массива «hash_img». Сами файлы до окончания работы скрипта хранятся в /tmp и затем удаляются. При парсинге параметров учитывается уровень доступа пользователя и переменная level, устанавливаемая в конфигурационном файле. Если уровень доступа меньше, чем level, то применяются жесткие правила, при которых из всех переданных запросов «выбиваются» потенциально опасные символы ' < и так далее. Если level больше, то в дальнейшем такие символы просто экранируются стандартной функцией библиотеки mysqlclient
    2. подключение к базе данных. Если подключение прошло успешно, то все запросы к базе можно выполнять через экземпляр класса.
    3. Происходит авторизация пользователя. Если «зашел» авторизированный, то получается его уровень доступа и все данные пользователя.
    4. Получается имя основного шаблона используемого для формирования страниц
    5. Устанавливается глобальная переменная определяющая язык интерфейса страниц
    6. Получается сео информация для запрошенной страниц title, leywords и так далее

    Второй по значимости класс — VdMainapp. Вот некоторые функции это класса

    1. menu – формирует массив для вывода меню на странице
    2. writelink – создает ссылку
    3. get_class – возвращает массив классов которые должны быть инициализированы
    4. fotos – возвращает ссылку на фото и т.д

    Перечислять все функции и классов смысла здесь нет. Упомяну только основной функционал

    VdUser – работа с данными пользователя
    VdKassa – все связанное с платежами и финансами.
    VdVideo – для погрузка видео по ссылкам
    VdNet – сетевые функции
    VdAdmin – функции администрирования
    VdImg – капча и фото
    VDArcticle – все что нужно для добавления на сайт текстовых материалов
    VDMessages – все для чатов, тикетов и т.д

    Все выше перечисленное – очень, очень скромное даже не описание того, что есть. Однако, думаю, даже из него Вы поняли – только лишь gem-ом тут дело не ограничивается.

    Действительно кроме самого gem-a есть еще:

    • база данных (а точнее несколько – одна основная и по одной на каждый язык)
    • набор шаблон для шаблонизатора erubis
    • набор js скриптов
    • набор заготовок для расширения уже существующих классов
    • определенное количество Ruby скрипов работающих с AJAX функциями упомянутых выше js.

    А еще есть cкрипт instal.rb который все это разворачивает по вашему запросу.

    При запуске последнего Вам нужно будет указать директорию проекта и параметры подключения к базе данных. После чего в указанной директории вы получаете все необходимые файлы, а на вашей локальной машине сконфигурированный сервер nginx и фактически работоспособный сайт с минимальным набором страниц и админ панелью. В последнюю можно попасть с логином/паролем admin admin. Внутри Вы сможете добавить остальные страницы, определить их вложенность указать для каждой сео информацию. Ну а дальше – полная свободна творчества.

    Несколько ложек дегтя.


    Еще раз хочу подчеркнуть. Вопреки мнению некоторых, комментировавших первую статью, я не пытаюсь никого учить. Я даже не пытаюсь не то что навязывать, а даже предлагать работать с нашим инструментом. Хотя он есть в открытом доступе на нашем сайте, но всегда рассматривался только для «внутреннего потребления». Схема была проста – если какой-то функционал присутствовал более чем в 3 проектах, мы переписываем его на Си и добавляем в gem. При этом ни кто не старается навести особую «красоту». Как следствие, если рассматривать его как нечто, что я мог бы предлагать всем, то нужно признать, что проект достаточно сырой. В нем много чего не хватает. Например нет поддержки PostgreSQL (которую, кстати уже пишем) и еще ряда полезных «плюшек». Потому, если у кого-то есть желание познакомиться поближе, – милость просим, но только, как говорится, «под вашу ответственность».
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 15

      +2
      «фреймворки не нужны поэтому мы используем in-house аналог»
        +5
        «У нас был собственный вебсервер, CGI, взаимодействие с базой данных, авторизация, и формирование клиентских страниц, а еще это было написано на си. Не то, чтоб это был необходимый запас для всех нужных нам фич, но включив NIH-синдром, остановиться уже трудно. Единственное, что у меня вызывало опасения — это сторонние фреймворки. Я знал, что рано или поздно мы перейдем и на эту дрянь...»
          +1
          "… и соскочить с нее будет очень трудно"
        +2
        Непонятна мотивация минусования, автор же честно рассказал о том, к чему пришла его компания, которая судя по всему работает не первый год и даже не два.
        Если их собственный фреймворк помогает им вести разработку быстрее и дешевле и при соблюдении требований к проектам, то «почему бы и нет»?
        За мои 15 лет в разработке бекендов, были кучи примеров таких «инхаус» перед глазами, причем иногда все начиналось с популярных фреймворков, которые потом допиливались/перепиливались до нужной функциональности и уже становились теми же самыми «инхаус». Но в конечном итоге, после жизненного цикла в 5 лет, становилось очевидно, что дешевле было сразу создать свое, нежели чем адаптировать что-то стороннее.
        Сей рецепт не универсален, и есть тысячи случаев, когда именно не надо пилить свое, но это же не означает, что инхаус это всегда плохо?
          +2

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

            –1

            Ну а про тесты, документацию и скорость исправления багов я вообще молчу.

              +1
              Насчет не модернизируется вот не соглашусь. Если отдел разработки «пилит какое-нибудь и-коммерц ядро системы» для своей компании, то как раз ситуация может быть прямо противоположной. У нас как раз такая ситуация, выкатываем по 3..4 апдейта прода в неделю, из них как минимум 1 достаточно существенный. Приблизительно половина апдейтов случаются после обнаружения/устранения багов и по результатам профайлинга, а вторая половина — новые фичи или очередное А\Б тестирование.

              У любого подхода есть минусы и плюсы. Если плюсы в частном случае перевешивают, то почему бы и не пойти таким путем? В нашем случае, мы получаем приличную производительность (по нашей предметной области). Никакой коробочный софт или фреймворк даже близко не сможет такое дать. И естественно продать на сторону этот свой «инхаус фреймворк» как коробочное решение (или фреймворк) мы не сможем. Но у нас и задачи такой не стоит.
                +2
                Про апдейты — у нас практически аналогичная ситуация И про производительность — полностью согласен Причем для нас это главный приоритет.
                  0
                  У кода не может быть проблем априори. Он написан и работает ровно так, как его написали. И у вас судя по всему нет проблем на вашем рабочем месте. И «движок» ваш крут. Проблемы возникают, когда программист либо уходит из вашего проекта или приходит к вам. В первом случае с большой долей вероятности знания о вашем «движке» можно оставить у дверей на выходе. С такой же вероятностью у вас при смене работы станет важным знать и уметь в «Симфони»(в кавычках). А нового коллегу придется учить вашему «подходу» и всем оптимальным ходам.

                  «То что один программист может сделать за месяц, два могут сделать за два.» — фреймворки помогают делать именно за месяц или полтора. Стремятся к этому.
                    0
                    Да в какой-то степени Вы правы. Если к нам приходит новый человек он какое-то время учится. Но знайте, что самое интересное? Когда-то у нас была попытка написать проект на рельсах. Взяли человека который утверждал, что рельсы он знает очень хорошо. Проект был достаточно сложный, как в общем и все наших проекты. Это был маркетплейс по покупке с доставкой сыпучих строительных материалов. Там было более 2к в водил которые размещали свои предложения и, когда заходил покупатель, для него нужно было автоматически сформировать наилучшее предложение на основании имеющихся прайсов (порядка 60к) расстояния доставки и еще некоторых факторов.
                    Так вот пока писалась общая «обвязка» проблем не было. Но как только дело дошло до основного функционала тут все и застряло. Чтобы понять как это сделать нашему новому сотруднику приходилось лезть в маны, в которых далеко не всегда получалось найти нужную информацию. То есть пять же учиться. Причем учить чужой продукт, согласитесь сложнее чем свой. А для части функционала решения вообще найти не удалось и пришлось писать костыли. В результате — время разработки выросло непомерно и продукт получился, честно говоря не очень.
                    Так вот мораль сей басни такова — если Вы пишите какие-то стандартные проекты, в которых нет особо сложного, уникального функционала Вы вполне можете обойтись коробочными решениями. Тем более для большинства их заказчиков те mc, о которых я писал, честно скажем, значения не имеют. Но если вы делаете, что-то более сложное и уникальное то тут «швейцарский нож» с кучей инструментов не подойдет. Нужен «десантный нож» который может и не «умеет» кофе подавать, но в своей специализации на высоте. И иногда его приходится «ковать» самим. Потому мы и не берет дешевые проекты )
                      0
                      Под узкоспециальные задачи или ресурсоемкие процессы легко написать микросервис, отдельного «демона» или «воркер» хоть на вашем хоть на С. При этом обвязка будет написана любым из 1000 без дополнительного обучения.
                        0
                        Иными словами написать тот самый костыль о котором писал tuxi чуть выше ) Может сразу использовать то что этих костылей не требует?
            +1
            Вот тут позволю себе не согласиться. Весь функционал постоянно дорабатывается и улучшается. У нас часть наших программистов работает над проектами заказчиков, а часть над инструментом для них и это процесс постоянный.
              –2

              «Приходите к нам, у нас вы за месяц научитесь пилить на НЕфреймворке, и наберетесь ценного костыльного опыта, который вам нигде не пригодится, потому что на этом НЕфреймворке больше никто не пишет»


              Какой программист в здравом уме пойдёт к вам закапывать себе карьеру?

                0
                Кто сказал что мы кого то приглашаем? А по поводу ни кто не пишет — почитайте посты выше. Да и за месяц Вы программистом точно не станете. Это байки «интернет экспертов»

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое