Меня зовут Харитонов Роберт, я работаю ведущим верстачиком
однокласснике РУ, больше занимаюсь сейчас не версткой,
чтобы таких больших недоумений не было, больше занимаюсь
процессами, организацией команды, работой с дизайнерами,
ну и тем, собственно, о чем я буду сегодня рассказывать.
Давайте поговорим о боли.
Боль бывает разная, бывает боль в общем человеческом
понятии, всем весь больно будет стрелять себя в ногу,
зачастую девелоперы это делают, потом очень сильно
жалеют.
Боль бывает девелоперская, всем тоже знакомим этот
символ, много воспоминаний с ним, тут логотип немного
новый, но тем не менее, как Антон показывал, тоже
печали и боли хватает в нем тоже, и боль бывает вот
такая, такая прям, когда кровь из глаз готова
посечь, и очень больно, зачастую бывает такая боль
с молодыми дизайнерами, молодыми не по возрасту,
а молодыми в профессиональном плане.
Давайте поговорим на конкретных примерах, что болит у фронтент
разработчиков, как-то спрашивал в твиттере самое основное
боль, самая основная проблема фронтент разработчиков,
бэкэнт разработчики не шутили, что это сам фронтент,
в какой-то степени может быть и да, но были и другие
перечисления, что-то постарался показать на первых слайдах
во вступлении.
Большая боль – это рутина, когда вы верстаете несколько
проектов или делаете один большой проект, часто приходится
отпереверствовать одно и то же самое, те же самые
конструкции, те же формы, кнопки, все верстается зачастую
заново, просто потому, что не было возможности задокументировать
или просто было лень что-то разработать, сложить в одно
место, чтобы потом просто отодобрать и базировать.
Есть первоначальное начинание в виде HTML5 болерплейт, но
это только совсем маленькая часть, нужно больше избавляться
от рутины и больше складывать себе снебетов.
Еще одна проблема – это бэкэнт разработчики, все явно
встречались с такой ситуацией, когда программист, который
не знает, клиент сайт приходит и говорит, я тут немного
поправил и потом такое видно в коде, хочется за голову
ухвататься, большие очень каскады, импортанты, трудно
поддерживаем код, ваш красивый код испорчен, все
нужно рефакторить, очень неприятно, очень больно.
Как я говорил, дизайнерами тоже бывают частенькие
проблемы, зачастую это связано с тем, что происходит вечный
дизайн, постоянно что-то меняется, постоянно появляется
какие-то нововведения, что-то нужно переделывать, все
встречались с ситуацией, когда приходил дизайнер,
смотрел вашу готовую верстку и жаловался на какие-нибудь
не очень неправильные градиентики, жаловался, как так это
выглядит не так же, как у меня в фотошопе, конечно
друг не так, как в фотошопе, мы все-таки в браузере
зарабатываем, пользователи не в фотошопе, наши сайты
смотрят.
И есть большие проблемы в команде, в процессах, взаимодействии
между людьми, нужно придерживать с кого-то единого стиля,
нужно общаться, коммуницировать, нужно вместе делать
единый продукт, хороший продукт.
Что делать, как решать эту проблему?
Есть огромное множество сервисов, я перечислил далеко
не все, которые так или иначе могут помочь избавиться
от этой боли, к сожалению, эти сервисы являются не
специализированными, они не те самые таблетки, которые
целенаправлены и точечные решают конкретно перечисленные
проблемы, та же почта придумана не для бак-репортов или
не для обсуждения дизайна, а просто для общения, для
деловой переписки, просто мы взяли ее и начали использовать
так.
Мы пробовали много сервисов, пробовали еще куча других
сервисов, сайтов, подходов, которые не перечислены на
этом слайде и пришли к тому, что нужно писать что-то
свое, нужно писать единый специализированный инструмент.
И мы написали движок, который называли Source, что это такое?
Но главная цель движка Source — это обеспечить хороший
инструмент для создания документаций, плюс сделать
удобную слою для разработки интерфейсов и для взаимодействия
в команде.
Собственно, этот слайд является и содержанием всей
презентации, мы пройдемся пока же из проблем и обсудим
это все детальней.
Сразу укажу, что движок уже Open Source, и я не просто
так буду рассказывать о каком-то закрытом, проприетарном
инструменте, то есть уже можно приходить, уже можно
контрибью здесь пользоваться, общаться, высказывать свое
фи или помогать улучшить инструмент, ссылка на GitHub
в описании будет позже в слайдах.
Начнем с документации.
Очень хорошо, когда документация налажена, когда все разложено
по полочкам, когда в ней легко ориентироваться, информация
становится все больше, нужно ее как-то уметь быстро
воспринимать.
Нужно не все сейчас запоминать, а нужно уметь быстро ориентировать.
Это главное качество современного, как человека, так и разработчика.
Для кого нужна документация, для кого она может решить
проблемы, может решить туболь перечисленную на вступлении.
Первым делом документация нужна для берстальчиков,
для фронтендеров, которые разрабатывают фронтенд.
Также документация очень полезна будет и для команды,
и для продукта, что это значит, сейчас мы узнаем.
Чтобы не быть голословным, поговорим о масштабе.
Сейчас в нашей команде около 5 берстальчиков, 10 дизайнеров,
это дизайнеры, которые непосредственно делают интерфейсы, не дизайнеры,
рисующие рекламу, рисующие промо-проекты, а именно те
люди, с которыми мы работаем каждый день, и взаимодействуем,
с которыми нам нужно считаться, с которыми нам нужно уметь
хорошо работать.
Также у нас много разработчиков, около 50, которые работают
над вебом, это в основном бэкэнт разработчики, пишущие
код на джаве, так как наш проект написан в основном
на джаве, и большинство интерфейсов имплемитируется
на джаве, нам тоже с ними нужно очень тесно сотрудничать.
Чтобы иметь представление, с какими объемами верстки
нам приходится работать, я перечислил количество
модулей, которые у нас используется в двух слоях по нашей
методологии верстки МЦС, если вы не знакомы с ней
и не представляете, что такое модуль по этой методологии,
то, говоря в терминах BEM, можно каждый наш модуль умножить
на 5 и получится примерно количество блоков BEM, то есть
больше узконаправленных блоков.
И все это выливается в огромное множество CSS кода, 650
килобайт CSS после Юи компрессии, то есть после убирания
всех пробелов, убирания комментариев, это много-много
тысяч строк кода, конечно есть и множество старого
кода, но половина, больше половины, это тот код, который
мы разрабатываем постоянно и постоянно поддерживаем.
Значит, какие есть проблемы у верстальщиков?
Самое главное в команде верстки, в команде разработки
интерфейсов, в команде технологов, это иметь возможность
легко и удобно обмениваться кодом, чтобы можно было
работать с чужим кодом легко, чтобы не нужно было переходя
на другой проект, все переписывать, чтобы можно было просто
брать и делать, и очень большая проблема среди верстальщиков
это велосипеды, конечно каждый велосипед хорош по-своему,
просто как велосипед, как опыт, но верстки скорее
не так и велосипеды верстки, наоборот делаю ситуацию
много хуже, это связано с тем, что верстать проще,
наверстать кучу вариантов одной конструкции очень
просто, все это выливается в такой неподдерживаемый
ад, поэтому нужно это как-то решать.
Первое, с чего нужно начать решать эту проблему, это
нужно определиться со стилем написания кода и с методологией,
как можно понимать друг друга, если каждый будет писать
разным почерком в разном виде, есть очень большое
количество опытов интернете, на котором можно сослаться,
можно посмотреть и стайл-гайды Гугла, и стайл-гайды Гидхаба,
но мы не будем об этом, я просто упомяну вот как
самого базового вещь, чего нужно начинать налаживать
процессы и делать в команде жизнь лучше.
Второе, это собирание сниппетов кода и набор общей базы,
на которой будет строиться дальше Верска.
С помощью коллективного разума в команде можно сразу
определить, какие конструкции будут лучшие, какие будут
более гибче и устойчивее в дальнейшем использовании,
и сразу с первой комплиментацией начать делать уже хороший
код, они писать что-то быстро, потом это переписывать,
потом другой версиатчик придет тоже перепишет, этого
быть не должно быть, быть не должно.
И очень важно документировать Верску, как я документировать,
сейчас вам покажу, мы очень сильно документироваем
Верску прямо в CSS, так это выглядит на реальных CSS
файлах, мы описываем не только какие-то конструкции,
какие-то секции, в которых распределены CSS стили, мы
описываем мырышифровку и описываем свойства, которые
выглядят подозрительно, как проверить на сколько
подозрительное свойство в определенном селекторе,
достаточно позвать просто коллегу и спросить, понятно
ли тебе что тут написано, зачем вот нужен там overflow
хайден, зачем пози션 релатив, оба свойства могут местами
быть проблемными и могут вызвать какие-то баги, и чтобы
человек, который будет работать с этим кодом, сразу
мог быстро разобраться в ситуации, очень важно указать,
времени это много не займет, но это очень удачная
инвестиция в будущее, в том числе и для самих себя,
возвращаясь к своему коду, которая может быть с ходу
не очень понятен, в комментарии помогут быстро вникнуть
в то, что вы делали месяц, год назад, и документировать
нужно HTML, если CSS все просто, то с HTML посложнее, так
выглядит страница документации в движке source, можно видеть
что очень много пунктов, это документация по формам,
она была разработана на протяжении двух лет, сейчас
она уже практически не разорабатывается, потому
что все кейсы уже покрыты, и с помощью этих наработок
верстальщик, программист, даже дизайнер в будущем,
сможет как из конструктора собирать просто новые формы,
используя уже все то, что задокументировано единочный,
проработано, что проверено временем, и где по фикшенности
узкие баги, узкие моменты, документации создаются
в простом HTML, плюс шабанизатор, о нем тоже немного позже,
и проблемы, которые он помогает решать, какие проблемы
документации может решить для команды, как видите
это наша команда, это рижский офис, много людей, не думайте
что если вы один разработчик, или если вас двое, трое,
не думайте что вам не страшны эти проблемы, что вы не столкнетесь
с ними, рано или поздно команда явно вырастет, все
хорошие сайты делаются вместе, не по единочке, тем более
что интерфейс становится сложнее, нужно взаимодействовать
обязательно, и если сейчас вы не столкнетесь с этой
проблемой, нужно подумать уже заранее о будущем.
Я упоминал проблему и туболь, когда программисты
лезут в КН программисты, не буду набирать тех программистов,
в КН программисты лезут в клиент сайт-код, лезут туда
где они имеют небольшую компетентность, верстальщики
от этого плачут, дети плачут, всем плохо, нужно как-то
решать.
У нас мы пришли к такому решению как вывод source-кода, благодаря
тому что на каждый пример можно сразу посмотреть исходный
код, как HTML, CSS, GS, есть место, куда можно сослать
программиста, чтобы он посмотрел и сравнил, можно
подумать, что должны все программисты знать, что
такое инспект элемент, чтобы просто открыть его,
посмотреть в дефектовых инструментах сам код как
он выглядит, но к сожалению, далеко не все бакэнт разработчики
знают, как этим пользоваться, плюс есть проблема расхождения
с тем же Firefox, он может и свои свойства подрисовывать,
которых по-настоящему нет в CSS, то есть лучше иметь
отдельный эталон, который будет доступен сразу же,
на него можно сгенерировать ссылку и сразу сослать программиста,
сказать, друг, сравни пожалуйста свой код, который ты имплеметировал
по нашим наработкам, и вот эталон, это просто, это
легко сравнить, чтобы документация не было просто грудой
чего-то, чтобы это не было куча файлов на файловой
системе, просто сложно в каком-то виде, может быть даже
если в структурированном виде, по папочкам разложенное,
нужно уметь, уметь и иметь возможность хорошо и быстро
навигироваться по большому количеству документации,
для этого в движке сделана страница документации, есть
общая страница документации, есть страницы навигации
по определенным разделам, плюс есть поиск, который
позволяет легко и быстро, по ключевым словам, по
названию документации, сразу прийти в то место, куда
нужно, также навигация важна очень тем, что если не
иметь возможность быстро переходить в определенное
место, разработчику будет проще написать свой велосипед
чем взять уже что-то готовое, то есть нужно обогнать
его на таком уровне, чтобы ему было легче и проще
взять готовое, быстро найти это, чем писать свой
велосипед в очередной раз.
Также в команде очень важное общение, коммуникация,
особенно большой команде, критично важна, чем больше
команда тем дольше происходит обсуждение, чем дольше
происходит все взаимодействие, чтобы не плодить все общение,
все баг-репорты, все известия о небольших правках по
скайпам, джирам, любым другим бактрекерам, мы сделали
плагин для комитирования прямо в странице документации,
выглядит это вот так, после оставления комментарии
от дизайнера, менеджера, другого верстальщика, тестировщика
или кого угодно из членов вашей команды, комментарии
останется до рассмотрения от автора, которая разрабатывала
эту документацию.
С помощью этих же самокомитариев можно спокойно делать
какой-то ревью, в будущем мы сделаем, чтобы можно было
комитировать сам source-код и как-то вести о нем обсуждение.
Для чего пригодится документация в отношении к продукту?
Очень важно в продукте иметь консистентность, дизайн
тоже будет одинаковый, как видно на примере, кнопочки
разные, с одной стороны одинаковые, но тоступают
немного другие, все они на велосипеде, это очень
сильно может влиять на мнение конечного пользователя,
может влиять на мнение о вашем продукте, нам такое
не нужно.
Мы хотим, чтобы пользователи любили наш сайт, чтобы понимали
наш интерфейс.
Какие еще проблемы, кроме консистентности есть в
плане продукта?
Очень важно разрабатывать прямо в контексте, нельзя
разрабатывать какие-то сферические конструкции, которые
не совсем применимы к реальной жизни.
Нужно разрабатывать все в спектре, видеть, как еще
будет разрабатываем блок, выглядеть в других вариациях,
в других модификациях и какое решение для этой проблемы
есть, это документирование по проектам и использование
тестовых данных, тестового контента, который будет
вставлен в дальнейшем в эту верстку.
Так выглядит документация по проекту у нас, это реальные
скриншоты с реального проекта, тоже достаточно
много пунктов, можно видеть, что блоки отображены в
разных вариациях, поставлен какой-то контент, похожий
на реальный, то есть, разрабатывая какую-то общую обертку,
мы сразу можем предусмотреть, что у этого обертку попадет
и сразу посмотреть, нужно ли будет как-то рефакторить
эту обертку, прямо в одном месте, имея единый скоб
и единое окно для просмотра всего того, что вы разрабатываете.
И упоминал я тестовые данные, пока у нас довольно мало
инструментов для автоматической постановки именно живых
тестовых данных, пока мы просто поставляем вручную
или с помощью небольших снепетов, которые поставляют
разные имена пользователей, разные статусы, разные текста,
с помощью этого мы можем сразу проверить на контенту
устойчивости определенной места верстки, в чек-листе,
в нашем чек-листе это на очень высоком уровне, так
как генерированного пользователя контента очень много и нужно
все время помнить, что пользователь может ставить или куча символов
или куча разного текста, или просто попробовать
преднамеренно что-то сломать в верстке.
С документацией закончили, поговорим о движке, как
о инструменте разработки.
Говоря о процессе разработки, так он выглядит у нас.
Сначала дизайнер рисует картинку, потом передает
фронтент разработчикам и не делает статику, и дальше
происходит имплеметирование живой продукт.
Возможно, у вас этот процесс выглядит немного по-другому,
из дизайна происходит имплеметирование сразу в продукт, на
какой-то тестовой среде очень похожий на продакшн среду,
очень похожий на сам продукт.
Так или иначе, можно вывести обычный процесс, провести
линию, как обычно происходит разработка.
Есть редактор, в котором происходит все написание
кода, далее есть статика, по которой мы смотрим, как
это рисуется в браузере, и есть конечный продукт.
Редакторы развиваются, IDE становится сложнее, интереснее
дают новые возможности, для них пишется куча инструментов,
а статика стоит на месте.
Как была статика 10 лет назад в виде просто HTML файла,
так она, по сути, осталась.
Давайте улучшим это звено, поменяв статику на среду
для разработки.
То есть вчера статика, сегодня новые идеи для разработки
и улучшения от озвена, а завтра, возможно, вы уже
сможете использовать наш инструмент и, возможно,
если будем уже делать для него новые вещи, новые
плагины, которые позволят улучшить не только ваши
процессы, но и наши, и сделать WebDevelopment намного удобнее
и приятнее.
Вы можете спросить, чем отличается среда для разработки
верстки от продакшн среды, от той среды по процессу,
когда идет дизайн, и сразу внедрение.
Самое основное преимущество это гибкость.
В отдельном инструменте мы можем внедрять любые
плагины, мы можем делать все, что захотим, можем
имитировать любые ситуации и иметь полный доступ к
тому, что мы делаем, в отличие от строгих ограничений
архитектуры уже готовой системы и похожими проблемами.
Сразу можно подмечить проблему, что если помечать один
блок в нескольких модификациях, будет много копипаста.
Как это решить?
Мы решаем это с помощью клиентского шаблонизатора.
Мы используем у нас Master.js именно в документациях,
плюс дополнительные прослойки, как Icon.js, plugin и пару наших
функций, которые позволяют легко вызывать определенные
ранние шаблоны с помощью классов insert, tere и id-шаблона.
Это шаблонизатор мы используем только в середине документации,
не используем на продакшене, но лучше всего используемся
один и тот же самый шаблонизатор и там и там.
Есть идеи попробовать скрестить наш инструмент с наработками
ребята ZYANDEX-SBM, и использовать шаблонизацию и блоки, которые
разрабатываются в бейме, и в документации для разработки,
и потом для использования этих же блоков на продакшене.
Довольно много работы мы провели над специальным
инструментом, позволяющим автоматически тестировать
верстку по чек-листу.
Большинство из вас явно знакомы со статьей на Хабриот
Игоря Зенеча, который составил огромный список хороших
практик верстки.
Все пункты очень правильные, очень важны, но просматривать
каждый раз этот список и сравнивать его с той версткой,
которую вы делаете каждый день, очень сложно и долго.
Нужно это как-то автоматизировать.
С помощью плагина и с помощью дополнительных инструментов
можем легко автоматизировать эти процессы и сразу получать
какой-то фидбек.
Также вместе с идеями по этому инструменту есть
мысли начать делать какое-то прототипирование на основе
уже готовых блоков, используя интерфейс графический прямо
в браузере.
Так выглядит дебак режим.
По умолчанию окошко спрятано, кликом на верхнюю левую
часть экрана мы можем вызвать по типу инспект элемента
и указать какие-то фильтры, проверки, которые мы хотим
получить.
После того, как указав, что мы хотим проверить, дебак
режим нам подсказывает, где есть проблемы места
и где их нужно решить.
Помимо подсказки на странице последних этих элементов
можно увидеть просто общее количество проблем в
документации.
Также для удобного тестирования, подставляя какой-то новый
контент, реализована такая функциональность, позволяющая
быстро включить режим редактирования на определенной секции
с примером кода и вставить какой-то контент.
Используется это с помощью контента DIT-ABLE атрибута
из HTML5, что позволяет, просто включив этот режим,
кликнув на любой текст, вести что-то больше, попробовать
подставлять более длинные фразы, подставлять странные
символы и посмотреть, как верстка это все выдержит.
Обсуждали уже тестирование.
К сожалению, пока у нас не так много инструментов, чтобы
хорошо производить тестирование, но мы очень активно об этом
думаем, и на это есть очень большие планы.
Какие есть возможности с тестированием прямо в теле
документаций?
Во-первых, можно делать скриншоты и сравнивать их
в дальнейшем автоматически по эталону.
Что это значит?
Используя тот же Funtime.js, Casper.js, библиотеки, которые
работают на ноде, можно автоматически делать скриншоты
определенных частей страницы, может делать их по ревизиям
и после какого-то рефакторинга, после каких-то изменений
верстки, просто автоматически запустив скрипт, видеть
где появились проблемные места, где что-то поехало,
на что нужно обратить внимание.
Поговорим о дизайнерах, о неотъемливой части команды
разработки интерфейсов.
Самое главное — это понять, что дизайн и верстка — это
одно целое.
Эти сущности нельзя разделять, и разделяя их мы только
копаемся яму и стреляем себе в ногу, как вы видели
на первом слайде моей презентации.
Мне должно существовать дизайна и в картинке, и
в Сверсона-Виде.
Недавно в них пор наши дизайнеры имели отдельно свой
столгайт, где они были собраны дартные элементы, на
которые они ссылались, делая новую интерфейсу.
И у нас была своя реализация того же столгайда только
в Сверсона-Виде.
Две сущности имеют практически то же самое, но расхождения
периодически появляются, связанные с тем, что они развивая
свой столгайт, а мы ждем, пока они дадут отмашку,
можете делать, можете обновлять.
Мы решили объединить эти две сущности, и сделалось
так, чтобы дизайнеры ссылались уже на готовый столгайт
в Сверсона-Виде и чтобы сразу видели, как это выглядит
в браузере в реальных условиях.
Немного котиков, как еще можно общаться с дизайнерами,
нужно как-то их подкармливать, нужно давать им что-то
доброе, полезное мило, чтобы они шли больше на взаимодействие
и чтобы они больше шли к нам на уступке.
Для этого мы сделали интерактивную документацию.
Что это значит?
Есть интерактивная документация по стилям, она тоже доступна
уже на гитхабе и можете щупать, пользоваться, устанавливать,
что дает интерактивная документация по стилям, какие возможности.
С помощью специализированного инструмента мы можем составлять
документации не просто в виде какого-то текста или
в виде статичной картинки, кто как делает.
Наши дизайнеры до сих пор вставляли картинки вики среду.
Очень неюязабельно, очень мало возможности работать
с таким видом документацией, поэтому мы сделали интерактивные
спеки и что они умеют.
Во-первых, можно свободно фильтрировать определенные
секции, можно сразу видеть, как все выглядит в браузере,
если есть задокументированное состояние разных ссылок,
размеров текстов, можно посмотреть, как ссылки выглядят
на ховрере, какие свойства к ним применяются и одним
кликом получить нужный цвет кода или вести СС.
И вторая интерактивная документация, если со стилями
довольно все просто, довольно простая документация,
мало функционала, то с графикой мы можем получить
намного больше возможностей.
Так выглядят наши наработки, в плане интерактивной
документации по графике, в первую этап мы хотим
сделать простую фильтрацию по размерам картинок, простую
навигацию и поиск именно по тем картинкам.
В следующих этапах мы хотим сделать уже возможность
загружать картинки прямо в эту страницу, загружать
туда исходники, получать более детальную информацию
о каждой картинке, сортировку по цветам и еще кучу разных
возможностей.
Какие плюсы еще в интерактивной документациях?
Благодаря тому, что мы эти документации можем положить
в одно место, где лежат все остальные документации
по интерфейсам, мы можем легко наладить взаимодействие
между этими сущностями.
То есть наладить сообщения, обращениями из одной документации
в другую, просто благодаря тому, что все в одной среде
и все прямо на одной файловой системе доступно одним
аякзапросиком.
Также большие возможности в автоматизации процесса
создания эти документации, если говорить на примере
графики, можно натравить скрипт, рисующий эту документацию
на страничку, на папочку со всеми иконками, и документация
сама нарисуется, даже ничего дополнительно не нужно будет
сделать.
Так, давайте подведем итог, мы разобрали, какие проблемы
может решать инструмент, собственно, вот обещанная
ссылка на сайт проекта, там же можно будет найти ссылку
на репозиторию гитхабия, где можно будет почувствовать
реальный код, решили проблемы с документацией, решили
проблемы с взаимодействием с командой, не только решили
с помощью нашего дешка, а также поговорили о возможностях
решения этих проблем в целом, если вам даже не подойдет
этот инструмент, вы вполне после этой презентации можете
прийти на работу, обдумать, переварить полученную информацию
и начать решать те же самые проблемы как-то в своем
ключе, имея вот эту первичную зарожденную мысль.
Поговорим об архитектуре и движка, построена архитектура
на модульной системе, есть модули прямо в ядре, которая
создают основной функционал движка, которая дают разное
апи, и есть плагины, которая легко отделяема движка.
По умолчанию часть плагинов отключена, включается довольно
просто в ключе установить параметр тру в определенной
файле, это все может будет найти в документации, процесс
разработки очень простой.
Что из технологий мы использовали в разработке движки, мы все
фронтендеры, мы любим клиентский код, поэтому основная
часть движка написана на джаоскрипте, естественно
без HTML, CSS не обойтись, из популярных фрейморков
использован был Require.js для реализации той же модульности
и для удобной настройки ее, удобного приключения
плагинов, разработки сторонних плагинов, и мы начали использовать
сравнительный данный jasmine для написания и унитестирования.
Очень важно, когда в команде несколько человек работают
каждым своим модулем, очень важно не сломать модуль
вашего коллегия, не использовать жизнь другому, с помощью
тестов, перед тем как что-то закоммитить, мы можем спокойно
зайти на страничку с тестами, посмотреть что все зелененькое
все окей, и закоммититься без лишних страхов.
Что будет в будущем?
Некоторые части плагинов написаны сейчас на PHP, просто
потому что изначально это было легко сделать, нам нужно было
любое решение прямо сейчас, когда мы еще не думали о
OpenSource, что делают PHP в этих плагинах, он просто генерирует
json, соответственно, в любом момент мы можем заменить,
что мы собираемся делать, заменив часть функционал
генерации json, необходимая для работы движка на Node.js.
Я упоминал, какие возможности есть тестирование, и библиотека
Phantom.js для той же ноды очень поможет в будущем реализовать
наши идеи и сделать функционал тестирования тоже очень
удобным, прозрачным и быстрым.
Также очень хочется уже пощупать новый перепроцессор,
CSS-припроцессор Rework, так как CSS оформляющий страницы
документации довольно сложные, связано это с тем, что
на странице документации мы подключаем сразу все
стили проекта, и вам тоже советую на того же самого,
чтобы опять же не разделять сущности, не оплодить
copypast, и чтобы эти стили не конфликтовали, нужно делать
жесткую завязку, нужно где-то делать important, где-то делать
прямые селекторы по родителям, с помощью Rework мы сделаем
этот процесс более прозрачным и более гибким для кастомизации
с вашей стороны, для создания тем, для поддержки существующего
кода.
Поговорим о будущем, что мы хотим реализовать в ближайшее
время, опять же, тоже автотестирование, очень много возможностей
и еще одна огромная тема, это прототипирование прямо
в браузере, сейчас очень популярна тема веристающих
дизайнеров, создание дизайна прямо в браузере, мы хотим
улучшить этот процесс, сделать его более простым для
людей, которые не знают клиент сайт, наши дизайнеры
в основном не знают, как верстать, наверное, только
один человек был знаком с этим и когда-то пробовал,
и чтобы они могли легко создавать какие-то прототипы,
нового функционала, какие-то каркасы, основаясь на тех
блока, которые уже есть в документации, мы сделаем
инструмент, который про саму драгондровану позволит
как-то позиционировать все элементы и отдавать
верстальчику уже интерфейсы и прототипы в том виде, которая
после небольших изменений можно будет прямо внедрять
продакшн и уже использовать для пользователей.
На этом все, большое спасибо за внимание, очень рад
буду, буду очень рад ответить на ваши вопросы, как и сейчас
так и в Твиттере, так же для меня можно достучаться
по почте и любыми удобными способами, я обязательно
отвечу, если не отвечу, вы можете просто напомнить.
Я отходил, поэтому мог пропустить, скажи пожалуйста, а ты уточнял,
чем твоя система документирования лучше, чем существующая
аналогия и почему она вот выбралась делать свою,
они использовали какие-нибудь существующие на работке?
Довсёв очень мало, именно с таким функционалом, есть
аналогик для автоматической генерации документации,
но они имеют довольно маленькую гибкость, то есть
любая автоматизация имеет свои проблемы, связанные
с тем, что тяжело сделать что-то кастомное, тяжело
сделать шаг в сторону, то есть похожего инструмента
мы не нашли просто, а насчёт автоматизации у нас тоже
есть идеи в плане автоматизации некоторых процессов, но
всё автоматизировать мы точно не будем, только
возможно какие-то конкретные спеки, какие-то конкретные
документации.
Спасибо, очень интересный доклад, я бы хотел задать
два вопроса, я так понял то, что вы пишете на чистом
ЦСС, почему не используете САС или лес язык, и как
вы осуществляете кросс-браузерное тестирование авты и ручную.
Спасибо.
Мы пишем, да сейчас пока просто ЦСС, где-то в документациях
мы экспериментировали с разными при процессорами,
которые пока не используются на продакшене, связаны это
с тем, что довольно сложный билд процесс, это просто
отсутствие, на этом сказывается просто отсутствие человека,
который пишет хорошо билды, и просто у нас покажет
у нас этот человек, который мог бы легко интегрировать
любой из при процессоров в нашу систему, мы в этом
активно думаем, у нас нет причин от этого отказываться,
просто так пока сложилось, но будет сто процентов.
Насчёт кросс-браузерного тестирования, в основном
всё тестирование у нас проходит в ручную, тестировщики
смотрят сами, это местами дешевле, чем тестировать
всё с помощью юнитестов, в том плане, что работа
тех же тестировщиков дешевле, чем работа разработчиков,
которые будут писать те же юнитесты и тратить
только же самое время, не столько тратят тестировщики
на ручной просмотр.
Говоря о автоматическом тестировании, там пока не так
всё радужно и автоматически тестировать, получается
только в определённых браузерах, с помощью того же селениума
это обычно Firefox, с помощью Fentom.js это WebKit.
А вот про кросс-браузерный ещё, по поводу Intrain Explorer
и E Collection вы используете, то есть вы используете чистые
реальные браузеры или вот как вот E Collection используете.
То есть один компьютер там, по одной версии каждого
браузера, другой компьютер, может быть виртуалка, что
вы используете?
Мы используем живые браузеры, так как это надёжнее всего,
у нас есть как компьютеры и отдельные, с определёнными
браузерами на старых и на разных операционных
системах.
И есть компьютеры более мощные, в которых установлены
виртуальные машины с разными ежками, ну и все остальные
браузеры.
То есть мы не используем какие-то дополнительные
инструменты на таком production тестировании.
Разработчики могут экспериментировать с разным, с чем
вам удобнее работать, но в конце всё равно это реальные
браузеры.
Здравствуйте, скажите пожалуйста, вот дизайнеры, если они набирают
из готовых элементов дизайн, то получается, что если
им что-то создать нужно новое, то им всё равно придётся
рисовать это в фотошопе и уже передавать на верстке.
Правильно понял?
Конечно.
То есть в чём же случается дизайн, если они набирают
каждый раз абсолютно из одних и тех же блоков, которые
сделал верстальщик из готового дизайна.
Нельзя рисовать постоянно что-то новое, то есть большинстве
случаев и наши дизайнеры и любые дизайнеры больших
проектов используют уже готовую на работке.
И очень полезно было бы в этом плане дать им инструмент,
позволяющим делать прототипирование прямо уже на готовых элементах.
А если делать новые интерфейсы, конечно же их лучше сначала
как-то оттачивать в специализированных инструментах, в те же файерфоксах,
в фотошопах, далее мы уже сами на стороне команды
верстальщиков это имплементируем и тоже внесём в общую базу,
с помощью которой уже потом может будет также прототипировать
как и с более старыми элементами.
Спасибо.
Что у тебя первична, стайл-гайд или дизайн, то есть как происходит
формирование стайл-гайда, сначала пишется стайл-гайд
и по нему дизайнерам, например, и по нему уже происходит
отрисовка элементов или у вас создаётся элемент, так
он добавляется в библиотеку компонентов и на основе библиотеки
компонентов пишется стайл-гайд.
У нас нет такого стайл-гайда, который описывает прямо все
моменты, общие стили определены изначально, то есть сначала
был стайл-гайд, потом уже какие-то наработки, новые
элементы сначала рисуются, обсуждаются в команде дизайнеров,
потом приходят в общие стайл-гайд, в общую документацию.
Иногда наши дизайнеры экспериментируют, делают что-то
полностью с нуля, полностью с другим видением, обычно
это делает другой дизайнер, который раньше не работал
над этим проектом, просто чтобы получить какие-то
новые идеи, то есть делается все с нуля, потом что-то упражняется,
что-то делается под существующие стандарты, под существующие
реалии и вот развитие, документации происходит все время,
то есть какие-то обновления и в старых элементах стайл-гайдов
есть и вот появляются новые какие-то элементы, которые
мы просто добавляем постепенно.
