Примета джуна #1 «С шашкой наголо»
На фоне вопроса какая разница между джуном и мидлом пришла в голову идея пойти несколько другим путем — описать то, что в моем понимании есть признаки джуна. То есть те вещи, которые характеризуют джуна и могут быть маркерами как для тех, кто оценивает сотрудником так и для тех, кто хотел вырасти из джуна. Чтобы собрать их воедино — добавляю тег #примета_джуна. По нему можно будет все их собрать.
Рассмотрим обычную историю: есть некий проект, который уже вышел в прод. Проект частично можно уже назвать легаси, так как некоторые модули от греха подальше не не лезут ибо «и так рабоает».
На проект берут нового инженера с горящими глазами сделать мир лучше. Ему назначают задачу: нужно добавить еще один атрибут в одну из базовых сущностей.
Задача в общем то не очень сложная, можно сказать даже идеальная для вхождения в проект — потому что придется пройти весь путь от добавления нового поля в таблицу до показа этого поля наружу через РЕСТ АПИ.
И тут в ходе решения этой задачи наш инженер начинает по пути улучшать места рядом с которыми он находится. Небольшой рефакторинг там, небольшой рефакторинг сям. Там импорты поправил в соседнем классе, там удалил неиспользуемый уже долго метод. Создал удобочитаемые переменные вместо каких‑то магических строк захардкодженных внутри.
И казалось бы молодец, ведь проект после этого стал лучше и чище. Или нет?
И вот здесь, прежде чем читать дальше, я предлагаю вам подумать самим. Хорошо ли сделал новый инженер или нет?
Думаю у всех уже было время подумать.
Мой ответ НЕТ, человек не справился со своей задачей. Почему? Потому что вместо того, чтобы сделать только то, что ему говорят, он полез заниматься еще чем‑то. Потратил лишнее время. А быть может эта новая функциональность уже ждет на ПРОДЕ и самодеятельность инженера оттягивает ее сдачу.
Причем скорее всего этот рефакторинг будет носить локальный характер и не решит проблему целостно, а лишь только поверхностно.
Очень сложно проводить код‑ревью в таких случаях, так как нужно найти именно те изменения, что решают поставленную задачу.
Выше я предположил идеальную ситуацию к рассмотрению, что дополнительная активность была по делу и ничего не ломала, а ведь это зачастую не так. А это значит, нужно еще больше тратить время на код‑ревью, чтобы еще понять, что остальные изменения не сломают ничего и мы в следующем релизе не выстрелим себе в ногу на ПРОДе.
А это все значит, что нужно будет проводить более детальную регрессию по тестированию, что опять таки нагружает команду без необходимости.
Даже больше скажу, вполне возможно, что те улучшения не нужны были вовсе. Такое бывает сплошь и рядом. А работа произведена.
Здесь конечно можно сказать, ну ты ж критикуешь, так предложил что можно сделать!
Согласен полностью, такие вещи стоит обсуждать с командой и если в улучшениях есть необходимость, то нужно заводить отдельные задачи для этого и вести их в ракурсе работы с техдолгом.
Оценили техдолг, отсортировали его по приоритетам и берем поэтапно в следующие спринты.
Разумеется коллеги, жду ваше мнение в комментариях)
Комментарии (29)
AlexSteelax
14.10.2023 11:24+7Джун, который что-то улучшает и рефакторит? Это точно не джун.
А как относится к подобный действиям - вопрос требуемый рассмотрения ситуации, но никак не рассматриваемый в вакууме - это просто узколобо и ничем не отличается от вещания ярлыков.
GospodinKolhoznik
14.10.2023 11:24+3Такой джун ещё и архитектуру боевых систем прорабатывает. И денег неплохо получает, но в конвертике. А по документам числится джуном, чтобы у налоговой вопросов не возникало.
mirwide
14.10.2023 11:24+2Есть разработчики которые не могут заниматься поддержкой чужого кода. Им нужно создавать что-то свое, желательно с нуля или на крайний случай рефакторить чужое. С уровнем навыков это никак не связано, момент чисто психологический. Им проще не есть и не спать чтобы всё переделать чем исправить 1 строчку. Скорее даже наоборот, если в позиции джуна они еще готовы мириться с тем что надо делать то что требуется, а не то что хочется, то в роли сеньора остановить их уже не возможно))
0serg
14.10.2023 11:24+10Если даже небольшой рефакторинг грозит сломать Ваш код и единственный способ этого избежать это тщательный просмотр лидом знающим все подводные камни, то Вы уже делаете что-то не так, это раз. Подумайте о добавлении автоматических тестов и TDD.
Если Вы не сумели объяснить джуну задачу - что надо делать а что НЕ надо то это изначально Ваша ошибка как менеджера а не проблема джуна, это два. Проявлять инициативу - это нормально для джуна. Обучать джуна тому почему что-то не надо делать - это нормально для лида. Ругать джуна за то что вы его кинули без присмотра и он проявил инициативу - это НЕ нормально.
olartamonov
14.10.2023 11:24-1Более того, джун — это источник проблем просто по определению, на то он и джун. Задача руководителя — эти проблемы отлавливать на взлёте, а не на проде. Наличие в работе джуна очередной проблемы — штатная ситуация.
«Ты вообще-то такие вещи сам знать уже должен» — это претензии к миддлу и выше. Джун ничего не должен ещё.
Grodastr
14.10.2023 11:24Расскажи это рекрутерам, которые пишут про опыт работы в 2 года на микросервисах в джуновских вакансиях.
Минимум что видел - пол года в коммерческой разработки.
dididididi
14.10.2023 11:24+1Магический TDD, никогда его не видел. И не знаю человека, который бы его видел)
GospodinKolhoznik
14.10.2023 11:24В принципе на Хаскеле получается писать соблюдая принцип TDD, хоть и не по форме но по сути. Код самотестируется на этапе тайпчекинга компиляции. Поэтому шутка про то, что Хаскельный код можно даже не запускать, если скомпилился, то работает правильно, это не совсем шутка.
MonkAlex
14.10.2023 11:24Писал даже, не то что "видел". Непривычно и местами неудобно, но работать работает.
Не использовал каждый раз, поэтому впечатления двоякие, может нужно больше практики.
DistortNeo
14.10.2023 11:24А вы точно имеете в виду TDD, а не его суррогат в виде Tests First?
MonkAlex
14.10.2023 11:24+1Почему суррогат то? У них общая база - тесты вперёд кода.
Пишешь тест, представляя себе апи новой фичи, потом пишешь фичу. Большой разницы не вижу навскидку, тем более что какой-нибудь "сертификации" по TDD не было, делали как умели.
DistortNeo
14.10.2023 11:24Потому что движение маленькими шажками - один из краеугольных камней TDD. Нельзя писать больше одного теста за раз. Нельзя писать больше кода, чем нужно для прохождения теста. Утверждается, что именно такой подход даёт максимальное покрытие кода тестами.
0serg
14.10.2023 11:24Ну тут не надо возводить идею в абсолют (как и со всем остальным). Ключевой принцип тут имхо в том что надо убеждаться в том что тест вообще работает. Я не раз видел ситуацию когда тест просто не ловил проблему которую он должен был обнаружить. То есть человек по видимому вначале написал код, затем к нему тест, запустил его - тест зеленый, все значит работает. В реальности же тест просто не работал. Ну а движение маленькими шажками - один из наиболее простых способов добиться того чтобы такая ситуация была невозможной
MonkAlex
14.10.2023 11:24Такой подход неплохо заходит на небольших задачах (в которых опытный разработчик обычно уверен и даже тесты может не писать, к слову).
А как только фича уровня эпик - от TDD мне лично становилось неудобно. Поэтому и пишу выше - не использовали TDD на каждой задаче. Возможно если использовать совсем всегда, то будут какие то плюсы и хорошие привычки, но я не нашел прямо классных преимуществ у такого подхода.
0serg
14.10.2023 11:24Большие задачи зачастую распадаются на множество задач поменьше :). Я тоже не везде его использовал, да, но там где применял - он прям очень хорошо работает. Причем кажется поначалу что он замедляет девелопмент, но нет, на дебаге и на рефакторинге экономится время и баш на баш выходит, а код по качеству и покрытию тестами лучше.
MonkAlex
14.10.2023 11:24Я в целом понимаю о чём речь.
Но подход TDD вроде больше про "сделай просто, потом сделай ещё чуток, продолжай повторяй". И если так делать большую фичу, то у нас в команде не выходило сделать это хорошо. Получалась каша. Но, я честно выше писал - опыт не очень глубокий и полноценный, возможно стоило повторять до успешного результата =)
9982th
14.10.2023 11:24+4Очень сложно проводить код-ревью в таких случаях, так как нужно найти именно те изменения, что решают поставленную задачу.
Вот это, пожалуй, единственное, что герой сделал не так. Изменения "по пути" следовало просто вынести в отдельные коммиты. Так проще проводить ревью, и если какой-то из рефакторингов трогает то, что трогать не надо, то коммит просто дропается, а джун с этого момента знает кодовую базу чуть лучше.
А инициативу, как правило, перестают проявлять буквально после первой подобной претензии и на все время работы, поэтому большого ущерба это едва ли нанесет.
Lomserman
14.10.2023 11:24+2...о нет, я уже лет 10 так делаю. FOREVERDJUN!
Ну и если что-то ломается от попутных правок, то тут большой вопрос к качеству изначального кода и к QA. Конечно, если твои попутные правки что-то ломают, это не отменяет твоей персональной ответственности, поэтому всегда надо за собой проверять, и джунов этому надо учить. Ну и проводить/просить ревью обязательно.
Если давать коду зарастать паутиной (а так же копипастой, сомнительной невнятной логикой и артефактами времён стартапа) - дальше будет лишь сложнее это понять, читать и поддерживать, что только увеличит количество багов на проде.
Лучше 1 баг в ровном коде сегодня, чем 10 багов (+выгорание), которые обязательно появятся, в запутанном коде через год, по причине его запутанности.
alexander_kuznetsov
14.10.2023 11:24+4Наверное, единственное, что в этой ситуации джун сделал не так - это предварительное не сказал лиду, что видит косяки и хочет их отрефакторить.
Это сняло бы претензию про «а вдруг этот код срочно ждут на проде» и в целом сделало бы ситуацию более управляемой. Например, лид мог бы предложить разделить фикс и рефакторинг на отдельные коммиты/ветки, или дать совет вида: это правь, а это мы починим через техдолг в следующий спринт.
А в остальном - если даже джун видит в коде косяки, то код почти наверняка лучше поправить, пока копящийся снежный ком из кривого кода не превратил проект в сложноподдерживаемое нечто. Понятно, что ситуации бывают разные, например, если проект доживает последние дни, то заниматься рефакторингом уже не надо, но, на мой взгляд, джуна, который хочет сделать код лучше, надо поощрять, даже если он ошибается по-мелочи, а не ругать.
elzahaggard13
14.10.2023 11:24Ранний рефакторинг это не трата времени сейчас - это экономия времени в будущем на поддержку. Поэтому если вы по факту задачи исправите какой то кусок кода, то в следующие разы уже будет легче этот код поддерживать и поэтому время будет экономиться
Politura
14.10.2023 11:24+4А почему в комментариях все джун, да джун? В первом абзаце автор пишет, что хочет описать некие признаки, по его мнению, присущие джунам, дальше пишет о том, чем джун заниматься не будет - тем же рефакторингом.
У меня сложилось впечатление, что взяли мидла, или сеньера, но автору статьи он чем-то сильно не по душе, и на почве душевных терзаний он накатал статью, желая получить одобрение от местной публики и подтверждение того, что он правильно не любит этого нового коллегу.
По мне, так проблема надуманная, в разных коллективах отношение к рефакторингу, и прочим вещам разное, задача онбординга в наиболее дружелюбной форме донести до нового человека практики используемые в коллективе, а не катать статьи на Хабре. :)
Ant80
14.10.2023 11:24ИМХО, одно из основных правил работы в команде - никакой самодеятельности без согласования.
tushev
14.10.2023 11:24+2Я видел такое в крупных проектах: "Ты должен решать только свою задачу", "Не лезь чужую зону ответственности", "Тебя об этом думать не просили", "Забыть ты это слово - рефакторинг", "Не трать время на то, о чем тебя не просили", "Если ты это исправишь, ты можешь дать 100% гарантии что ничего не сломается?", "Здесь так не принято", "Это сделали умные люди, ты что, считаешь себе умнее их?" и т.д. (Именно в таких резких выражениях это озвучивается не часто, но посыл такой)
И ничего удивительного что проект через несколько лет развития представляют собой кошмарную архитектурную лапшу и сплошной легаси. Даже у новичков с горящими глазами быстро отбивается желание сделать проект лучше и они начинают просто "закрывать свои задачи".Конечно, не надо по каждому поводу сразу кидаться в рефакторинг, но такие идеи надо сразу обсуждать. И не выкидывать в бесконечный бэклог-помойку.
К тому же новички могут взглянуть на проект свежим не замыленным взглядом, или принести какие то хорошие решения с предыдущих мест работы. И у них еще не отбито желание сделать что то лучше.
Politura
14.10.2023 11:24В действительно крупных проектах, где прод запускается сразу на сотни тысяч - сотни миллионов клиентов, такие вещи давно защищаются фиче флагами (feature flags). Развернулась новая версия на проде, но пока работает старый код, ибо ФФ для всех выключен. Включили ФФ на несколько продовых тестовых пользователей (или компаний, или кто кто там потребитель), провели последний раунд тестирования уже на проде, все норм - включаем ФФ, если какие-то багофиксы, или тот-же рефакторинг то прям сраузу для всех. Если что-то большое, то ФФ уже обзывают экспериментом и включают по частям, например, сначала на 100-500 пользователей, через неделю на 1%, потом на 10% и тд. Если что-то пошло не так на любом этапе, всегда можно откатиться или совсем отключить ФФ и за секунды все вернутся к старой версии.
Aykeye
14.10.2023 11:24>А быть может эта новая функциональность уже ждет на ПРОДЕ и самодеятельность инженера оттягивает ее сдачу.
Если поручаете критику джуну, то ссзб.
f_s_b_37
В статье описана вкусовщина, которую возвели в правило.
Я бы больше сказал: из способов борьбы с тех долгом, которые я видел, правило бойскаута, использованное местным «джуном» работало лучше всего.
edogs
Это если бойскауту поставили эту задачу, а если не ставили, то он занимается на работе не тем, что ему поручили. Давно занятие на работе не тем, что поручили стало оплачиваться и поощряться?
Не говоря уже о том, что каждая правка джуном, просто в меру его позиции, должна проверяться миддлом/сеньором перед уходом в прод. То есть 100-500 бойскаутских правок джуна превращаются в недельную занятость миддла/сеньора, при чем заметьте, непредвиденную занятость, т.к. он делает то, что ему никто не поручал и то, что от него никто не ожидал.
Статья правильная так-то, только тянет больше на комментарий, а не на статью. Можно сократить до "джун должен заниматься тем, что ему поручили"©
esselesse
правило бойскаута - это парадигма программирования, можно сказать, а не конкретная задача
edogs
Так эта парадигма как раз состоит в том, что бы выходить за рамки конкретной задачи. Что позволено, ну, начиная от миддла вкатившегося в компанию скажем, но никак не для только нанятого джуна.