6. Что мы получили
• Снижение количества коллизий
• Сокращение сроков разработки
• Уменьшение времени простоев
• Масштабируемость
• Увеличение точности оценок
7. А как это все реализовать?
И причем тут bem, node.js и python
8. Презентационная логика в Django
mytardis.readthedocs.org/en/latest/architecture.html
Для верстки «по живым
данным» необходима
работоспособность
всего стека
компонентов Django
9. — Общая логика обработки запроса
Middleware
— Представление ресурсов
URL Mapper, View
— Предметная область
Model, Business Logic
— Готовые решения Auth, Migrations,
Logger, Cache, Geodata, …
Специализация Django
10. БЭМ — верстка, которую легко
поддерживать и развивать
• Методология http://ru.bem.info/
• Node.JS https://github.com/joyent/node/wiki/
Installing-Node.js-via-package-manager
• БЭМ https://github.com/bem/project-stub
11. БЭМ
— Единая предметная область:
Блок, Элемент, Модификатор
— Библиотеки bem-bl, bem-controls, ...
— Шаблонизатор на JavaScript bemhtml
— Сервер для разработки bem server
— Сборщик ресурсов borschik
— Менеджер зависимостей bem make
— Возможности для кастомизации node.js
19. Что из это вышло
• Параллельность и асинхронность
• Сроки
• Качество
• Масштабируемость
20. Алексей Спиридонов spiridon@jetstyle.ru
Евгений Генералов lucky@jetstyle.ru
JetStyle http://jetstyle.ru
http://github.com/jetstyle/
ppa:jetstyle/pyv8
Вопросы...
— Кто делает так же?
— Как сделать ещё лучше?
— Как вы боретесь со сложностью?
Editor's Notes
Всем привет! Меня зовут Алексей Спиридонов со мной будет рассказывать Евгений Генералов. Давайте перед тем как рассказывать свой доклад поинтересуемся: 1) Кто знает что такое BEM? Кто сталкивался с ним? 2) Кто занимается разработкой на PHP? Кто на питоне? Кто на руби? Кто на с++ - шарпах и прочей? Кто не из всего вы перечисленных? А чем? кто уже когда нибудь сталкивался со связкой BEM
У нас в JetStyle есть отделы дизайнеров, верстальщиков, программистов и тестировщиков. В нашем докладе мы хотим расссмотреть этапы верстки и программирования и их взаимодействие. И как в большинстве компаний процесс разработки выглядит следующим образом: Каждая задача идет каскадным методом (по так называемому класическому "Водопаду") от постановки до тестирования: После постановки и проектирования за нее брался дизайнер и рисовал что-то. После этого, это что-то брал верстальщик и преврашал его в HTML. Псоле всего над получившимся макетом дрожал программист и обвещивал все это дело яваскриптом, разбивал это все на шаблоны в своем шаблонизаторе и получал готовый продукт на выходе. После чего менеджер и тестировщик проверял правильность выполнения задачи. Но это все в идеальном мире. На деле же происходит следующее:
ВОт такой вот ежик. Дизайнер не то или не все наривсовал, верстальщик что-то сделал не так или все так но совершенно не согласуется с виденьем программиста. ПРограммист не так натянул верстку или при такой верстке яваскрипт работает медленно и еще какие то. В итоге разбитый результат правится несколькими льюдьми и получается ад и ненависть. Когда Общее время разработки растет, затягиваются сроки, все недовольны ибо плохая предсказуемость.
Пока технологии были относительно просты и программирование фронт енда занимало маленькую часть от общего программирования приложения, мы как-то мирились с этим. Но постепенно технологии расли, появлялась фронтендная магия и становилось сложнее "разворачивать" задачу обратно верстальщику. У нас появляется куча всего нового: 1) Сложный аякс 2) Хранение данных на клиенты 3) Сокеты 4) МВЦ 5) Динамические сложные системы 6) Сложность верстки росла и приближалась (в некоторых проектах) по времени к бекендовой разработке. В общем львиная часть логики переносится на яваскрипт Граница ответсвенности становится зыбкой и непонятной, вертальщик говорит что это должен делать программист, программист говорит что это удобнее делать верстальщику и тд. В итоге после всех этих припитий кто-то делает и.... все ломает, потому что другой тоже решил это сделать.. в общем бардак и суматоха. А еще может сложиться так, что кто-то кого то ждет и все сроки идут в... Стоит так же упоминуть про масштабируемость, в настоящее время можно легко выделить несколько видов приложений, браузерное, тачевое, мобильное. И данные то одни и логика то одна но встараивать они должны все разными видами и по разному. Зачастую для каждого из типов приходиться делать большой кусок работы на бекенде. Это большая работа, случается много опять же проблем с оценкой и прочее прочее... После прихода понимая что так дальше жить нельзя мы решили все поменять. Об этом и об средствах для этого собственно наш сегодняшний доклад.
Для начала мы решили что верстака от программиста надо обособить друг от друга. Сделать их разработку независимой друг от друга.
После данного изменения в процессе мы получили: 1) Мы избавил от вредных пересечений зон отвественности разработчиков, раньше было так называемое сложение ответственности и "перекидывание задач" (когда верстальщик утверждает ) 2) Сроки, изза более раннего начала этапа программирования, проекты стали выполняться быстрее по времени, 3) Изза того что мы распралелили и изолировали версту и программинг теперь никто никого не ждал, а следовательно и простоев на осталось 4) Масштабируемость, теперь у нас одна логика для всех приложений и каждому приложению только одна своя шкурка 5) Оценка - изза независимости разработки, в оценку вкладывается меньше факторов которые влияют на ее оценку, а следовательно она стала точнее //ВО первых, данный метод прост в управлении, от постановщиков и главное от менеджеров не требуется специальных знаний или инструментов. Временные и людские затраты //относительно малы. //Во вторых, из за четкости постановки задачи и понятного конечного результата оценка, пусть даже с небольшим огрехом, достаточно верна (при отсутвии форс-мажоров и хорошем //менеджменте) //После каждого этапа идет вполне обособленный результат. Данный пункт можно частично отнести к минусам, потому изза обособленности результата, имеено после выполнения //задачи мы можем //Во первых это Масштабируемость - при вмешательстве в разработку по причинам внутренним (на предыдущем этапе что-то не доделали) и внешних (заказчик передумал и надо //все поменять). Это очень накладно, вообще у нас получается так, что чем раньше мы внесли изменения (баг это или новая функциональность) тем дешевле она на выходит. //Коллизии -, мы считаем что, если какую то задачу могут сделать 2 типа разработчиков это плохо! Это выливается в "перекидывание задачи" или в выполнении задачи менее //квалифицированным специалистом. //На сроки при таком подходе очень сильно влияют различные внешние и внутренние факторы, изменения верстки, разрезка макетов, плохое настроение заказчика и прочее... Иногда //может доходить до простоев в производстве
Для того, чтобы внедрение данных подходов в процесс разработки стало возможным на практике, нам нужны эффективные инструменты. Кто использует python и django и считает что они классные?
Использование шаблонизато
БЭМ (аббревиатура от слов Блок-Элемент-Модификатор) про "острова" Мы более трех лет делаем сайты для Яндекс с использованием методологии БЭМ и наши скиллы проверены на практике. Для разработчика Упрощение разработки и поддержки Простота переключения между проектами Ускорение разработки при повторном использовании кода Рост проекта не ухудшает качество кода Для командной работы Быстрое подключение человека к команде Совместная работа с кодом разных специалистов Независимая работа над частями проекта Использование чужого кода без погружения в детали реализации
Примерная схема работы всего такогва, !ОБЪЯСНИТЬ ЧТО ТАК А ЧТО НЕ ТАК!
Примерная схема работы всего такогва, !ОБЪЯСНИТЬ ЧТО ТАК А ЧТО НЕ ТАК!
Примерная схема работы всего такогва, !ОБЪЯСНИТЬ ЧТО ТАК А ЧТО НЕ ТАК!
Мы помогали развивать pybem и решили ряд функциональных проблем.
Что нам дало такое разделение: 1) Изоляция, теперь верстальщик и программист полностью дистанцированны друг от друга, у них разный однозначно определнный круг задач !!НАДО ЕЩЕ!!! 2) Сроки, стали немного более пресказуемыми, дизайн перестал влиять на программиста, верстак начал делать javascript и css с html для себя, что тоже немного ускорило разработку. Ошибки стали более дешевые и быстро исправляемые. 3) Внесение измений стало более быстрым и пресказумым с меньшим кол-вом ошибок. 4) Рост проекта в ширь (создание нескольких разных версий) или в глубь (увеличение функционала, увеличение команды и прочее) стало сильно менее проблематичным.
На данный момент JetStyle это 15 разработчиков (7 программистов, 8 верстальщиков), с полсотни проектов в активной доработке и поддержки, а еще с полдестяка новых проектов, часть которых наверняка добавится к проектам в доработке и поддержки. /// На этом сайте хочется показать Преимущества JetStyle // Мы используем крутые трендовые штуки и технологии от крутых разработчиков // для реализации крутых проектов крутым клиентам // и есть место для эксперимента, что позволяет придумывать новые комбинации для принесения максимальной пользы. Визуально список технологий БЕМ Django Node.js HTML5/CSS3 Компании Microsoft Yandex SAP