Комментарии 29
В статье описана вкусовщина, которую возвели в правило.
Я бы больше сказал: из способов борьбы с тех долгом, которые я видел, правило бойскаута, использованное местным «джуном» работало лучше всего.
Это если бойскауту поставили эту задачу, а если не ставили, то он занимается на работе не тем, что ему поручили. Давно занятие на работе не тем, что поручили стало оплачиваться и поощряться?
Не говоря уже о том, что каждая правка джуном, просто в меру его позиции, должна проверяться миддлом/сеньором перед уходом в прод. То есть 100-500 бойскаутских правок джуна превращаются в недельную занятость миддла/сеньора, при чем заметьте, непредвиденную занятость, т.к. он делает то, что ему никто не поручал и то, что от него никто не ожидал.
Статья правильная так-то, только тянет больше на комментарий, а не на статью. Можно сократить до "джун должен заниматься тем, что ему поручили"©
Джун, который что-то улучшает и рефакторит? Это точно не джун.
А как относится к подобный действиям - вопрос требуемый рассмотрения ситуации, но никак не рассматриваемый в вакууме - это просто узколобо и ничем не отличается от вещания ярлыков.
Есть разработчики которые не могут заниматься поддержкой чужого кода. Им нужно создавать что-то свое, желательно с нуля или на крайний случай рефакторить чужое. С уровнем навыков это никак не связано, момент чисто психологический. Им проще не есть и не спать чтобы всё переделать чем исправить 1 строчку. Скорее даже наоборот, если в позиции джуна они еще готовы мириться с тем что надо делать то что требуется, а не то что хочется, то в роли сеньора остановить их уже не возможно))
Если даже небольшой рефакторинг грозит сломать Ваш код и единственный способ этого избежать это тщательный просмотр лидом знающим все подводные камни, то Вы уже делаете что-то не так, это раз. Подумайте о добавлении автоматических тестов и TDD.
Если Вы не сумели объяснить джуну задачу - что надо делать а что НЕ надо то это изначально Ваша ошибка как менеджера а не проблема джуна, это два. Проявлять инициативу - это нормально для джуна. Обучать джуна тому почему что-то не надо делать - это нормально для лида. Ругать джуна за то что вы его кинули без присмотра и он проявил инициативу - это НЕ нормально.
Более того, джун — это источник проблем просто по определению, на то он и джун. Задача руководителя — эти проблемы отлавливать на взлёте, а не на проде. Наличие в работе джуна очередной проблемы — штатная ситуация.
«Ты вообще-то такие вещи сам знать уже должен» — это претензии к миддлу и выше. Джун ничего не должен ещё.
Магический TDD, никогда его не видел. И не знаю человека, который бы его видел)
В принципе на Хаскеле получается писать соблюдая принцип TDD, хоть и не по форме но по сути. Код самотестируется на этапе тайпчекинга компиляции. Поэтому шутка про то, что Хаскельный код можно даже не запускать, если скомпилился, то работает правильно, это не совсем шутка.
Писал даже, не то что "видел". Непривычно и местами неудобно, но работать работает.
Не использовал каждый раз, поэтому впечатления двоякие, может нужно больше практики.
А вы точно имеете в виду TDD, а не его суррогат в виде Tests First?
Почему суррогат то? У них общая база - тесты вперёд кода.
Пишешь тест, представляя себе апи новой фичи, потом пишешь фичу. Большой разницы не вижу навскидку, тем более что какой-нибудь "сертификации" по TDD не было, делали как умели.
Потому что движение маленькими шажками - один из краеугольных камней TDD. Нельзя писать больше одного теста за раз. Нельзя писать больше кода, чем нужно для прохождения теста. Утверждается, что именно такой подход даёт максимальное покрытие кода тестами.
Ну тут не надо возводить идею в абсолют (как и со всем остальным). Ключевой принцип тут имхо в том что надо убеждаться в том что тест вообще работает. Я не раз видел ситуацию когда тест просто не ловил проблему которую он должен был обнаружить. То есть человек по видимому вначале написал код, затем к нему тест, запустил его - тест зеленый, все значит работает. В реальности же тест просто не работал. Ну а движение маленькими шажками - один из наиболее простых способов добиться того чтобы такая ситуация была невозможной
Такой подход неплохо заходит на небольших задачах (в которых опытный разработчик обычно уверен и даже тесты может не писать, к слову).
А как только фича уровня эпик - от TDD мне лично становилось неудобно. Поэтому и пишу выше - не использовали TDD на каждой задаче. Возможно если использовать совсем всегда, то будут какие то плюсы и хорошие привычки, но я не нашел прямо классных преимуществ у такого подхода.
Большие задачи зачастую распадаются на множество задач поменьше :). Я тоже не везде его использовал, да, но там где применял - он прям очень хорошо работает. Причем кажется поначалу что он замедляет девелопмент, но нет, на дебаге и на рефакторинге экономится время и баш на баш выходит, а код по качеству и покрытию тестами лучше.
Я в целом понимаю о чём речь.
Но подход TDD вроде больше про "сделай просто, потом сделай ещё чуток, продолжай повторяй". И если так делать большую фичу, то у нас в команде не выходило сделать это хорошо. Получалась каша. Но, я честно выше писал - опыт не очень глубокий и полноценный, возможно стоило повторять до успешного результата =)
Очень сложно проводить код-ревью в таких случаях, так как нужно найти именно те изменения, что решают поставленную задачу.
Вот это, пожалуй, единственное, что герой сделал не так. Изменения "по пути" следовало просто вынести в отдельные коммиты. Так проще проводить ревью, и если какой-то из рефакторингов трогает то, что трогать не надо, то коммит просто дропается, а джун с этого момента знает кодовую базу чуть лучше.
А инициативу, как правило, перестают проявлять буквально после первой подобной претензии и на все время работы, поэтому большого ущерба это едва ли нанесет.
...о нет, я уже лет 10 так делаю. FOREVERDJUN!
Ну и если что-то ломается от попутных правок, то тут большой вопрос к качеству изначального кода и к QA. Конечно, если твои попутные правки что-то ломают, это не отменяет твоей персональной ответственности, поэтому всегда надо за собой проверять, и джунов этому надо учить. Ну и проводить/просить ревью обязательно.
Если давать коду зарастать паутиной (а так же копипастой, сомнительной невнятной логикой и артефактами времён стартапа) - дальше будет лишь сложнее это понять, читать и поддерживать, что только увеличит количество багов на проде.
Лучше 1 баг в ровном коде сегодня, чем 10 багов (+выгорание), которые обязательно появятся, в запутанном коде через год, по причине его запутанности.
Наверное, единственное, что в этой ситуации джун сделал не так - это предварительное не сказал лиду, что видит косяки и хочет их отрефакторить.
Это сняло бы претензию про «а вдруг этот код срочно ждут на проде» и в целом сделало бы ситуацию более управляемой. Например, лид мог бы предложить разделить фикс и рефакторинг на отдельные коммиты/ветки, или дать совет вида: это правь, а это мы починим через техдолг в следующий спринт.
А в остальном - если даже джун видит в коде косяки, то код почти наверняка лучше поправить, пока копящийся снежный ком из кривого кода не превратил проект в сложноподдерживаемое нечто. Понятно, что ситуации бывают разные, например, если проект доживает последние дни, то заниматься рефакторингом уже не надо, но, на мой взгляд, джуна, который хочет сделать код лучше, надо поощрять, даже если он ошибается по-мелочи, а не ругать.
Ранний рефакторинг это не трата времени сейчас - это экономия времени в будущем на поддержку. Поэтому если вы по факту задачи исправите какой то кусок кода, то в следующие разы уже будет легче этот код поддерживать и поэтому время будет экономиться
А почему в комментариях все джун, да джун? В первом абзаце автор пишет, что хочет описать некие признаки, по его мнению, присущие джунам, дальше пишет о том, чем джун заниматься не будет - тем же рефакторингом.
У меня сложилось впечатление, что взяли мидла, или сеньера, но автору статьи он чем-то сильно не по душе, и на почве душевных терзаний он накатал статью, желая получить одобрение от местной публики и подтверждение того, что он правильно не любит этого нового коллегу.
По мне, так проблема надуманная, в разных коллективах отношение к рефакторингу, и прочим вещам разное, задача онбординга в наиболее дружелюбной форме донести до нового человека практики используемые в коллективе, а не катать статьи на Хабре. :)
ИМХО, одно из основных правил работы в команде - никакой самодеятельности без согласования.
Я видел такое в крупных проектах: "Ты должен решать только свою задачу", "Не лезь чужую зону ответственности", "Тебя об этом думать не просили", "Забыть ты это слово - рефакторинг", "Не трать время на то, о чем тебя не просили", "Если ты это исправишь, ты можешь дать 100% гарантии что ничего не сломается?", "Здесь так не принято", "Это сделали умные люди, ты что, считаешь себе умнее их?" и т.д. (Именно в таких резких выражениях это озвучивается не часто, но посыл такой)
И ничего удивительного что проект через несколько лет развития представляют собой кошмарную архитектурную лапшу и сплошной легаси. Даже у новичков с горящими глазами быстро отбивается желание сделать проект лучше и они начинают просто "закрывать свои задачи".
Конечно, не надо по каждому поводу сразу кидаться в рефакторинг, но такие идеи надо сразу обсуждать. И не выкидывать в бесконечный бэклог-помойку.
К тому же новички могут взглянуть на проект свежим не замыленным взглядом, или принести какие то хорошие решения с предыдущих мест работы. И у них еще не отбито желание сделать что то лучше.
В действительно крупных проектах, где прод запускается сразу на сотни тысяч - сотни миллионов клиентов, такие вещи давно защищаются фиче флагами (feature flags). Развернулась новая версия на проде, но пока работает старый код, ибо ФФ для всех выключен. Включили ФФ на несколько продовых тестовых пользователей (или компаний, или кто кто там потребитель), провели последний раунд тестирования уже на проде, все норм - включаем ФФ, если какие-то багофиксы, или тот-же рефакторинг то прям сраузу для всех. Если что-то большое, то ФФ уже обзывают экспериментом и включают по частям, например, сначала на 100-500 пользователей, через неделю на 1%, потом на 10% и тд. Если что-то пошло не так на любом этапе, всегда можно откатиться или совсем отключить ФФ и за секунды все вернутся к старой версии.
>А быть может эта новая функциональность уже ждет на ПРОДЕ и самодеятельность инженера оттягивает ее сдачу.
Если поручаете критику джуну, то ссзб.
Примета джуна #1 «С шашкой наголо»