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

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

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

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

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



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



А у кодера при этом сложится понимание, как создать решение вроде <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 и может помочь вам трансформировать содержание труда разработчиков из скоростной выдачи своей порции на общий конвейер в акт совместного творчества в духе дадаистов или художников поп-арта. Идеальный эффект: когда все участники команды подсознательно находятся как-бы в непрерывном диалоге друг с другом по поводу процессов вокруг фреймворка, провоцируют друг друга на профессиональный рост, стремятся выйти на трансцендентальные решения.