Меня зовут Павел Гринченко. Я был одним из участников Школы разработки интерфейсов Яндекса в Симферополе. Когда-то давно я посмотрел видеозаписи самой первой Школы 2012 года и почерпнул из них очень много полезной информации. Затем я узнал, что в моём городе пройдёт новая Школа, и решил обязательно поучаствовать.


Чтобы попасть в Школу, требовалось заполнить анкету и сделать два тестовых задания. Одно из них — по вёрстке, довольно простое. Звучало оно так: сверстать список ачивок, но максимально гибко и реюзабельно (например, используя СSS counters). Второе задание оказалось посложнее: написать обфускатор CSS-классов без использования сторонних библиотек. На входе — массив классов, на выходе — их обфусцированная версия. Но вот пара нюансов:


  • Длина результирующих классов должна была получиться минимальной.
  • Наиболее часто встречающиеся классы должны были занимать наименьший объём.

3 июля, сделав задания, я отправил заявку и забыл про Школу, а 26 июля мне пришло письмо о том, что я принят. Сегодня хочу рассказать вам о том, как проходил процесс обучения, какие инструменты разработки я открыл для себя и какие задачи нам приходилось с интересом решать.


Итак, в письме Яндекс описал формат наших занятий. Общая продолжительность — месяц, одно лекционное занятие по средам в вечернее время и одно практическое по субботам в течение всего дня. В конце предполагался экзамен.


Всего участников было 30. Нас поделили на пять команд, предоставив общее ТЗ. Целью было создание проекта под кодовым названием Pepo — простенького клона Твиттера. Его нужно было разработать на веб-технологиях и заставить хорошо работать на мобильных устройствах. По технологиям ограничений не было — каждая команда могла сама выбрать свой стек. Звучит интересно, не правда ли?


Наша команда решила, что, раз мы в Яндексе, было бы глупо не воспользоваться положением и не попробовать поработать с полным стеком БЭМа, тем более когда под рукой всегда есть люди, которые разрабатывают либо на БЭМе, либо сам БЭМ, и у которых всегда можно спросить совета (что не раз выручало). Спасибо за помощь нашим менторам, Владимиру Гриненко tadatuta и Павлу Кучерову!


С технологиями мы определились быстро — Node.js, MongoDB в качестве хранилища и VPS на DigitalOcean, любезно предоставленная Яндексом. Решив не заморачиваться настройкой MongoDB, мы использовали бесплатный тариф на mLab: для наших нужд его было более чем достаточно. Чтобы не начинать разработку с нуля, взяли рекомендованный нам stub, который отличается от официального тем, что уже содержит в себе преднастроенный для работы с БЭМом Express.js. Это оказалось весьма удобно, поскольку никто из нас не имел опыта работы с полным стеком БЭМа (CSS-нотация не в счёт).


Работа в первую субботу получилась очень сумбурной — мы слишком долго раскачивались. Почти весь день мы обсуждали, как должен выглядеть итоговый проект, какие функции нужно реализовать. Вы, наверное, уже поняли, что обсуждения не продвинули нас к цели, а время бесследно улетучилось. Наконец, после обеда мы решили набросать на доске все экраны нашего приложения и обобщить интерфейсные решения в компоненты. Дело в том, что весь БЭМ — как раз про компоненты: независимые и реиспользуемые. Ещё такая схема позволила нам распределить задачи между участниками. Всем рекомендую начинать именно с неё.




Компоненты-то мы распределили, но не было понимания, как всё это реализовывать. БЭМ сам по себе непрост, и с наскоку обучиться ему тоже достаточно сложно. Нам порекомендовали ознакомиться со следующими материалами:



После каждого видео приходило больше понимания, как всё работает и как Яндекс пришёл к такой архитектуре. Она позволяет без особых усилий реиспользовать свои наработки между проектами. Например, у нас всех на проекте есть выпадающее меню. Так почему бы не написать его один раз, чтобы потом просто использовать везде? Вы можете возразить, что это не всегда возможно, поскольку каждый проект имеет свою специфику. И вот тут очень помогают уровни переопределения. Основная логика пишется в библиотечном коде, специфичная — на проектном уровне. В итоге к следующей субботе мы уже могли более-менее активно вести разработку.


Для ускорения разработки мы воспользовались публичной библиотекой блоков bem-components. Так мы сэкономили время на разработку дизайна и базовых блоков, сосредоточившись на бизнес-логике и уникальных для нашего проекта компонентах. Забегая вперёд, скажу, что без bem-components мы бы, скорее всего, не успели. Я это к тому, что, имея похожую библиотеку компонентов у себя в компании, вы существенно упростите себе жизнь. Она не обязательно должна быть написана на БЭМ, а вполне может быть библиотекой Angular-директив или React-компонентов. Важна сама идея компонентной разработки.


