Архив недели
Понедельник
Всем привет! Меня зовут Саша, эту неделю мы проведем вместе. Я собираюсь рассказать немножко о себе и немножко о том, как работается в Delivery Club
Я в твиттере впервые, поэтому давайте разбираться как тут что. С редактированием профиля я справился, с первым твитом тоже. Давайте попробуем сделать цепочку твитов
Проверка цепочки. Тест. Раз-два раз-два.
Ага. Кажется получилось. Теперь давайте разберемся с взаимодействием с вами. Накиньте лайков, ретвитов, комментов, всего что только можно
Не стесняйтесь дизлайкать, я за любую форму обратной связи. Можно заминусовать этот твит, например.
Стоп. В твиттере нет дизлайков?!
@mobileunderhood Тоже мне )
А теперь проверяем цитирование. Егор, спасибо за ответ, я потренировался twitter.com/egorka/status/…
Так, тренировка окончена, вроде все ясно. Теперь расскажу о планах на неделю
Недавно прошла оценка 360, получил комментарий, что у меня инженерный подход к решению задач. Вот и к подготовке к этой неделе я подошел системно
Я постараюсь твитить по 3 раза в день. По утрам будем обсуждать процессные вопросы, в середине дня будем погружаться в рутину написания кода, а по вечерам постараюсь накидывать что-нибудь легкое
Темы, которые я хочу обсудить будут тоже в специальном порядке, кто догадается в каком - поставлю лайк (:
Расписание тем на неделю:
Пн: собеседования;
Вт: онбординг;
Ср: архитектура;
Чт: технический долг;
Пт: технический бренд;
Сб и Вс: что-то легкое, чтобы отдохнуть от работы, пока не решил что именно
@mobileunderhood Хм, почему у нашей экосистемы ещё нет общих мобильных митапчиков 🤔
Давай организуем? twitter.com/victoriaqb1/st…
Я немножко поработал и вернулся к вам! Давайте поговорим про собеседования. Сначала кратко о том, как у нас, потом подробнее и порассуждаем
В Delivery Club процесс отбора кандидатов такой:
HR-интервью;
Техническое интервью;
Финальное интервью.
Раньше был еще скрининг между 1 и 2 этапом, но мы от него отказались
Внимание, вопрос. Как считаете, 3 этапа - это много или мало?
Поподробнее про HR-интервью. Оно занимает (не соврать бы) минут 15. Цель - узнать чего хочет кандидат, синкануть это с нашими ожиданиями от кандидата
Нам этом этапе у людей бывает неосознанное (или осознанное) желание не рассказать чего именно хочется, а показать что хочется именно на эту вакансию. По крайней мере у меня такое желание возникает зачастую. Я борюсь с ним
Думаю, что никому не будет лучше от того, что кандидат скажет не то что думает, а то что от него хотят услышать. К тому же это самый первый этап, а значит ты (некий абстрактный «ты» - кандидат на вакансию) не затратил еще сил и энергии и не страшно, если дальше не позовут
Другое дело, если по какой-то причине именно эта вакансия тебе очень-очень интересна. Думаю, тогда стоит это озвучить и назвать пару причин почему. Никого не отпугнет фраза «всю жизнь хотел работать именно у вас». Но при этом на вопросы все же стоит отвечать честно
По итогам интервью HR пишет подробный отчет - все что получилось узнать. Потом тимлид еоманды, куда открыта вакансия принимает решение, приглашать ли кандидата на техническое интервью
Техническое интервью - двухчасовой марафон, подробнее раскажу сегодня вечером. Кстати можно почитать на хабре хорошую статью от уже к сожалению бывшего коллеги m.habr.com/ru/company/mai…
Есть мнение, что техническое собеседование не дает объективное оценки уровня кандидата. Согласен. И тем не менее, очень люблю технические интервью, как проводить, так и проходить. Даже когда не мог пройти ни одного, все равно любил
Для меня это либо ценный опыт, либо обратная связь, либо возможность показать себя, либо узнать что-то новое. Кстати хорошо проходить технические интервью я стал только после того, как начал сам их проводить
В общем реалии такие, что хоть как-то оценить кандидата надо. 2 часа болтовни на общую тему - не самый худший способ. А вот тесты перед техническими интервью я не люблю. Человеческого фактора не хватает
По итогам технического интервью мы, разработчики, составляем подробный отчет с оценками по все темам по такой шкале:
0 - нет знаний;
1 - плохо;
2 - недостаточно;
3 - достаточно;
4 - подробно;
5 - исчерпывающе;
? - не обсудили
Если вы хотите показать исчерпывающие знания - рассказывайте подробно сами, не ждите что вас попросят углубиться в какую-то тему. Если что, интервьюер наоборот остановит и перейдет к следующей теме.
По итогам отчета тимлид принимает решение, звать ли кандидата на финал. Финал - встреча с тимлидом и его руководителем. Длится полчаса, смотрят на софты, culture fit и так далее. По итогам встречи тимлид со своим руководителем принимают решение о том делать ли оффер
Так, мне пора бежать, укладывать сына спать. Ему год и у него есть ритуал перед сном, в котором я каждый день принимаю участие. Я расскажу подробнее про техническое интервью вечером, ждите новый контент!
Продолжу в этом треде. Тема беседы - техническое интервью. Для начала давайте узнаем, что думает публика. Двухчасовое техническое интервью - хорошо это или плохо?
Как я уже говорил, я люблю технические интервью. Для меня это возможность показать себя со всех сторон, произвести впечатление. Но так было не всегда. Еще года 3-4 назад, я ужасно заваливался на таких собесах
Попробую рассказать о том как проходят технические интервью у нас и дать полезные советы тем, кто как и я раньше, справляется с ними со скрипом
Наше ТИ (устал печатать целиком) разбито на несколько секций: Objective-C, Swift, UI, SOLID, архитектура. Где многопоточность, спросите вы? На нее мы обращаем внимание в рамках практической задачи (о ней расскажу позже). Ну и на усмотрение интервьюера, можно поспрашивать и теорию
Итак, Obj-C. Зачем спрашивать это в 2020 году? И правда, мы пишем весь новый код на Swift, 90% времени читаем его. Но Obj-C все-таки встречается. К тому же мы его выпиливаем. Чтобы выпилить кусок на Obj-C, нужно его понять
Мы не спрашиваем теорию по Obj-C. Мы даем практическую задачу. Взять кусок легаси кода, старого, страшного и внести в него продуктовую правку. Убиваем сразу кучу зайцев:
- проверяем как кандидат ведет себя в стрессовой ситуации;
- проверяем как он разбирается в чужом коде;
- оцениваем как он умеет доводить дела до конца;
- попутно обсуждаем Obj-C;
- затрагиваем многопоточку на конкретном примере.
Когда я устраивался в Delivery Club я прошел такое же интервью и секция с задачей на легаси Obj-C код мне очень понравилась. Она раскрыла все мои лучшие стороны. Но не каждому кандидату такой формат заходит, к сожалению.
Помню я собесился в hh и мне дали код прочитать... Я облажался, код был на свифте с дженериками, я тогда только-только щупал свифт, многого не знал. Но мне очень понравился формат. Я попросил ребят скинуть мне тот код, чтобы разобраться. Оказалось - это были исходники Alamofire
Следующая секция - Swift. И тут мы спрашиваем исключительно теорию. Хотя у меня был хороший опыт на старом месте работы давать сниппеты кода, наводящие на теоретическте вопросы. Работало хорошо, кажется, что кандидаты охотнее шли в диалог
Я вообще считаю, что хорошее интервью - это диалог. Ну и разумеется, главное же не то, правильно ли кандидат отвечает на вопросы, а как он мыслит (:
Дальше UI. Даем практические задания на верстку в ксибах, спрашиваем теорию. Тоже зависит от интервьюера, кто-то любит спросить одно, кто-то другое
SOLID - тоже на практике. Мы не просим расшифровывать буквы и давать определения. Даем не самый качественный код и предлагаем внести в него изменения, поревьюить. Моя любимая секция, всем за нее ставлю пятерки
Финалочка - архитектура. Мы не требуем знаний конкретных архитектур и паттернов, интересно насколько кандидат понимает архитектуру на текущем проекте. Либо любую другую архитектуру, которая ему нравится больше.
Рисуем схемы, обсуждаем. После того как схема нарисована - даем практическое задание, реализацию которого нужно «натянуть» на нарисованную схему. Как по мне - тоже очень интересный подход. Когда я проходил собес, мне очень понравилось.
После этого выдыхаем, расслабляемся. Отвечаем на вопросы кандидата и предлагаем ему презентацию с конфы о нашей архитектуре, в качестве визитки проекта.
А теперь перейдем к советам. Сперва для интервьюеров. Мне когда-то сказали, что хороший тон - это начать на «вы» и спросить можно ли перейти на «ты». Теперь стараюсь так делать и вам советую
Банальщина, но не нужно сразу бомбить техническими вопросами, лучше спросить как дела, поговорить о погоде. Что-то нейтральное, чтобы растопить лед. Любое интервью - стресс, давайте его минимизировать
Обязательно нужно заранее озвучить план интервью. Представьте это чувство, когда уже час вас мурыжат какими-то вопросами, вы выжаты как лимон, ответили только на половину. А сколько еще это будет продолжаться? Неизвестно... Нет, кандидата надо предупредить обо всем
Доводите интервью до конца, даже если думаете что кандидат не вывозит. Пусть тренируется. И следите за таймингами. Сказать что время на задачку вышло и перейти к следующей теме - норм. Через 15 минут после начала собеса сказать «я услышал достаточно, до свидания» - не норм
Я люблю рассказывать кандидатам правильный ответ, если в процессе диалога мы до него все же не добрались (если конечно сам знаю (: ) и вам советую так делать
И пара советов интервьюентам. Старайтесь отвечать подробно, развернуто. Самое ужасное - это односложные ответы. Никакой информации не дают. Помните, идеальный собес - это диалог
Не бойтесь спорить с интервьюеров и отстаивать свою точку зрения. Аргументированно, разумеется.
Я кстати люблю в процессе интервью открыть плейграунд, чтобы проверить что-то неочевидное, что обсудили. Бывает обидно, когда при этом общаешься со вторым интервьюером, а кандидат не включается в обсуждение. Это же интересно!
Кстати, знаете какой у меня основной критерий при выборе из кандидатов? Я выбираю того, кто на собесе хоть раз сказал мне перед тем как что-то объяснить: «так, ну, смотри»
Сложно объяснить почему это для меня сигнал. Вообще это интуиция, но мне кажется что люди говорят такие фразы когда хотят объяснить что-то в чем разбираются. Или хотят разобраться.
Ладно, я иссяк, надеюсь было интересно. Завтра поговорим про онбординг. А пока еще пара опросов
Какие вы больше любите вопросы?
Любите ли вы задачи на алгоритмы?
Как относитесь к тому, чтобы писать код на собесе? Не на бумажке, это жесть, но, например, в плейграунде?
Вторник
Доброе утро, уважаемые читатели. Сегодня мы поговорим про онбординг. А если конкретнее, то про все, что происходит с тем, кто прошел все круги отбора и согласился связать свою профессиональную карьеру с нами
Я веду прямой эфир из теплой ванны, расслабляюсь после утренних занятий с сыном и набираюсь сил перед рабочим днем. А вы любите принимать ванну?
Итак, к теме дня! Если вы приняты в Delivery Club на должность iOS разработчика, то вы попадаете в одну из продуктовых кроссфункциональных команд
Ваша команда укомплектована бэкендерами (их у нас много), андроид разработчиком, QA-инженером и тимлидом. За вашей командой закреплены продакт и дизайнер
Ваш непосредственный руководитель - тимлид продуктовой команды. Он решит для вас все необходимые административные вопросы.
Кроме того, вы попадаете в команду iOS разработки. Я специально выбрал именно это слово, а не гильдия или сообщество. iOS разработчики у нас - это одна команда. Мы общаемся ежедневно, у нас очень живой чатик и каждый готов прийти на помощь своему соратнику
Процессом онбординга руководит тимлид. Он должен погрузить вас в процессы, познакомить со всеми коллегами, с кем придется взаимодействовать, ответить на все вопросы. Но тимлид - не айосер, как быть?
Для того чтобы помочь вникнуть в специфику нашего проекта, познакомить с архитектурой, принятыми решениями и объяснить как мы делаем PRы, вам выделят Buddy. Это iOS разработчик, который будет вам помогать
Разумеется, большинство информации вы найдете в Confluence, но общаться с живым человеком всегда приятно.
Итак, курьер привез вам ноутбук, вы подписали документы, админы выдали необходимые доступы, пора приступать к работе. У нас скрам, 2-недельные спринты. Вот типичный календарь iOS разработчика в Delivery Club:
- стендап с продуктовой командой (ежедневно)
- стендап с iOS командой (ежедневно, понедельник и пятница - по желанию)
- встречи по проработке эпиков на следующий спринт (со среды по пятницу, перед спринтом, сколько необходимо)
- планирование (понедельник, первый день спринта)
...
...
- груминг (первая пятница спринта)
- демо (второй четверг спринта)
- ретроспектива (вторая пятница спринта)
У нас релизный поезд. Обновления в мобилках уезжают раз в неделю. В среду отводим релизную веточку, проводим регресс, в четверг стараемся релизить.
Спринты разбиты на бакеты:
- продуктовый бакет, самый большой, первая неделя спринта и понедельник следующей недели, пилим продукт
- саппорт бакет, вторник второй недели, фиксим баги, новые или накопившиеся
- бакет техдолга, последние 3 дня спринта, пилим технические задачи
Договаривать о том что делать в каждом из этих бакетов нужно с тимлидом. Следить за тем чтобы продуктовый бакет не вырос на целый спринт придется следить вам самим. Каждый разработчик заинтересован в выделении времени под техдолг
Так, вроде все рассказал, скоро стендап, пора вылезать из ванны. Вернусь к вам днем, поговорим подробнее про все что предстоит узнать новичку именно об iOS специфике
@mobileunderhood А сколько у вас iOS’ников в команде, если не секрет?
Вот это топовый вопрос, я забыл упомянуть. Нас сейчас 10, ищем еще twitter.com/tw1tteru5er/st…
Уфф, ну и денек, включили наконец CI на PRах, дженкинс разорвало) Кажется что твитить по 3 раза в день было авантюрой, хотя может быть дальше будет посвободнее...
Этой ночью стартует сезон в NBA, какой матч будете смотреть?
Ладно, к делу. С чем же приходится знакомиться новичку на старте работы у нас в компании? Для начала - с проектом. У нас монорепа, но не монолит. Дальше - подробнее
Наше приложение разбито на модули с помощью фреймворков. CocoaPods используем только для сторонних зависимостей. Модули разбиты по слоям, разрешено импортить только модули из нижних слоев. Из своего слоя или слоя выше - нельзя
Слои сверху вниз:
- Основная аппка. Это остатки монолита, мы продолжаем вырезать из нее куски
- Flows. Их два. Это основные сценарии нашего приложения: рестораны и продукты
- Features. Тут собраны модули для отдельных фич, переиспользуемых в аппке или во флоу
...
...
- VIP. Это отдельные экраны, переиспользуемые в фичах. Название такое в честь архитектуры (о ней завтра), а не из-за важности
- Managers. Вы размажете меня по стенке, но у нас сущность которая ходит в сеть называется... Manager...
...
...
- Repositories. Эти ребята - фасады над менеджерами. Могут иметь много менеджеров для агрегации разных данных, могут хранить кеши. Один интерактор - один репозиторий
- Models. Тут свалка моделек для бизнес логики
...
...
- Libs. Абстракции над сторонними библиотеками, наша дизайн система и модуль для экспериментов и фиче тогглов
- Helpers. Думаю комментарии не нужны, у всех есть
- Logger. Умеем логировать в крашлитику с релизных сборок
Тест на внимательность. Где тут ошибка?
Правильно, Repositories и Managers надо поменять местами, косякнули.
Окей, с этим разобрались. Как же нужно писать код? У нас есть линтер, который подскажет (у всех наверное есть). У нас остались выключенными некоторые правила, которые очень хотелось бы включить, но тысячи ворнингов в легаси пока откладывают это действие
У нас есть кодстайл. Мы взяли за основу AirBnb, положили в readme и решили делать в него PR если какое-то правило не нравится или хочется внести новое. Голосованием галками будем решать принимать ли PR
С тех пор как мы это сделали, разговоры о том что нам нужен код стайл подутихли, но не уверен что им кто-то пользуется. По крайней мере PRов в него было очень мало
У нас одна ветка - develop. Стараемся делать маленькие PRы, по максимум все закрывать фича тогглами, чтобы можно было лить PRы по недоделанной фиче в develop. Если никак - то longterm ветка, но у нас такое - редкость
У нас есть правила по оформление PRов. Там есть пункт - добавить скриншот, а лучше гифку с записанным функционалом в коммент к своему PR. Так делают не все и не всегда, но когда делают - ревьюить ну очень приятно. Всем советую
Кстати, не из банального. У нас есть лесенка ревьюеров. Это табличка, где перечислены все разрабы, и каждому присвоен первый ревьюер, второй ревьюер и третий. При создании PR нужно добавлять только первого. Первый, после ревью добавляет второго и т.д. Ну или ставит NW конечно
Зачем это? Психологический фактор. Когда видишь PRы, где кроме тебя несколько ревьюеров, думаешь: кто-то другой посмотрит. А когда ты один - ты блокер. Дополнительный бонус - несколько ревьюеров не кидают одновременно одинаковые комменты
Мы периодически шаффлим нашу лесенку, учитываем тех кто в отпуске. Я написал скрипт на свифте, который это делает, оказалось нетривиальная задача. Если интересно - могу поподробнее описать, но попозже
Из 18 опрошенных никто не собирается смотреть матч GSW - Nets, что вы за люди... Я ради этого матча подписку купил на год
Среда
Всем доброе утро, я снова на связи, снова из ванной. На этот раз сделал воду попрохладнее, а то вчера налил горячую и вскоре стало как в бане. Сегодня поговорим про процессы и архитектуру
Давайте начнем с настроения общественности. Что лучше, кроссфункциональные продуктовые команды или по направлениям (iOS команда, к примеру)
И еще один опрос. Скрам (ну или agile) - это хорошо или плохо?
Я люблю agile, и возможно, что это неосознанное мнение, связанное с кое чем из моего прошлого. Знаете, как психологи говорят, многие взрослые поступки, точки зрения, строятся на основе моментов из дества
В начале карьеры я работал 3 года соло iOS разработчиком и у меня в принципе не было никаких процессов, даже вотерфолла. Но самое гоавное - не было команды, не было общения с людьми
А потом я перехожу в большую команию, где команда и agile. Встречи каждый день, иногда несколько раз в день. И сразу так стало приятно. Чувствуется плечо товарища, чувствуется важность того что ты делаешь
Поэтому я считаю что Agile способствует мотивации и желанию работать. Когда я работал в соло, я большую часть рабочего времени тратил на просмотр баскетбола и развитие себя в качестве покерного игрока
Попав в окружение коллег, делающих совместно одно дело я стал развиваться в своей профессии. Мне стало это интересно. Работа перестала для меня быть «просто работой». Хотя я еще женился в то время, может это тоже связано)
Еще я время от времени слышу мнение, что в скраме слишком много встреч и он не подходит именно вашей команде, ее специфике. Согласен, но...
Но если каждая команда будет начинать с изобретения велосипеда (будет придумывать какой-то свой, идеальный процесс), то она никогда не начнет работать. Потому что поиск идеала бесконечен. А скрам, со своими минусами, закрывает из коробки большинство потребностей
Подытоживая - я за наличие процесса и против его отсутствия. Я против слепого следования правилам, но я за то чтобы начинать по правилам и менять их итеративно и осознанно
Что-то на философию потянуло... А если вернуться на землю, то давайте обсудим плюсы и минусы нашего процесса, я описывал его вчера
Стендапы - отличная штука. Держит тебя в тонусе, не позволяет неделями заниматься непонятно чем на работе. Оставляет тебя «в струе» так сказать
Планирование - тоже норм. Тратишь час, а получаешь понимание и спокойствие на 2 недели вперед. Объем работ понятен, импакт понятен, приоритеты ясны, голову можно выключать
А вот что мне не очень нравится - так это то что на техдолг (3 последних дня спринта) приходится чересчур много встреч, подготовка спринта, демо, ретро. Зачастую времени на разработку очень мало. А для меня техдолг - это возможность влиять на свои же будни и будни коллег
Демо - тоже классная штука, люблю выступать, люблю слушать других. Приятный способ провести время и узнать чем занимаются другие команды
Ретроспектива. В теории - топовое мероприятие. Позволяет улучшать процессы, продвигать свои идеи, менять повседневную рутину в лучшую сторону. На практике - поныли, потерпели, разошлись. Очень мало было на моем опыте ретроспектив, по итогам которых что-то менялось. И это грустно
Внимательные вспомнят, что есть еще стендап iOS разработчиков. На мой взгляд - это геймченджер. Я когда пришел и услышал что айосеры встречаются каждый день, я очень удивился. Но именно общение приводит к единству команды. А оно ощущается. Даже на удаленке
Ладно, время принять душ и бежать на стендап. Встречу днем не обещаю (наученный вчерашним опытом). До встречи вечером. Хотя всякое бывает...
Ребятки-ребятушки, сегодня день выдался еще хлеще вчерашнего, давайте с вами завтра утром поболтаем, тема - работа с техдолгом
Четверг
Доброе утро всем! Вот когда у меня точно есть время на твиты - так это по утрам. Я каждый день встаю в 7:00, потому что у сына режим и его надо разбудить. Потом мы тусим, гуляем и где-то в 10 я передаю его жене и начинаю работать. Ну а на этой неделе - твитить
Вчера я словил хейта за твит, мне понравилось, чувствую себя звездой)))
Но, пока меня не отвлекли по работе, расскажу про то, как мы в Delivery Club работаем с тех долгом. Точнее, в iOS команде
Я уже говорил, что у нас есть бакет техдолга в каждом спринте - посоедние 3 дня. Некоторые команды экспериментируют и пробуют делать несколько полностью продуктовых спринтов, а затем технический спринт. Тоже валидная опция
Иногда продуктовые задачи настолько важны, что время на техдолг в спринте не выделяется. Это редкость, но бывает. Можно договориться о том, чтобы в следующем спринте вернуть должок. Все в ваших руках
И кстати, это дает простор для маневра и в обратную сторону. Если есть архиважная задача по техдолгу, то можно договориться с тимлидом и продактом о том, чтобы взять под техдолг больше времени. Опять же, все в ваших руках
С ответом на вопрос «Когда?» разобрались. Теперь поговорим про «Что?»
Чтобы понять что делать в рамках техдолга, нужно иметь некий бэклог и приоритеты. Мы решили это так: собрались, обсудили главные боли и выделили 4 направления, в рамках которых будем улучшать наш проект
Эти направления мы назвали - стримы. Получились вот такие:
- CI/CD
- UI-тесты
- Дизайн система
- Платформа
У каждого стрима есть родмап и бэклог. Есть техлид, который отвечает за стрим. Есть 2-3 разработчика. Есть регулярные синки, раз в 2 недели
Подробнее про каждый из них.
CI/CD
У нас было 2 основных проблемы. Мы собирали сборки для релиза руками и не гоняли тесты на PRах. Мы это исправили, теперь у нас все красиво. Релизный пайплайн с выгрузкой в Firebase и TestFlight, unit тесты на каждом PR. Наконец-то)
Теперь бэклог этого стрима содержит задачи на оптимизацию пайплайнов, автоматизацию рутинных задач и прочие приятные мелочи
UI-тесты.
Еще одна наша боль - это регресс. Его проводят раз в неделю QA-инженеры всех продуктовых команд, занимающихся мобильной разработкой. Мероприятие на день-полтора. Очень хочется сократить и автоматизировать. Решили покрывать сценарии регресса UI-тестами
Синканулись с андроидом, выработали единые подходы к тестированию, сделали даже похожий синтаксис (благо Kotlin и Swift схожи). Будем подключать QA-инженеров к написанию тестов.
Продумали когда будем гонять тесты и как будем реагировать на их результаты. Решили не гонять их на PR, чтобы не тормозить разработку из-за моргающих тестов. Гоняем по ночам и на регрессе.
По результатам прогона во время регресса составляется список прошедших успешно тестов. Эти сценарии руками тестировать уже не нужно. Все красные тесты нужно проверить руками. Зато нет требования обязательного прохождения всех тестов
По результатам ночного прогона об упавших тестах оповещаются все заинтересованные команды. Решение о том, насколько срочно чинить тест и нужно ли его вообще чинить принимается внутри команды. Может чинить тест дороже чем каждый раз тестировать руками
Дизайн система
Здесь мы прям в самом начале пути. Сделали отдельный модуль, назвали дизайн системой, добавили цвета и шрифты. Потихоньку обогащаем ее общими компонентами: кнопками, алертами и прочим
Платформа
Основной фокус этого стрима - система мониторинга о стабильности приложения. С помощью связки MyTracker и Grafana мы научились мониторить сценарий авторизации пользователя. Если количество ошибок превышает некое значение, то в телеграм приходит алерт и мы реагируем
Кроме этого, платформа занимается рефакторингом легаси и выпиливанием остатков Objective-C. Большое спасибо ребятам за эту работу
В следующем году мы планируем выделить платформенную команду, которая будет фуллтайм заниматься техническими задачами. Туда будут стекаться самые важные проекты и задачи. Кажется что работа станет более прогнозируемой
Кстати, по опыту продуктовых команд, которые изредка делают технические спринты, может стоит для платформенной команды иногда делать продуктовый спринт, чтобы держать разработчиков в тонусе)
А вы какие задачи больше любите, продуктовые или технические?
Пятница
Доброе утро, мои дорогие. Сегодня я чуть раньше выхожу в эфир, потому что жена укладывает сына спать дома и мне не нужно с ним гулять. Сегодня мы поговорим про технический бренд
Хочу собрать обратную связь о нас. Я понимаю что продукт Delivery Club известен всем, а как обстоят дела с техническим брендом? Помимо того что я рассказывал на этой неделе, слышали ли вы про разработку в Delivery Club?
Давайте разберемся что такое технический бренд, на что он влияет и почему полезно его качать
Технический бренд - некая мера известности среди разработчиков. Бывает личный тех бренд, например, мой. А бывает тех бренд компании, например, Delivery Club
Личный тех бренд разработчика, зачем он нужен? Думаю, все сводится к одному. Проще устроиться на работу. Речь не только о работе программистом, но и о любой медийной деятельности.
Вот я, например. В этом году я занялся своим техническим брендом. Первое что я сделал - выступил в первом сезоне Podlodka iOS Crew. Мне кстати за это заплатили. Потом выступил во втором сезоне
Теперь я провожу интенсивы по iOS разработке для Skillbox, скоро выйдет пилот на youtube канале Технострим, где я буду писать код, ну и вот, в твиттере засветился. Нужно вам это или нет - решать вам. Но возможностей становится больше и они разнообразнее
А вы до этой недели где-то меня видели?
На самом деле любой тех бренд сопровождается аудиторией. А для того чтобы набрать аудиотрию в 2020 нужно развивать соцсети. А этого я не делаю. Заметили что в профиле нет ни одной ссылки на что-то мое?
Теперь разберемся с тех брендом компании. Он нужен для того чтобы люди хотели в этой компании работать. Найм - довольно трудозатратное мероприятие и упрощать его полезно любой компании
Как компания может прокачать свой тех бренд? Рассказывать о себе на всевозможных ресурсах. Статьи, выступления, нужно себя рекламировать. Можно организовывать мероприятия, собирать людей, проводить экскурсии по офису. Можно контрибьютить в open source
Для того чтобы всем этим заниматься, нужны активные сотрудники, которым подобные мероприятия интересны. И в этот момент рождается синергия между сотрудником, развивающим личный тех бренд и компанией, развивающей свой тех бренд
А вот вам еще одно подтверждение того, что личный тех бренд приносит пользу. Для компаний, которым это важно полезны и такие сотрудники.
А теперь еще один пример. Допустим появляется новое направление бизнеса, нужно собрать команду. Какого тимлида взять? Ноунейма или того, чья фамилия на слуху? Ко второму охотнее пойдут работать. Опять же, упрощается найм
На последок дам напутствие всем. Не бойтесь рассказывать людям то что думаете. Наверняка ваши мысли кому-то покажутся полезными. Ну, а если нет - что в этом плохого? Самое ужасное что может случиться - это уснувший зритель/слушатель. Так что действуйте!
Суббота
Помните я писал что хотел посмотреть матч Nets - Warriors? В воинах я конечно разочаровался, а вот Nets вообще в порядке по первым матчам
Долго я думал над темой этого треда и наконец определился. Оценка задач, планирование и все что с этим связано
По традиции начну с вопроса без контекста. В чем оценивать задачи?
Давайте разбираться. Зачем вообще оценивать задачи? У любой задачи есть заказчик и исполнитель. В нашем контексте, исполнитель - это iOS разработчик. Заказчиком может быть кто угодно: тимлид, продакт, клиент (если вы - аутсорс компания)
Вообще в аутсорсе с оценкой все строже, ведь на основании оценок договариваются о сроках и стоимости проектов. Но в аутсорсе я не работал, давайте установим контекст для продолжения рассуждения: продуктовая команда с собственной разработкой
Я думаю, оценка задач нужна и заказчику и исполнителю. Заказчик заинтересован в том, чтобы знать хотя бы примерный срок выполнения задачи. Скорее всего заказчик ведет не одну задачу, а для составления планов, родмапов, диаграм Ганта и всего такого надо от чего-то отталкиваться
А исполнителю нужна оценка для того чтобы понимать, успевает он или нет. Да и в принципе для того чтобы понимать скорость своей работы
А теперь давайте рассмотрим две классических единицы оценки задач на примере небольшой iOS команды, где есть, к примеру, один джун, один мидл и один синьор
Оценка в часах. Это единица времени, которую необходимо потратить на разработку конкретной задачи. Давайте оставим за скобками сторонние процессы вроде код ревью и будем считать что разработчик пушит в мастер без тестирования
Мы не землекопы, которые копают с постоянной скоростью прямую траншею заданной длины. Поэтому абсолютно точной оценки не может дать никто и никогда. Да и если бы мы были землекопами, никогда не знаешь сколько на пути траншеи ты всетишь корней, кирпичей и прочих неожиданностей
Это я говорю как человек, копавший канавы на даче))
Итак, сформировалась первая проблема: как оценить задачу? Как понять сколько же она займет времени в часах? Вопрос сложный и ответа у меня нет. Помогает опыт, помогает обсуждение с командой.
Вторая проблема возникает, когда вы оцениваете задачи всей командой. Напомню, что у нас в команде джун, мидл и синьор. Допустим команда оценила задачу на 4 часа разработки. Вопрос, за сколько эту задачу в итоге выполнит джун, а за сколько синьор?
Получается, что оценка в часах зависит от конкретного исполнителя? Либо для конкретного исполнителя добавлять множитель: джуну х2, синьору х0,5? А что если есть 2 синьора, но с разным опытом в предметной области?
Зато у оценки в часах есть существенное преимущество. Можно сравнить оценку с реальными затратами. И понять, попал или нет. Возможно, даже можно улучшить свой навык оценки задач благодаря таким регулярным проверкам и анализу
Теперь перейдем ко второму способу. Оценка в стори поинтах. Стори поинт - относительная мера сложности задачи. Это значит что нужна некая эталонная задача, ей присваивается один стори поинт. А дальше все остальные задачи сравниваются с эталонной и другими оцененными задачами
Что мне нравится в этом подходе - независимость от исполнителя. Это метрика именно задачи. Но возникает резонный вопрос, как спрогнозировать срок, который важен заказчику? Как исполнителю понять, успевает ли он?
Способ есть. Эмпирический. Нужно поработать несколько спринтов (стори поинтами меряют задачи в Agile). Замерить сколько стори поинтов выполняется за спринт и можно предположить, что и за следующий спринт выполнится столько же.
Есть еще одна интересная особенность оценки задач в сторипоинтах. Вариантов оценок существует ограниченное количество. По классике - числа фибоначчи. 1 2 3 5 8 13 21 и т.д. Это логично, чем сложнее задача, тем больше разброс в точности оценки
Но один вопрос остается открытым. Как узнать, не ошибся ли ты с оценкой? Возможно стоит анализировать флуктуации (спринты, когда выполнилось либо сильно меньше чем обычно, либо сильно больше)
Мне подход со стори поинтами значительно больше импонирует, и когда я работаю в команде где оценка в часах, я на самом деле маскирую оценку в сторипоинтах часами. То есть я оцениваю задачи путем сравнения их сложности, стараюсь выбирать из ограниченного количества вариантов
Раз мы затронули спринты, то давайте разберемся как посчитать capacity, то есть емкость спринта. в случае со стори поинтами у нас есть средняя скорость спринта и к ней нужно внести коррективы в зависимости от больных, отпусков и т.д.
В случае оценки в часах, появляется термин фокус-фактор. Кажется, что разработчик не пишет код по 8 часов в день, хотя его рабочий день именно таков. Но какое-то время он тратит на встречи, какое-то на переключение контекста, а какое-то на мемасы
Фокус-фактор - это коэффициент перевода реал ных часов в эффективные часы разработки, в которых ведется оценка. В одной команде у меня был фокус-фактор 0,5 и это означало что ядолжен взять в двухнедельный спринт задач на 40 часов
Сейчас в моей команде другой подход. Мы для вычисления капасити сперва вычитаем все запланированные встречи. А потом оставшиеся часы умножаем на фокус-фактор 0,8. Кстати, в среднем, получается примерно столько же
Давайте закончим тему опросом. Сколько времени в среднем в день вы реально пишете код? (тимлидов просьба вспомнить старые добрые деньки, когда вы были разработчиками)
Воскресенье
Вспомнил, что не успел рассказать про архитектуру нашего iOS приложения, давайте сейчас исправлюсь. Она называется VIP и это по сути компоненты из VIPER, только перемешены немножко по-другому
Ну, давайте с основ. Презентационный слой: вокруг каждого UIViewController есть однонаправленный треугольник, состоящий из него самого, Interactor, и Presenter
Однонаправленный, потому что вьюха сообщает интерактору о действиях пользователя, интерактор говорит презентеру какие данные подготовить, презентер говорит вьюхе что отобразить на экране. В обратную сторону связей нет
Вьюху держит UIKit, она держит интерактор, который в свою очередь держит презентер. У презентера слабая ссылка на вью
Ответственность вьюхи - отображать данные из тупых ViewModel. Это структуры с подготовленными для отображения данными. Так же вьюха сообщает интерактору о действиях пользователя
Ответственность презентера - подготовить данные. То есть перевести их из моделек для бизнес логики во вьюмодели. Если презентер разрастается, то создается вспомогательная сущность: Mapper, в которую уходит часть логики
Интерактор - главный чувак. Он хранит состояние и принимает решения. Какие решения он может принять? Запросить данные из источника, скомандовать о переходе на другой экран, скомандовать о том что нужно готовить данные для отображения
Для обработки всех состояний при загрузке данных мы используем стейт машину. Специальная сущность, с помощью которой мы привели к единому виду работу с загрузкой данных на всех экранах. Для самих запросов - Repository
Repository - это чувак, который знает откуда какие данные брать. Он может взять их из локального хранилища, может попросить Manager’а сходить в сеть. Иногда полезно подписываться на изменения в Repository, чтобы получить актуальные данные. Этот механизм у нас тоже реализован
Возвращаемся в интерактор. Для перехода на другой экран мы используем Router. Если роутер умеет отобразить новый экран, то делает это сам. Если нет - проксирует до координатора. Координатор - это грубо говоря тот же роутер, только обладающим большим контекстом
Для того чтобы собрать всех этих чуваков мы используем билдер. Билдер на вход получает все необходимые внешние зависимости, создает все внутренние сущности и связи между ними.
Для того чтобы создать билдер с внешними зависимостями используем Assembly. Он с помощью Swinject резолвит все что нужно и прокидывает билдеру. Мы сдклали так на случай если решим сменить Swinject на что-то другое, тогда менять придется меньше кода
Интересный момент возникает когда нужно передавать данные между VIP модулями. Для этого мы делаем связь интеактор - интерактор, закрываем ее протоколом. Если надо докинуть данные внутрь можуля, то создаем протокол ModuleInput, который реализует наш интерактор
Если нужно прокинуть данные наружу, то создаем протокол ModuleOutput, который реализует внешний интерактор
Еще один интересный кейс - как отображать алерты. Интересен он тем, что нужно решить кто занимается локализацией строк, а кто отображением алертов. В идеальном мире, строками занимается презентер, а отображает роутер с помощью слабой ссылки на вью
Но проблема в том, что роутером командует интерактор, а обратной связи от презентера к нему нет. Получается что либо надо создавать обратную связь от презентера к интерактору, либо передать отображение алерта во вью, по команде от презентер
Либо разрешить роутеру локализовывать сроки, чего мы делать совсем не хотели. В итоге остановились на втором варианте: интерактор командует презентеру чтоб локализовывал строки, презентер командует вьюхе чтоб показала алерт с этими строками
Разумеется, у нас не все экраны сейчас на этой архитектуре. Есть совсем легаси экраны на Obj-C, есть поновее, где только вьюха и презентер. Но мы активно приводим проект к этому новому виду
Для генерации модуля мы решили использовать шаблоны Xcode. Показалось удобнее чем Generamba, в основном из-за многомодульности приложения
Но минусы у шаблонов тоже есть, они не умеют создавать группы с вложенными группами. Только folder reference. Приходится создавать модуль, потом удалять его из проекта и добавлять снова
Зато нативненько. Кроме шаблона для генерации VIP-модуля, мы используем шаблон для генерации менеджера (у него тоже много вложенных сущностей), шаблон для теста на Quick&Nime, шаблон для теста на интерактор.
А еще пара шаблонов, которые пригодятся всем: шаблон UIView + Xib (как для ячеек) и шаблон проктол + имплементация. Последний - вообще гейм ченджер для меня. Меня всегда ломало 2 файла создавать и я объявлял протокол в файле с имплементацией
