Приближение к front-end-фреймворку

    Хочу поделиться своими открытиями и рассказать про набитые шишки на пути создания фреймворка для моего работодателя.

    Аутсорсинговые ИТ-компании часто работают с клиентами из одной и той же рыночной ниши, разрабатывая сходные решения. Вполне естественно возникает желание избежать изобретения одного и того же велосипеда в каждом новом проекте. Большинство разработчиков за время своей карьеры вырабатывают свои собственные фреймворки, что кстати является неплохим показаетлем их компетентности. А тенденция превращения веб-страницы из документа в арт-объект переводит наличие фреймворка из разряда желательного в разряд необходимого, т.к. пренебрегать связностью команды, универсализацией (и ожидаемой от неё синергией), снижением объёма рутинных задач и связанного с ними стресса становится всё труднее.

    У готовых фреймворков есть серьёзный недостаток — фреймворк является слепком коллективного сознания (и подсознания), предпочтений, стиля команды его разработчиков, а также его изначально так или иначе «затачивают» под решение определённой (своей) задачи. Проблема в том, что эти задачи или слишком конкретные (и шаг в сторону от внутренней логики фреймворка карается «шатанием» всей конструкции), или слишком абстрактные (и есть опасность использования фреймворка только ради использования фреймворка). Для себя я обнаружил, что создание собственного фреймворка как некий постоянный процесс внутри ИТ-компании или отдела имеет много побочных положительных эффектов. И вот почему: когда собирается команда под проект, очень часто выделяют набор абстрактных проектных ролей, а не коллектив реальных личностей, т.е. например аналитика и дизайнера, а не Сергея О. и Сергея М., у которых есть совершенно конкретные (и разные) ценности, видение, свои особенности восприятия и проблемы с коммуникацией. Когда же эти проблемы всплывают и заставляют менеджмент обратить на них внимание, то проблемы коммуникации и сработанности оценивают по каким-то средневзвешенным или косвенным показателям, а решают факапами и «общеукрепляющими упражениями-тренингами-распитием». Хотя именно созданием своего фреймворка эти проблемы можно как минимум вскрыть.

    Профессиональный работник выделяется (как минимум) 3-мя признаками: процессом, фреймворком и самоанализом (работой с фидбэком свой деятельности). Причём все эти вещи индивидуальны и органичны для конкретного человека. Стоит задача скомпилировать общий фреймворк, который потянет за собой установление и откалибровку более качественного общего процесса и позволит делать самоанализ в масштабах команды или даже компании. Причём надо соблюсти личные особенности участников, но при этом фреймворк должен быть полезен всем участникам процесса разработки. Начнём с front-end-фреймворка. Front-end-фреймворк здесь подходит как ничто другое, т.к. в нём могут быть запакованы ожидания и видения всех участников проекта, также интерактивные компаненты интуитивно понятны и иллюстративны, это классный срез.

    Под бесполезностью фреймворка будем понимать соотношение времени, затраченного на его создание, ко времени, которое удалось сэкономить за счёт его применения, этот показатель полезно публиковать в виде плаката в курилках. Начнём с анализа существующего портфолио компании и сделаем следующую визуализацию: разместим все проекты компании как точки в дискретном пространстве (назовём его пространством компетентности команды/компании) с коодинатами по осям «IxD Patterns», «Visual Design Concepts» и «Back-end Requirements and Restrictions».



    Координаты конечно же условны, точки-проекты стоит располагать ближе/дальше от типичных «узловых» решений с координатами вроде Проект-Икс(сайт-визитка; в минималистичном стиле; на Drupal). Разберёмся с осями. Предложите вашему интерэкшн-дизайнеру (из-за путаницы с должностями сложно угадать как этот человек называется у вас) разобрать паттерны, которые применялись в создании предыдущих проектов, и составить из них список в терминах (например) welie.com/patterns в порядке убывания частоты их использования, этот список будет шкалой на данной оси. Создание градуировки этой оси требует существенных интеллектуальных усилий, однако у человека с опытом наверняка уже выработалась собственная иерархическая система, которую легко интерпретировать в подобную шкалу. Тут стоит определиться и со степенью погружения в детали, принять за паттерн-засечку сайт-визитку, или, скажем, блок вроде главной навигации, опять-таки всё решает компетентность/опыт. Далее предложите вашему графическому дизайнеру в компании с кодером определить шкалу «возрастания сложности» внешнего вида для каждого из паттернов предыдущей шкалы, лучше всего, если дизайнер отрисует их в виде эволюционного ряда, например:

    Evolution

    А у кодера при этом сложится понимание, как создать решение вроде <tag class=«button button-frutiger button-curved-7px button-gradient-03 button-shadow-04» ...>Caption</tag>, когда он сможет без существенных временных затрат первращать один скин в другой. Предварительно определитесь со списком «поддерживаемых» дизайнеризмов или т.н. «sure fire» техник исполнения. Это наиболее субъективный момент, личные качества дизайнера и кодера, их способности к коммуникации могут стать причиной провала всего начинания. Наконец, предложите back-end-разработчикам составить шкалу из требований/ограничений для каждого из паттернов, с точки зрения применимости и «удобоваримости» решений в рамках используемых ими движков. Следует максимально широко обсуждать каждую ось, точки на осях и весь процесс создания фреймворка, используя wiki-подобные решения, т.к. ценность результата для всех участников разработки гарантируется только степенью их вовлечённости.

    Осей/параметров для описания проектов конечно же гораздо больше, можно вспомнить слои User Experience от J.J. Garrett’а, но предложенных 3 осей вполне достаточно, чтобы вычленить ядро — наиболее часто изобретаемый командой/компанией велосипед. Это ядро описывает объём фреймворка, создание которого будет полезным для данной команды/компании с учётом ориентированности на нишевых заказчиков, в дальнейшем объём достаточно плотной части ядра можно рассматривать как индикатор роста/сужения компетентности и использовать его при планировании роста, анализе конкурентов и т.п.

    В дальнейшем, когда фреймворк существует, разработка должна сводиться к использованию решений из фреймворка с незначительной доработкой, в случае, когда во фреймворке нет подходящей заготовки, в первую очередь расширяется фреймворк, а затем с его помощью получаем частное решение, это гарантирует сохранение инерции в эволюции. Создание фреймворка — вечный проект, вокруг которого должны не умолкать дискуссии, следует сделать процесс его создания касающимся всех и каждого с отвественными лицами, кураторами из числа неформальных лидеров сообществ внутри компании, билдами (которые вполне можно сделать коммерческими продуктами). Создание front-end-фреймоврка сейчас может совпасть с переходом на html5 и может помочь вам трансформировать содержание труда разработчиков из скоростной выдачи своей порции на общий конвейер в акт совместного творчества в духе дадаистов или художников поп-арта. Идеальный эффект: когда все участники команды подсознательно находятся как-бы в непрерывном диалоге друг с другом по поводу процессов вокруг фреймворка, провоцируют друг друга на профессиональный рост, стремятся выйти на трансцендентальные решения.
    Поделиться публикацией

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

      0
      Буквально вчера закралась мысль сделать свой фреймворк, есть над чем подумать. Спасибо за отличную статью.
        0
        Пожалуйста, эта статья родилась после бесед с различными дизайнерами-голландцами (я сейчас в командировке у них), есть очень много специфики в оценке работы фронт-энд-разработчиков здесь, все озабочены поиском вдохновения в искусстве, особенно современном, постами вроде: www.smashingmagazine.com/the-death-of-the-blog-post/, все понимают, что затраты на типичные решения должны быть минимизированы, чтобы позволить кодерам и дизайнерам как можно чаще выходить за привычные рамки, их «отжигание» на проектах становится необходимостью
        0
        Все верно пишете. Фрейворк — это именно показатель того, в какую сторону идет команда как команда. Последнее время часто вспоминаю грабли и наработки прошлых лет, и этот подмеченный Вами факт многое объяснил.

        Несмотря на опыт велосипедиста, мне не приходила в голову мысль численной оценки полезности фреймворка, за идею спасибо. Хотя мне ближе оценка «сэкономленного» благодаря фреймворку кода (тут как бы подразумевается, что временнАя оценка по Вашему рецепту — уже хорошая).
          0
          Просто сэкономленный код интересует разработчиков и всех, кто внутри разработки, а бизнес (и всех, кто снаружи) интересуют только монетизируемые параметры, кот. в первую очередь являются сэкономленные человеко-часы, которые должны оправдать инвестированные человеко-часы в разработку фреймворка, эта оценка для убеждения в первую очередь тех, кто снаружи
          0
          Кстати, (имхо) блог Вы выбрали неудачный, тема более глобальна, чем пользовательские интерфейсы и касается не только фронт-енда. Скорее, сюда относится приведенный Вами пример.
            +1
            род мой деятельности завязан на интерэкшн-дизайн, не решился играть на неродном поле, где не знаю подводных течений, пост на самом деле про психологию коллективного творчества и как её «инсталлировать» в команде (дизайнеров-кодеров)
              0
              Я серверный разработчик и мне Ваша статья очень близка :)

              Меня удивляет ее низкий рейтинг, на данный момент проголосовало всего 13 человек, да и дискуссии в комментах не вышло. Есть подозрение, что это результат неправильного выбора блога.
                0
                да, похоже, я промахнулся с блогом (боюсь, что в других слово фронт-энд-фреймворк станет ещё большим раздражителем, чем все психологические штуки здесь), и я опасаюсь начать «учить жизни» там, где сам не работал
            0
            Статья весьма плотно набита информацией и поднимает интересную тему — автору спасибо! Но написана несколько сумбурно — нет четкой постановки задачи и четких путей решения. Я понимаю, что она дискуссионная, но в этом случае структура статьи все же должна быть явно выраженной — тогда будет проще комментировать те или иные выкладки автора.

            А вообще мне кажется сомнительной идеей, что все именно фреймворк является центром вселенной разработки, то есть, получается некий framework-oriented design. Все же фреймворк это внутренний артефакт разработчика, пользователь сталкивается с его внешним проявлением, но не более. Не может фреймворк являться движущей силой проектирования интерфейсов.
              0
              я боялся написать роман и отпугнуть «неосиливаемостью из-за многобуковости», в каждое предложение запакованы 1-2 абзаца рассуждений-разговоров, я расчитывал, что какие-то из них вызовут прямые вопросы, тогда в комментариях я раскрою больше информации; здесь фреймворк — это как сеты ди-джея, каждый разработчик работает над своей «музыкальной» темой, но редко кто слышит, как звучит их материал, когда всё сводится в единую композицию, тут мысль в том, чтобы разобраться с «попсовой» частью и начать ориентироваться в своих сочинениях на общую созвучность; спасибо за критику, никак не могу найти формат поста, чтобы и всё расскрыть, и не быть косноязычным и ясности было больше, чем запакованности; опять-таки пост называется приближение, т.е. мысли в направлении того, чем может быть фреймворк
                0
                Жду хорошей статьи с разархивированными смыслами :), а также с разбитием на главы, а если еще будут и иллюстрации в виде интерфейсов, то цены ей не будет.
                  0
                  ок, найти бы толковую книжку по стилистике русского языка, что-нибудь для журналистов, пишущих для технических изданий
                    0
                    Кто-то уже спрашивал об этом в Хабре. Попробую сформулировать собственный подход:

                    1. Определиться с целями статьи. Их не должно быть много — от одной до трех, максимум. Цели вам помогут выкинуть лишнее и добавить недостающее.

                    2. Сделать скелет статьи в виде заголовков неких смысловых блоков. Каждый следующий блок должен плавно вытекать из следующего (логически связан). При этом автор идет от общего к частному (в текущей версии статьи общее и частное тщательно перемешано, как в блендере).

                    3. Желательно использовать трехчастную структуру повествования — вступление, завязка и катарсис (разрешение).
                    — Во вступлении мы вводим читателя в контекст статьи и сообщаем нечто достаточно понятное сразу. Если автор применяет некую специальную или неустоявшуюся терминологию, желательно дать краткие определения.
                    — В завязке мы ставим проблему (проблемы) — заинтересовываем читателя, чем больше читатель знаком с проблемой тем больше шансов, что он будет читать дальше.
                    — В катарсисе мы показываем как эти проблемы разрешаются.

                    Желательно в самом конце сделать краткие выводы из статьи. Эти же выводы можно поставить, наоборот в самом начале статьи, чтобы читатель мог понять — интересна ему вся статья или нет? Еще этот блок поможет блоггерам, которые смогут выводы быстро поставить его в качестве цитаты внутри своих сообщений по поводу вашей статьи. То есть в этом случае повышается шанс, что обсуждение вашей статьи разойдется по сети.
                      0
                      спасибо
                        0
                        Забыл еще добавить.

                        1. После того, как определены заголовки, надо внутри каждого раздела накидать сырых тезисов.

                        Предварительную работу я обычно делаю в MindManager — очень легко кидать туда тезисы, а потом их структурировать, перекидывая от одного раздела к другому.
                      0
                      Еще один подход от НЛП-практиков. Как простейший вариант — проходитесь по каждому пункту в этом же порядке, но можно и поменять местами. В результате получится подать тему достаточно широко.
                      Итак:
                      1. Определяете проблему — то, что побудило Вас написать статью
                      2. Можно копнуть вглубь и подумать над причинами данной проблемы, но не всегда обязательно.
                      3. Определяете результат, которого хотите достигнуть
                      4. Описываете Ваше решение — то, что превращает проблему в результат.
                      5. Обязательно рассмотреть, какие дополнительные эффекты возникнут благодаря такому решению. Они могут быть как положительными, так и отрицательными.

                      Фактически это модель SCORE, при помощи которой удобно систематизировать информацию. Никто не мешает использовать ее не для сбора информации, а для ее подачи :) Если интересно, копните гугл за примерами, ну или в личку.
                        0
                        спасибо, погуглю

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

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