В итоге за месяц у нас родился недоработыш, который мы и презентовали на экзамене. Баги правили прямо во время презентации, что было весьма забавно. Самое интересное — после всех защит нам сообщили, что это не конец и через две недели нас ждёт окончательная защита проекта. Эти две недели разрешалось потратить на доработку, причём необязательно в команде: были люди, которые не сошлись с командой во мнениях и защищались со своим форком. Для меня эти две недели получились сумасшедшими. Была проделана огромная работа, и проект удалось довести до состояния, которое соответствует первоначальному ТЗ и которое уже не настолько стыдно показывать. Впрочем, вы можете оценить результат сами: zoopark.top. Внимание: VPS всё еще на DO, а база на mLab, поэтому отказоустойчивость не гарантируется. :) Репозиторий с кодом лежит на GitHub.




Наша Школа была скорее для тех, кто уже имел опыт разработки. Новички бы чувствовали себя совсем некомфортно. Им я рекомендую упомянутые в самом начале и по-прежнему актуальные видео первой Школы. В ШРИ можно смело идти за опытом работы в команде с незнакомыми тебе людьми, чтобы ближе познакомиться с БЭМом (хоть это и не было обязательным условием), а также — чтобы попробовать попасть в Яндекс на работу: в итоге некоторых участников позвали на стажировку. Ну и ещё просто потому, что это весело и интересно.


В мой отчётный день мне задали вопрос — буду ли я использовать БЭМ в своей повседневной разработке? Я, не сильно задумываясь, ответил: «Скорее нет, чем да». Но затем прошло какое-то время, и я, переварив полученный объём информации, понял, что в своём ответе исходил из двухлетнего опыта разработки SPA-приложений. Сейчас моё мнение прозвучало бы немного иначе. Использовать БЭМ для SPA я бы, наверное, по-прежнему не стал, а вот для классических приложений это действительно отличный выбор, позволяющий привнести порядок во фронтендовую часть и упростить разработку и поддержку проекта.


Я могу смело рекомендовать участвовать в подобных мероприятиях всем. Даже если в дальнейшем вы не собираетесь использовать БЭМ в своей работе, вы всё равно получите новые интересные знания и опыт, которые могут быть применены и с другими технологиями. Спасибо Яндексу и всем людям, которые потратили на нас время, за эту Школу!

