Стандартизация web разработки

Так сложилось, что я последний год занимаюсь стандартизацией разработки. Я хочу обобщить свой опыт и наработки данным постом.

Бардачок
Вы все знаете наш цикл производства: продажа, тз, дизайн, верстка, интеграция, контент и переезд на сервер. Чуть позже появляются доработки, которые показываю где мы ошиблись




У меня почему-то  таинство проектирования информационной архитектуры всегда было на этапе интеграции. Менеджеры всегда писали "смешное" ТЗ. Дизайнеры проектировали свои "типо"-графику и юзабилити. Верстальщики ваяли оторванный от жизни js. А контент от Заказчика, на момент внесения, взрывал все проектирование . Если пускали Заказчика  самостоятельно вносить информацию, то тег font с завидной периодичностью показывал всем нам какую типографику на самом деле ждал клиент...



Есть и хорошие примеры. Когда Заказчик подгоняет тз и дизайн под свой контент, все получается довольно четко и быстро, а вот если "льстит" себе, мы получаем бардак.

Я искренне уверен в двух правилах:

1. Заказчик в итоге получит сайт соответствующий его внутренним бизнес процессам.
2. Сайт не создает бизнес процессы под себя.
   

Где же тестирование?
Про тестирование ничего не сказал. Смотрите.

• ТЗ описывает пожелания Заказчика. Худо бедно из него можно понять суть проекта. Менеджеры уже научились "фейсбуки" не внедрять.
• Дизайн тестирует (принимает) Заказчик. Я считаю, таким образом он пытается удостоверится в том, что его пожелания через ТЗ полностью поняты и будут учтены при интеграции сайта.
• Верстку зачем тестировать? Конечно, юниоры могут накосячить с ie8, но это прогнозируемо. Обязанность верстальщика сделать свою работу качественно (кроссбраузерно и с нужной фиксированной шириной ). Но загрузку больших изображений, скорость и оптимальность js и т.п. вещей по сути не проверишь, дорого.
• Тестировать интеграцию? Настройки инфоблоков, индексация, эрмитаж, ЧПУ, seo и т.п.? Опять долго и дорого.
• Проверим внесение контента? Alt у всех картинок. Корректные телефоны и email. Не пожатые картинки, внутренняя перелинковка, ссылки на соц сети. Один email, на который идут уведомления съедает кучу нервов, да и никто уже не помнит какие формы на сайте есть
  

Вывод сам собой напрашивается: Все и всегда тестируем.

Или вводим стандарты
Давайте на BitrixFW посмотрим. Программист знает, что CIBlockElement::GetList сделает выборку из инфоблока. Менеджер (по идее) знает, что подписку на рассылку нужно делать через модуль "Рассылка" и данный модуль включен не во все редакции. Пару верстальщиков знает, что jquery 1.8 включен в ядро Битрикса и что теперь идет сжатие js и css. Все контент менеджеры умеют визивиком пользоваться. Дизайнеры... им знание БУС ничего не дает в чистом виде.

То есть сам БУС каким то волшебным образом задает “туннель” для процесса разработки. Он стандартен и огромен.

Однако сам процесс разработки сайта не подвержен четкой стандартизации. Можно настраивать формы редактирования инфоблоков, а можно и обойтись без этого. Можно сделать список адресов через инфоблок, а можно включаемым файлом. Можно запрограммировать js добавления в корзину товара, а потом переписать на стандартный из типовой поставки. Вариантов тьма. И людей много. Бардак обеспечен

Я предлагаю вам следующее решение.
 
Стандартизируйте три вещи:

1. Культуру работы.
2. Верстку.
3. Типовой функционал.
   

1. Культура работы
Описываем производственную цепочку.


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

Это все можно взять из бережливого производства. Крайне рекомендую

2. Верстка
Этот пункт задевает дизайн, верстку и контент.

Опишите правила дизайна:

• сетка
• вертикальный ритм
• использование шрифтов
• перечень иконок, кнопок и т.п.
• стандартные блоки на странице (поиск, логотип и т.д.)
  

Опишите правила верстки  (набор тегов и названия классов):

• список элементов (новости на главной, результаты поиска, список товаров, слайды и т.п.)
• элемент (новость, товар)
• навигация (верхнее меню, левое меню, хлебные крошки)
• форма (поля, валидация и т.п.)
• всплывающие окна
  

Это даст четкие параметры для верстки и интеграции. Используя их, можно через less (sass , БЭМ и т.п.) сверстать любой дизайн и быстро внедрить его.

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


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

Ложка дёгтя
Все это счастье нужно документировать:

• параметры передаваемые между этапами
• списки файлов и их структуру
• стандартное поведение элементов сайта
• правила внесения контента
• правила обучения клиента
• обучение новых сотрудников
• и самое важное: регламент обновления всей системы и стандартов в частности
  

Эпилог
Практика показала, что все это сделать реально.

Сложнее всего с культурой работы (у меня еще не получилось) и с документацией (пишу).

Пробую использовать mindmeister.com и документацию в админке.


Верстку я стандартизировал. Взял за основу исходники bootstrap (они в less формате), дописал вертикальный ритм, стандартные блоки, сделал поправку на админку Битрикса. Получилось удобно (shef.wizonepagedrapes).

Типовой функционал спроектировал через модуль (shef.base). Есть класс для создания инфоблоков. Я просто говорю, ему как инфоблок назвать и какие поля хочу, например видео множественное и дополнительные файлы и в итоге получаю инфоблок с этими полями. Причем инфоблок визуально настроен, даны доступы контент редактору, поля имеют стандартные символьные коды а компоненты их ждут

На этом все. Надеюсь вам было интересно и что-то новое вы почерпнули для своих процессов

Буду рад вашим комментариям!