Привет! На связи Митя Кожевников и Юра Соколов из Mindbox. В этой статье мы делимся внутренним гайдом, как джунам нарастить софскилы, быстрее закрепиться в команде и вырасти. Эта часть посвящена пользе.
О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах.
Некоторые советы могут звучать очевидно: например, у нас есть пункт «сначала разобраться в задаче» — понятно, что никто не бросится писать код, не понимая, какой результат нужен. Но часто именно таких простых советов тяжело придерживаться. Поэтому в статье мы «приземлили» их реальными историями, чтобы читатель мог узнать ситуацию, если столкнется с ней сам, и применить наш гайд.
Кому читать. Этот гайд — для джунов, которые хотят сделать софты своим конкурентным преимуществом. Если джун ответственно выполняет работу, умеет самостоятельно обучаться и не проходит мимо говна, его готовы оторвать с руками, даже если ему не хватает знаний. К тому же советы из этого гайда помогут быстрее закрепиться в команде и вырасти. Пользуйтесь!
Пара слов об авторах
Митя Кожевников — senior engineering manager, отвечает за достижения трех команд разработки, 70+ человек под руководством. В Mindbox с 2017 года, за год дорос до мидла и постепенно переключился на тимлидство: занялся обучением новичков, руководством стажерами.
Юра Соколов — senior software engineer. В 2019 закончил стажировку в Mindbox, за год вырос из джуна в мидла, через еще два — дорос до синьора.
Совет 1. Сначала разобраться в задаче — потом делать
Часто джуны — самые заряженные ребята в команде. Они берут много задач и рвутся быстрее писать код.
Юра Соколов
Помню это состояние, когда хочется доказать, что меня взяли не зря. Я представлял, как поражу всех: утром получил задачу, а в обед уже принес результат. К сожалению, это рвение больше вредило, чем помогало — есть одна история, которая это хорошо иллюстрирует.
После стажировки я вошел в команду, которая разрабатывает блоки рекомендаций — подборки товаров, которые могут заинтересовать пользователя. Моя первая задача была связана с рассылками: нужно было поправить правила вывода рекомендаций в письмах. Хотя я еще не был погружен в кодовую базу, технологии были мне знакомы, так что я взялся за дело с уверенностью.
Мне нужно было работать на верхнем уровне — в коде рекомендаций в рассылках. Я ни с кем не посоветовался и залез в ядро — основной код рассылок. Я так хотел сделать задачу как можно быстрее, что забыл обо всех хороших практиках.
О своей ошибке я узнал только на ревью, когда уже потратил кучу лишнего времени. Этот случай запомнился надолго — после него всегда проговаривал решение, которое хочу воплотить.
Чтобы понять, чего от вас ждет человек, поставивший задачу, полезно сделать несколько шагов:
1. Узнать, кто заказчик. Можно спросить в команде — в чате или на дейлике, — кто и как будет принимать задачу. В идеале найти всех, кто заинтересован в результате — это может быть один или несколько человек, а может — целый отдел.
Например, нужно добавить сортировку в список — заказчиком выступает продакт. Он будет оценивать, решили ли задачу клиента. Или задача — расширить мониторинг для нового сервиса. В этом случае заказчик — архитектор, который понимает, какие проблемы должен обнаруживать мониторинг.
2. Уточнить все неясные моменты. Часто кажется, что вопрос глупый, неуместный и только тормозит процесс. В такие моменты стоит напомнить себе, что для команды ответить даже на глупый вопрос в разы дешевле, чем исправлять код неправильно понятой задачи.
Если вопрос нужно задать занятому коллеге, можно выделить час–два на поиск решения и потом провалидировать его. Коллеге будет проще оценить готовое решение, чем объяснять его с нуля.
3. Записать или проговорить результат. Например: «В этой задаче нужно научиться обнаруживать зависшие отчеты. Я изучу доступные метрики, выведу нужную в графану и настрою по ней алерт. Я правильно понял? Ничего не упустил?»
Обычно, в этот момент обнаруживаются все недопонимания и детали, которые джун может не знать. Например, к решению выше опытный разработчик добавил бы: «Все так, но, когда будешь выбирать порог срабатывания алерта, посоветуйся со мной. А еще обязательно нужен ранбук — как дежурному разработчику реагировать на него. Плюс подумай, как будешь проверять работу алерта: сейчас активных проблем нет, скорее всего, придется эмулировать условия для его срабатывания».
Даже пройдя эти шаги, садиться кодить еще рано — нужно спроектировать решение.
Совет 2. Проектировать с конца
Когда есть понимание, к какому результату нужно прийти, можно по цепочке определить, какие действия приведут к этому результату. Причем двигаться лучше из конца в начало. С этим помогает вопрос: «Что для этого понадобится?»
Например, надо изменить отображение заказов, но так, чтобы не пропал доступ к админке админки (не случился даунтайм). Значит, нужна двухфазная миграция фронтенда и бэкенда, поскольку мы меняем контракт обоих сервисов. А перед сложной миграцией хорошо бы еще проверить, что новая форма заказа действительно решает задачи пользователя, например, «пощупав» ее вместе с продактом в админке на локальной машине.
После этой работы получится «план на салфетке»: производственный цикл в виде понятных шагов. Этот план стоит показать ведущему, заказчику или команде, чтобы провалидировать решение. Нормально, если показывать черновик — стыдно. Если не стыдно, то, скорее всего, уже слишком поздно.
Проектирование с конца полезно при контрактах между сервисами и рефакторингом, потому что помогает на старте определиться, какой контракт нужен между сервисами и как должен выглядеть код после рефакторинга.
Юра Соколов
В моей команде нужно было отрефакторить монолит: уменьшить объем шаблонного и дублирующего кода. На этом участке — несколько десятков алгоритмов, и было важно сохранить гибкость их настроек.
Задачу взял джун. Видимо, он не понял, какого результата ждет команда, поэтому спроектировал решение по своему усмотрению, не согласовал и приступил к работе.
Первый же пуллреквест, который он отправил на ревью, затрагивал большую группу алгоритмов и не предусматривал гибкую настройку. Коллеги посоветовали пойти другим путем и рефакторить алгоритмы по одному: так на ревью сможем договориться, как должен выглядеть код, и поменять его везде.
Джун начал по новой и на этот раз пошел через проектирование с конца. На уровне псевдокода он изобразил, как должен выглядеть код после рефакторинга, согласовал с командой и приступил к работе. Код, который он принес на ревью, решал задачу, и результат быстро приняли.
Митя Кожевников
Недавно перед парой наших джунов стояла задача переделать большой нагруженный кусок кода, поскольку:
Код не работал у нескольких клиентов. Нужно было воспроизвести способы оптимизации из другого похожего кода, в котором применили более производительный подход.
Код был путаным и сложным в поддержке. При рефакторинге нужно было упростить его.
Изначальный план ребят выглядел так:
Переписываем код.
Переписываем тесты.
Проверяем на клиенте, как работает решение.
План простой, но в нем два больших изъяна:
Проверить, что гипотезы по оптимизации работают, получится только после значительных инвестиций.
Нет гарантий, что после переписывания код станет читабельнее или хотя бы сохранит работоспособность.
Я предложил перевернуть план работы и сделать все в обратном порядке.
Проверяем гипотезы по оптимизации на выбранном клиенте (для этого у нас есть механизм feature-toggle). Если они подтверждаются, проблемы решены — остается разобраться только с читабельностью кода. Если не срабатывают, мы узнаем об этом в самом начале и не инвестируем в читабельность нерабочего кода.
Фиксируем ожидаемое поведение в новых тестах. Этого не сделать без бизнес-аналитика.
Переписываем код, постепенно «озеленяя» новые тесты, которые теперь еще и помогают сохранять читабельность кода (подробнее об этом можно прочитать в Test-Driven Development Кента Бека)
Совет 3. Вскрыть риски на старте
Если в задаче что-то кажется сложным или непонятным, есть соблазн начать с простого, а потом разобраться по ходу работы. Но действовать лучше наоборот: чем раньше вскроются риски, тем меньше шансов совершить ошибку, которую сложно и дорого исправлять.
Юра Соколов
У моей команды была задача — уменьшить размер данных в хранилище аналитики и отчетности продукта. Хранилище состоит из множества таблиц, часть из которых содержали избыточную информацию.
Задача несложная, ведь другая команда уже делала подобное в похожей системе. Единственный нюанс — та система была в разы меньше нашей. Но мы забили на это и не стали тестировать алгоритм на больших таблицах — это нас и подвело.
Когда запустили алгоритм, обнаружилось много подводных камней, и задача, на которую отводили 2 недели, растянулась на 2 месяца.
Митя Кожевников
Эта история произошла, когда я только начинал работать в Mindbox.
У нас есть конструктор операций — клиент собирает API, которое при вызове выполняет заданную работу, например, меняет информацию в профиле клиента. В этом конструкторе нужно было добавить галочку «Выбрать все поля».
Я предположил, что нет ничего сложного в том, чтобы добавить в верстку простенький стандартный компонент. Поэтому отложил фронт на потом, сначала реализовал весь функционал на бэке.
Как раз на фронте обнаружились проблемы. Оказалось, что существующая архитектура не позволяет добавить поведение, при котором состояние галочки влияет на другие компоненты. Я потратил больше недели, пытаясь красиво и правильно реализовать задуманное, но в итоге всё равно пришел за помощью к более опытному во фронтенде коллеге.
А если бы я сразу реализовал основной пользовательский сценарий вместе с фронтом, то в первый же день столкнулся бы с этой проблемой. А во второй — уже получил бы совет, в какую сторону думать.
Чтобы раньше вскрыть риски, полезно как можно быстрее получить фидбек от команды или увидеть, как решение работает в проде. В этом помогут несколько привычек:
Пуллреквесты по 300 строк. Такой объем проще ревьюить, а, если в решении ошибка, исправить ее легче.
Фиксировать задачу в описании. Ревьюеру должно быть очевидно, для чего этот код.
Каждый пуллреквест — законченное самостоятельное решение. В нем не должно быть кода «про запас» или «на будущее».
Оформление кода и рефакторинг — в отдельные пуллреквесты.
Если есть сомнения — показать незаконченный пуллреквест. При этом важно предупредить ревьюера, что это черновик и смотреть нужно на логику решения, а не чистоту кода.
Замечания по пуллреквесту вносить как можно раньше — желательно в первые полчаса. Так выше шанс получить повторное ревью сразу.
Спорные и непонятные моменты выяснять голосом или в мессенджере, в котором общается команда. Обычно переписка в GitHub идет медленно, поэтому проще вынести обсуждение в удобное пространство, а в GitHub зафиксировать принятые решения, чтобы можно было проследить историю.
Еще один вариант быстрее получать фидбек — работа в паре. Так можно получать замечания и исправлять их по ходу решения задачи — не дожидаясь ее завершения и ревью от коллег.
Чек-лист, чтобы приступить к задаче
Чтобы качественно выполнить задачу, перед началом работы ответьте на вопросы:
Кто и как будет принимать задачу? Кто заинтересован в результате?
Какую проблему я должен решить?
Какие вопросы по задаче остаются? Что я могу сделать самостоятельно, чтобы найти ответ? К кому обратиться за советом?
Как должен выглядеть результат? Согласовали ли его заказчики задачи?
Какая цепочка действий приведет к результату? Что сказали о ней ведущий, заказчик или команда?
Какие задачи в плане вызывают сомнения? Как минимизировать риск ошибки?
Как быстрее получить фидбек от заказчика или команды?
Бонус: что почитать, чтобы прокачать софтскилы
В качестве дополнения к статье советуем:
«The Clean Coder: A Code of Conduct for Professional Programmers» Р. Мартина. Здесь вы найдете практические советы развития софт-скилов: как разработчику общаться с коллегами, подходить к оценке проекта, написанию кода, рефакторингу и тестированию.
«The Pragmatic Programmer, 20th Anniversary Edition» Д. Томаса и А. Ханта. Здесь множество советов с примерами про то, как писать код, общаться с командой и подходить к решению задач.
Это статья в трех частях. Вы прочитали первую. Вторую можете прочитать в блоге Mindbox. Третья появятся позднее