Поделиться с друзьями
-->

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


  1. fsou11
    17.01.2017 17:24
    +13

    Так и как же обучают в школе и чему вы там научились? Больше похоже на восхваления БЭМа пост.


    1. Aingis
      17.01.2017 18:58
      +1

      В общем-то ШРИ для того и существует, чтобы учить БЭМу (и остальному понемногу) разработчиков, чтобы Яндекс мог нанимать людей. ШРИ — прямой путь новичков к работе в Яндексе (и де факто основной инструмент компании для найма веб-разработчиков), причём с тщательным отбором, ибо конкурс большой, а набирают всего 30 человек.

      Точно так же как новомодные митапы и даже конференции проводят и спонсируют компании, которые говорят: «приходите к?нам работать» и проводят конкурсы: «запишись к нашим HR и получи шанс выиграть дешёвую безделушку».


    1. PSDCoder
      17.01.2017 19:50

      Отправляя заявку в школу, я честно говоря, и ожидал знакомства с полным стеком БЭМа, т.к. для меня технология, в плане самостоятельного изучения, казалась несколько неподступной. И когда нам предложили самим выбирать технологии для проекта, я сильно не раздумывал. Так что не вижу ничего странного в том, что я изучал БЭМ в Яндексе =)


    1. Grimfri
      18.01.2017 01:02
      +1

      Я прошел эту же школу, но был в другой команде. Нас учили как правильно взаимодействовать между собой, как организовывать разработку в распределенной команде (мы работали над приложением не только по субботам), давали советы по планированию и отвечали абсолютно на любые вопросы связанные с разработкой.

      Было очень интересно разрабатывать проект в условиях ограниченого времени, ресурсов и сильной конкуренции. Нам приходилось решать: какой функционал мы не будем реализовывать и чему уделим больше внимания, как выдать что-то готовое к дедлайну, и при этом выглядеть не хуже других команд. Защита проекта, перед незнакомой аудиторией, также оказалась для меня полезным испытанием.

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


      1. fsou11
        18.01.2017 01:13
        +1

        Возможно, про это и стоило написать под таким заголовком, как в статье, дополнив интересными и полезными для разработчиков подробностями. Это ведь разрешено публиковать?


  1. nick_volynkin
    17.01.2017 18:29
    +1

    3 июля, сделав задания, я отправил заявку и забыл про Школу

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


    1. leremin
      17.01.2017 19:00
      +2

      Я хотел на Хабр. Отправил что-то в песочницу и забыл. Через два месяца случайно заметил, что могу «лайки» ставить.


    1. PSDCoder
      17.01.2017 19:50

      Чего уж тут лукавить, первые пару-тройку дней я действительно ожидал увидеть ответ в почтовом ящике. Но затем, в летней суете, как-то и подзабылось…


  1. Danik-ik
    17.01.2017 22:10

    Понастольгировал :). Сам выполнял эти задания. Обфускатор разочаровал лёгкостью условия, а ачивки, наоборот, сами разочаровались моей удалённостью от фронтендового мышления. Я даже отправлял результаты, хотя и знал, что не пройду (неформатный я, слишком взрослый, и не только — это помимо сомнительно выполненной вёрстки).


    Я тогда всеми силами старался вырваться из сантехников обратно в программисты. Удалось, однако, хоть и не попал в Яндекс.


  1. CuteWolf
    18.01.2017 13:21

    Интересно, куда проще попасть: сегмент Яндекса или Мэйла? :)))


  1. damat
    18.01.2017 13:34

    В который раз пытаюсь понять, какое это все имеет отношение к интерфейсам. Учат начинающих фронтов быть более продвинутыми фронтами под стандарты Яндекса. Может быть, есть какой-то тонкий юмор в том, что БЭМ — это такой системный интерфейс Яндекса, которому и учат в школе Яндекса.


    1. vithar
      21.01.2017 11:39
      +1

      А чему по вашему нужно учить разработчиков интерфейсов в Школе Разработки Интерфейсов?


      1. damat
        21.01.2017 11:44

        Вы не поверите, но таки разработке интерфейсов. Не кодингу, а разработке, которая включает в себя как минимум паттерны интерфейсов, гайдлайны, общий процесс разработки от проектирования до тестов и аналитики на реальных пользователях. Иначе это просто курсы повышения квалификации для веб-разработчиков


        1. vithar
          21.01.2017 11:48
          +1

          общий процесс разработки от проектирования до тестов

          Это было.

          аналитики на реальных пользователях

          Вам это часто пригождается в вашей работе разработчиком интерфейсов?

          паттерны интерфейсов, гайдлайны

          Это шире, чем разработка, это проектирование. В ШРИ мы ставим целью научить, как эффективно именно вести разработку, как взаимодействовать в команде.

          То, о чём вы пишете у нас есть в Мобилизации, она была в 2016 летом в Москве и будет в 2017.


          1. damat
            21.01.2017 15:04

            Понял, что ответил не в ту ветку :(


  1. damat
    21.01.2017 12:25
    -1

    Вам это часто пригождается в вашей работе разработчиком интерфейсов?

    Конечно. А как еще?..

    Это шире, чем разработка, это проектирование

    В корне не согласен. Школа — это обучение от и до. Не стоит использовать это слово, если не можете ему соответствовать. Причем в мобильном направлении у вас более понятно разделено: есть школа мобильного дизайна, есть школа мобильной разработки. Зачем было веб фронтэнд именовать «разработкой интерфейсов» — мне честно непонятно.

    Вот описание позиции UI-developer (взято из интернетов):
    A UI Developer is similar to a front-end developer in that she or he uses client-side technologies to build the front end of a website, but differs in that UI developers put more emphasis on a website’s design and aesthetic (typography, iconography, design principles).

    User Experience (UX) and asynchronous JavaScript and XML (AJAX) break the top ten most wanted UI development skills.


    Это шире, чем разработка, это проектирование.

    Ага, именно поэтому приложение из статьи выглядит вот так:

    Главная без title, meta, favicon или хотя бы названия
    image


    1. tadatuta
      23.01.2017 03:24
      +1

      Полагаю, что ваши обманутые ожидания происходят из-за того, что в Яндексе под «разработкой интерфейсов» понимают именно front-end, а UX и «красоту» относят к дизайну.

      Скорее всего причина историческая: в какой-то период времени в компании не было своих дизайнеров (макеты рисовала Студия), но были отдельные люди, которые занимались бекендом, были HTML-верстальщики и те самые разработчики интерфейсов — те, кто превращал сверстанную статику в живой сервис.

      Прошедшая Мобилизация была гораздо шире, там присутствовал дизайн, как отдельная «школа», но ШРИ, как и в Симферополе, затрагивала лишь программирование front-end-а.