У нас с Артёмом зудит,когда мы ищем материалы по какой‑то теме и не можем найти достаточно годноты. Нам не хочется искать кучу разрозненных статей по разным углам интернета,а хочется,чтобы всё было удобно,в одном месте и написано понятным языком. В последний раз такое случилось с ООП.
Объектно‑ориентированное программирование — старо как мир,по нему есть куча книг,но они толстые и заумные. Статьи о нём либо слишком академические,либо слишком простые и не покрывают сложных проблем,которые нам интересны. Источников на русском языке вообще раз,два и хабр.
В общем,нам бомбануло,и мы написали Солидбук. Это книга,в которой мы рассказываем о принципах SOLID, как их применять,чем они полезны.
Мы перелопатили кучу источников: книг,статей,научных работ,примеров. Для каждого принципа подобрали случаи из реальных проектов,с которыми работали. Нашли подходящие примеры из«идеального мира». Подобрали шаблоны проектирования и приёмы рефакторинга,которые помогают эти принципы соблюдать. Отобрали антипаттерны,которых советуют избегать. А ещё для каждого принципа мы приготовили вопросы и тесты для самопроверки!
Если книга вам зашла,пошарьте её в соцсетях и блогах или полайкайте на гитхабе. Мы будем благодарны! А если эта книга или другие статьи‑проекты‑что‑то‑ещё вам очень‑очень зашли,то вы можете поддержать нас на Патреоне.
В прошлом посте я рассказал,с какими проблемами столкнулся при разработке новой версии торговой площадки. В этом посте расскажу о ролях,которые успел примерить за время работы помимо«фронтенд‑разработчика» и том,какие скиллы помогли довести дело до конца.
Технолог тоже дизайнер
Ни один план не выдерживает встречи с реальностью,с дизайном та же история.
В разработке неизбежно настаёт момент,когда макеты перестают работать: поменялись бизнес‑требования,появились новые технические ограничения,мы что‑то не учли в дизайне,на устройстве работает всё совсем не так,как хотели,сроки горят,надо упрощать… Короче,картинки перестают работать,надо принимать решения на ходу. Часто — технологам.
Площадку задизайнил Костя Константинопольский. С ним мы работаем давно,и у нас есть наработанный общий контекст,который помогает мне быстрее понимать его решения и развивать их,прорабатывая детали. В этом проекте это особенно помогло.
Главной частью моего участия в дизайне была сверка макетов с реальностью. Я оценивал,насколько ресурсозатратным каждое решение могло оказаться. Что‑то я намеренно упрощал,чтобы не получалось чрезмерно дорого,что‑то распланировал на время после запуска,где‑то даже находил решения проще.
Пока не набил руку,каждое изменение утверждал у команды,потому что я не дизайнер и мог пропустить что‑то важное. Так,например,было с первым шагом регистрации компании. Мне показалось,что я смогу упростить автозаполнение реквизитов. Новое решение не подошло под требования,о которых я не узнал заранее.
Решение,которое я попробовал упростить,но у меня не получилось
Другой частью моего дизайнерства была разработка мобильной версии. Мобильные макеты у нас были,но они были больше похожи на отдельную версию для телефонов,чем адаптив того же приложения. Сделать ровно как на макетах было бы слишком дорого и долго. Поэтому мы обсуждали каждый экран,думая,как можно совместить нарисованное с техническими ограничениями.
Самой сложной частью оказалась работа с пользовательским контекстом,переходами между экранами и пользовательскими сценариями. Картинки нельзя прокликать и посмотреть,как будет работать дизайн в жизни.
Что произойдёт,когда я поставлю невалидную ставку; как мне придёт сообщение о победе в торгах; насколько запарно создавать таблицу с товарами для торгов? Всё это можно было ощутить либо имея кликабельный прототип,либо в ходе разработки. Каждое слабое решение мы меняли на другое.
Совмещать разработку с дизайном трудно,потому что необходимо помнить о принципах и цели продукта. Я разработчик,и у меня лапки иногда мои решения страдали от технозависимости. Принципы и цель помогали с этим бороться.
Тоже бекендер и девопс
Код писало двое человек: я и серверный программист. У нас не было ресурсов на отдельного человека для инфраструктуры,поэтому окружение,интеграцию и доставку настраивали мы сами.
Окружение и процессы — важная штука. Кажется,что они не особо влияют на результат,но они влияют на производительность,а вот уже она непосредственно влияет на результат. Чем хуже окружение,чем больше рутинных операций нужно выполнять вручную,чем дольше собирается билд и проходят тесты — тем больше времени тратится на непонятную херню,вместо решения задач.
У меня не получилось на 100% создать структуру с сине‑зелёным продакшеном и выделенным сервером под тестирование. Получилось примерно наполовину: мы ограничились CI/CD и прогонкой тестов в Travis.
Но вот для сборки и дев‑окружения фронтенда я автоматизировал кучу процессов: от старта проекта до прогона всех приёмочных критериев в CI. Оптимизировал запуск тестов под разные задачи: юниты на ядро,глупые компоненты,контейнеры,снапшоты,такая часть проекта,сякая часть проекта — всё можно было запускать отдельно,если нужно. Пару раз оптимизировал сборку,чтобы работало быстрее.
На окружение важно выделять время,потому что обидно находить себя в ситуации,когда четверть рабочего времени уходит на бесконечные сборки‑пересборки‑деплои‑и‑билды. От этого надо избавляться. Запускайте в фоне всё,что только можно,параллельте процессы,жгите процессор — делайте окружение комфортным.
Автоматизация также спасает от человеческой невнимательности. Если надо сделать несколько рутинных операций,человек всегда будет тупить проигрывать компьютеру. Люди ленятся идти по списку,делают что‑то неправильно,случайно(или неслучайно) пропускают пункты. Компьютер всегда выполняет инструкцию полно и правильно. Перестраховывайтесь от человеческого фактора.
Тоже редактор и маркетолог
Вместе с задачами на дизайн прилетали задачи на тексты и интерфейсные подписи. В основном приходилось думать над подписями элементов,чтобы было понятно,какую задачу они решают и зачем нужны.
Была и пара задач на«продажу» фич. В голландских аукционах мы сделали экран,где участник мог видеть положение курсоров соперников. Это стимулирует принимать решение быстрее,а значит покупать по более высокой цене.
Мы думали,как объяснить пользу этого экрана,показать принцип работы,как подписать«включатель» этой фичи. Потом то же — но для участников. Если бы за каждой кнопкой я бежал к дизайнеру за макетом,то мы,скорее всего,зарелизились бы году в 3019. Умейте работать с текстом, экономьте время и запускайте проекты быстрее.
Тоже менеджер
В прошлом посте я писал,что было трудно поддерживать мотивацию и ритм работы. С этим может помочь планирование и менеджерский скилл.
Мне по началу было трудно привыкнуть уделять время планированию и определению приоритетов,а не программированию. Но меня спасала аналогия с процессами в разработке — планирование же тоже автоматизация. Оно помогает на время забыть о том,«сколько всего надо сделать и не упустить бы ещё вот это».
Календарь и чеклисты разгружают голову. А свободное место в голове — основа хорошего отдыха, без которого работать продуктивно не получится.
Кроме того,без своевременной корректировки требований и ограничений запуститься было бы нереально. Чтобы проект к релизу всё ещё был нужен,его надо актуализировать,а делать это стихийно бесполезно. С этим тоже помогает планирование.
Тоже эйчар
После релиза я начал искать бойцов себе на замену. Я отбирал не просто фронтендеров,я искал людей,близких по духу и ценностям. Мне было важно,чтобы после моего ухода продукт был в порядке и развивался дальше. Людям,ценности которых не совпадают с моими или ценностями компании,довериться было страшно.
Проводить собеседования для меня было в новинку. Я сделал вывод,что проводить именно технические собеседования не имеет смысла. Вместо этого я фокусировался на вопросах о видении человека своей работы,на том,насколько кандидаты подходят нам,а наша компания — им.
Я рассказывал о продукте и для кого мы его делаем,как мы работаем и что для нас важно,как устроены процессы и как мы видим идеальную рабочую среду и т. д. После я слушал,что кандидаты рассказывают о своём опыте,расспрашивал о задачах,которые они решали,о проблемах,с которыми сталкивались,почему хотели работать у нас. Ближе к концу созвона я ещё раз обозначал наши ожидания: мы искали не просто фронтов,а людей,двое или трое которых смогли бы полностью заменить меня.
Однажды всего этого стало слишком много. У меня была неделя с 25 созвонами примерно по 2 часа каждый. Это не считая ревью тестовых заданий для тех,кто согласился на тестовое.
Я сильно закопался. Тогда на помощь пришёл Костя. Мы поняли,что собеседования превратились в конвейер,а я подзабыл,зачем это всё.
Мы с Костей проговорили цели,задачи и проблемы и решили,как именно надо искать нового человека. Снизили напряг,сократили ресурсы на поиск и фильтр кандидатов. В итоге я нашёл двух отличных ребят: Тимофея Аксенова и Романа Макарова. Сейчас весь фронт на них.
Тоже тимлид
Когда я нашёл людей в команду,начал думать,как их погружать в проект. Заготовок у меня не было,пришлось импровизировать. Придумал план рассказа о проекте.
Первый шаг — рассказ о высокоуровневых штуках: как работает архитектура,какие есть роли у клиентов,в чём разница между организатором и участником,какие сущности в принципе есть в предметной области. Без кода. Только интерфейс приложения и рассказ с примерами того,как работает.
Второй шаг — рассказ,где в коде какая часть интерфейса находится,как работает,какие сущности на экране каким сущностям соответствуют в коде. Всё это — шаря экран и показывая в живую,«вот здесь — это,здесь то».
Я быстро осознал,что это решение не масштабируется. Если бы мне приходилось нанимать людей чаще,то я бы быстро сдулся. Начал думать про автоматизацию онбординга и сбор базы знаний. Довести идею до реализации не успел,и настроить онбординг у меня не получилось.
Зато поуправлять командой перед уходом — получилось. Я научился распределять задачи по приоритетам для бизнеса в соответствии со скиллами разработчиков. Было клёво наблюдать как уровень ребят рос,и можно было делегировать более серьёзные задачи.
Делегировать оказалось трудно. Для меня было важно преодолеть желание сделать самому. Не имело значения,что я это сделаю быстрее,моя роль изменилась. Теперь задача состояла не в том,чтобы писать код,а в том чтобы код писался без меня. Когда осознал,полегчало,делегировать задачи стало проще.
Параллельно учился описывать задачи более понятно. Скудное описание демотивирует,потому что непонятно откуда брать нужные данные. Слишком объёмное — лень читать. Учился находить баланс.
Конечно,у меня тоже бывают моменты,когда я думаю«уф,это же не моя работа,почему я вообще должен этим заниматься?», но чаще всего — это от усталости. Работа может приносить удовольствие, если найти отчего прёт. Меня пёрла огромная амбициозная задача. Вроде,справился.
Последние джва полтора года я работал в закрытом режиме над фронтендом для последнего проекта. Мы не могли себе позволить до релиза пилить фичи итеративно и выкатывать их по мере готовности. Нам нужно было полностью переделать сервис и выкатить новую версию разом.
В этом посте я расскажу,почему это трудный путь,покажу ошибки,которые я допустил,и посоветую по возможности избегать такого подхода.
Контекст
Задача была в том,чтобы переписать фронт,обновить дизайн и добавить новые типы торгов.
Проект оказался сложным — я с таким уровнем до этого не сталкивался. Чтобы как‑то справиться,старался искать рекомендованные подходы,читать книги об организации кода и архитектуре и применять это всё по ходу дела.
Теперь вот рассказываю о граблях,которые насобирал.
Проблема 1. Один в поле
Я начинал писать фронт один. Писать сервис одному — значит страдать от недостатка ревью и обратной связи. Рефакторить трудно,спросить совета не у кого(исходники‑то под NDA).
Сила командной работы в том,что все погружены в контекст. Каждый в команде знает обо всех компромиссах и слабых решениях. Сами решения появляются не в одной голове,а свежий взгляд на задачу всегда помогает найти более простое решение.
Если вы пишете сервис в одиночку,этого будет сильно не доставать. И чтобы при этом поддерживать работу,надо обладать очень сильной самодисциплиной.
Проблема 2. Проседающая мотивация
Если вы пишете большой сервис в закрытую,неизбежно столкнётесь с состоянием,когда объём работы будет казаться неподъёмным,а планы перестанут вас убеждать,что вы справитесь. В такие моменты сильно проседает мотивация.
Чтобы не терять фокус и продолжать,я дробил этапы и задачи на более мелкие этапы и задачи. Так прогресс был более заметен,и впечатление непосильности на время отступало.
Но иногда и дробление переставало работать. Мне тогда помогало сесть и начать хоть что‑то делать. Начав с малого,можно втянуться и продолжать работать. Но именно«сесть и начать» бывает сложно.
Короче,марафоны, особенно закрытые,подходят не всем. Тщательно обдумайте решение,перед тем как вписаться в марафон.
Проблема 3. Отсутствие обратной связи
Если разработка не итеративная,значит какое‑то время результат работы будет уходить в стол. Когда проект не раскатывается на настоящих пользователей,работа может казаться бессмысленной.
Без обратной связи от мира трудно убедить себя,что есть реальная польза от работы. Без них может быть туго с удовлетворением от результата. Ну а без него — см. пункт 2 ↑
Проблема 4. Страх запуска
Итеративная разработка — это делаем фичу и деплоим её,когда она готова. Если что‑то пошло не так,узнаем об этом сразу,будет понятно,что вызвало проблему и как её исправлять.
В случае с закрытой разработкой всё не так. Вы пишете большой набор фич,из которых отвалиться может что угодно. Чем больше проект и чем дольше времени он был закрыт,тем больше страх запуска.
Дело не только в страхе,что в коде ошибки,но и в целом за продукт. Дизайн может вызывать отторжение,пользовательские шаблоны могут поломаться,где‑то точно появятся ошибки,которые будет трудно отследить.
Если логику можно покрыть тестами и частично снять когнитивную нагрузку, то с«предвосхищением» реакции пользователей на новую версию ничего поделать нельзя. Только запуститься,скрестить пальцы и ждать.
Преодолевать страх — трудно. Деплоить итерациями — спокойнее. Понять это на своём опыте — бесценно.
Проблема 5. Фичеризм
Если пилите проект в закрытую,очень велик соблазн добавить как можно больше фич.«Раз уж мы не выкатываемся по частям,давайте сделаем всё‑всё‑всё.» Это — путь в никуда.
Занятно,что чем больше времени потрачено на разработку,тем легче согласиться на ещё какую‑нибудь фичу. Ведь«мы потратили столько времени,не страшно потратить ещё немножечко». Но из таких«немножечек» могут складываться недели и месяцы. Не надо так.
Проблема 6. Размер и сложность
Помнить всё — нереально; слишком дофига деталей и нюансов.
Важно решения документировать,но важнее всего — описывать причины, по которым это решение принимается. Иначе велика вероятность,что потом вы не вспомните,почему какая‑то фича работает именно таким образом.
Переработка архитектуры и развязывание сущностей помогло нам немного сбросить эту нагрузку,но перерабатывать архитектуру — трудно,больно и затратно. По возможности контролируйте это с самого начала.
Проблема 7. Собственно запуск
В итеративной разработке релиз — это вполне обыденное дело. Сделали,зарелизили,работаем дальше.
В закрытой разработке релиз — это веха. Жизнь делится на до и после. После релиза,как правило,работы становится больше.
Если сервисом уже пользовались,и новая версия была в закрытой разработке,то бэклог будет расти с такой скоростью,что я бы с удовольствием придумал какое‑нибудь сравнение,но не буду даже пытаться.
Это может стать стресс‑тестом и для вашего продукта,и для вас. А там — привет,пункт 2 ↑
Итог
Это было трудно. Наверное,это был самый сложный проект и по сложности системы,и по поддержанию ритмичной работы с самодисциплиной.
После релиза стало веселее: появились новые люди в команде,свежий взгляд на сервис и всё такое. Но эти полтора года до — стали очень ценным опытом: многому за это время научился и многое испытал на себе.
Пользователи просили нас добавить в Тяжеловато доллары и евро. Мы знали,что если будем добавлять эти валюты,нам придётся добавить запятую на клавиатуру,чтобы можно было вводить дробные суммы.
Это было технически дорого,поэтому мы долго тянули с обновлением. Но вот наконец‑то оно пришло!
Есть ещё одна новость. Сейчас мы ищем разработчиков,которые нам помогут поддерживать и развивать проект. Первая задача — обновить и почистить кодовую базу в приложении.
В будущем мы хотим внедрить в приложение несколько новых классных штук. Но перед этим хочется привести нынешнюю версию в порядок,чтобы работать было приятнее.
Если вам интересно поучаствовать или вы знаете кого‑то,кто сможет нам помочь,напишите,пожалуйста,на почту bespoyasov@me.com.
Полтора года назад я провёл своё первое занятие в Нетологии. С тех пор я читал лекции,проверял домашние задания,менторил дипломные проекты и даже сам был студентом на одном из курсов. За это время я смог осознать для себя некоторые штуки о процессе обучения,которыми решил поделиться.
Будьте аккуратнее с новыми терминами
Если вы объясняете новичкам незнакомые термины,то это стоит делать понятиями,которые им уже известны. Следовать этому правилу труднее,чем кажется.
При переходе из разработки в преподавание,многое кажется очевидным. Маржины схлопываются,флоты надо сбрасывать,у боди есть отступы по умолчанию. Разработчики к этому настолько привыкают,что перестают замечать.
Но как только вы начнёте объяснять это другим людям,у них вполне оправданно появится куча вопросов. Что за маржины,что значит«схлопываются», как сбрасывать флоты,зачем они нужны,откуда отступы,зачем они там?
Чтобы объяснить эти тонкости,надо использовать уже знакомые понятия. Потому что иначе вы не только не объясните,что хотели,но и отобьёте интерес к теме. Никому не хочется разбираться в непонятной фигне,по крайней мере — в чересчур непонятной.
Поэтому объяснение нового термина должно:
состоять из уже известных понятий;
быть последовательным,строиться от целого к частному либо наоборот.
Избегайте путаницы
Если у термина есть синонимы(флот ⇔ плавающий элемент), надо это пояснить на старте.
Можно также объяснить,почему эти термины взаимозаменяемы.(Флот переводится,как плавающий,а используется такой элемент,чтобы его«обтекал» текст. Поэтому он как бы плавающий,это такой грубый перевод.)
Тем не менее,я стараюсь использовать один термин по ходу объяснения,даже если проговариваю синонимы в начале. Просто чтобы ученику не приходилось лишний раз соотносить новое понятие с ещё одним словом.
Автоматизируйте всё,что можно
Большую часть времени я тратил на ревью решений. В них важно не только рассказать,что неправильно и почему другое решение было бы лучше,но и понять,почему ученик сделал именно такую ошибку.
Часть ошибок — заблуждения,которые возникают при погружении в тему. На такие ошибки стоит заранее приготовить развёрнутое объяснение,почему заблуждение — это именно заблуждение,и как решить задачу было бы правильнее.
Нетипичные ошибки более редкие. Они особенно важны,потому что как бы ставят под вопрос рациональность технологии. На них отвечать надо ещё более полно.
Грамотно объяснить сложные вещи,будучи уставшим,трудно. Именно чтобы не уставать от ответов на типичные ошибки,лучше на них заранее готовить развёрнутый ответ.
Объясняйте на примерах
Объяснение с примерами понятнее. Я пробовал объяснять и абстрактно,и на примерах — на примерах лучше.
Абстракция — ресурсозатратная штука. Даже чтобы представить что‑то уже знакомое,требуется внимание и сосредоточенность. Чтобы представить какое‑то новое понятие,ресурсов потребуется больше.
Примеры будут экономить ученикам внимание и силы. Кроме этого они сильнее связывают новое понятие с каким‑то процессом или образом. И,возможно,как мне кажется,я не уверен,но так ученики лучше запомнят то,о чём вы говорили.
Делайте перерывы во время занятия
Во время объяснений стоит делать небольшие перерывы.
У меня не всегда получается вовремя вспомнить о них,потому что есть ограничение по времени на лекцию. Иногда я просто забываю о них. Но в последнее время стараюсь делать перерывы чаще и спрашиваю,какие есть вопросы.
Ученикам перерыв даёт время передохнуть и восстановить внимание. Вам — перевести дыхание.
Стимулируйте обратную связь
Задавать вопросы страшно и неловко. Но вопросы надо поощрять и стимулировать. Часто перед ответом на вопрос я говорю,что вопрос хороший,логичный или правильный. Не знаю,насколько это снижает страх задавать вопросы,надеюсь,помогает.
Если вопрос задан расплывчато,и вам непонятно,как ответить,просто уточните,что имелось в виду. И,если в чём‑то сомневаетесь,не стесняйтесь гуглить прямо во время занятия. Я так и говорю:«не уверен,давайте прямо сейчас и загуглим».
Пейте воду во время занятия
Мне трудно долго говорить,особенно если приходится следить за таймингом и проговаривать слова быстро и громко. Поэтому я во время лекции иногда отвлекаюсь на глоток воды. Голос не садится к концу,а ещё это помогает сделать вынужденный перерыв.
Пить воду ещё можно,если чувствуете,что плывёте или сильно волнуетесь. Это работает как микротаймаут: пока пьёте воду,можно перевести дух,сформулировать мысль и продолжить.
Дозируйте время на ревью
Любую работу стоит дозировать и разбивать на кусочки. Если два часа подряд ревьюить домашки,то к концу вы будете чувствовать большую усталость,чем если бы чередовали ревью с задачами по другим проектам.
Дело в монотонности,от неё надо избавляться. Чередовать темы,тасовать задачи,менять вид деятельности. Короче,делать всё,чтобы ревью не приедалось. Иначе отвечать свежо не получится и просто пропустить вопрос,на который стоит дать более развёрнутый ответ,или ошибку в решении.
Получайте пользу
Преподавание учит точнее выражать мысли и задумываться об аспектах разработки,о которых раньше вы бы не стали задумываться. Это почти как заново научиться верстать.
Если есть возможность заниматься менторством,то пробуйте. Вы глубже поймёте то,что знаете,научитесь объяснять сложные понятия и сможете помочь кому‑то разобраться с новыми для них вещами.
