Примета джуна #1 "С шашкой наголо"

Примета джуна #1 "С шашкой наголо" На фоне вопроса какая разница между джуном и мидлом пришла в голову идея пойти несколько другим путем - описать то, что в моем понимании есть признаки джуна. То есть те вещи, которые характеризуют джуна и могут быть маркерами как для тех, кто оценивает сотрудником так и для тех, кто хотел вырасти из джуна. Чтобы собрать их воедино - добавляю тег #примета_джуна. По нему можно будет все их собрать. Рассмотрим обычную историю: есть некий проект, который уже вышел в прод. Проект частично можно уже назвать легаси, так как некоторые модули от греха подальше не не лезут ибо "и так рабоает". На проект берут нового инженера с горящими глазами сделать мир лучше. Ему назначают задачу: нужно добавить еще один атрибут в одну из базовых сущностей. Задача в общем то не очень сложная, можно сказать даже идеальная для вхождения в проект - потому что придется пройти весь путь от добавления нового поля в таблицу до показа этого поля наружу через РЕСТ АПИ. И тут в ходе решения этой задачи наш инженер начинает по пути улучшать места рядом с которыми он находится. Небольшой рефакторинг там, небольшой рефакторинг сям. Там импорты поправил в соседнем классе, там удалил неиспользуемый уже долго метод. Создал удобочитаемые переменные вместо каких-то магических строк захардкодженных внутри. И казалось бы молодец, ведь проект после этого стал лучше и чище. Или нет? И вот здесь, прежде чем читать дальше, я предлагаю вам подумать самим. Хорошо ли сделал новый инженер или нет? .... .... Думаю у всех уже было время подумать. Мой ответ НЕТ, человек не справился со своей задачей. Почему? Потому что вместо того, чтобы сделать только то, что ему говорят, он полез заниматься еще чем-то. Потратил лишнее время. А быть может эта новая функциональность уже ждет на ПРОДЕ и самодеятельность инженера оттягивает ее сдачу. Причем скорее всего этот рефакторинг будет носить локальный характер и не решит проблему целостно, а лишь только поверхностно. Очень сложно проводить код-ревью в таких случаях, так как нужно найти именно те изменения, что решают поставленную задачу. Выше я предположил идеальную ситуацию к рассмотрению, что дополнительная активность была по делу и ничего не ломала, а ведь это зачастую не так. А это значит, нужно еще больше тратить время на код-ревью, чтобы еще понять, что остальные изменения не сломают ничего и мы в следующем релизе не выстрелим себе в ногу на ПРОДе. А это все значит, что нужно будет проводить более детальную регрессию по тестированию, что опять таки нагружает команду без необходимости. Даже больше скажу, вполне возможно, что те улучшения не нужны были вовсе. Такое бывает сплошь и рядом. А работа произведена. Здесь конечно можно сказать, ну ты ж критикуешь, так предложил что можно сделать! Согласен полностью, такие вещи стоит обсуждать с командой и если в улучшениях есть необходимость, то нужно заводить отдельные задачи для этого и вести их в ракурсе работы с техдолгом. Оценили техдолг, отсортировали его по приоритетам и берем поэтапно в следующие спринты. Разумеется коллеги, жду ваше мнение в комментариях) Джавист Роман | Подписаться (https://t.me/romankh3)