Ответ
Я восприму это как возможность улучшить проект и свой профессиональный опыт. Мои действия будут следующими:
-
Уточнение задачи: Я попрошу тимлида детализировать запрос. Что именно не так? Какие цели должны быть достигнуты после переделки (производительность, читаемость, соответствие архитектуре, устранение бага)? Пример вопроса: "Вы хотите, чтобы мы оптимизировали время ответа этого API с 200мс до 50мс, или главная цель — сделать код более поддерживаемым для новой команды?"
-
Анализ текущего кода: Я самостоятельно изучу проблемный модуль, чтобы понять его текущую логику, связи и потенциальные узкие места. Часто это помогает предложить более осмысленные варианты решений.
-
Предложение плана: На основе анализа я подготовлю 1-2 варианта решения (например, "Мы можем сделать полный рефакторинг с разделением на классы A, B, C, что займёт 3 дня, или можем быстро исправить критическую часть X за 1 день"). Обсуждение плана помогает убедиться, что мы с тимлидом на одной волне.
-
Реализация: После согласования подхода я действую системно:
- Пишу тесты: Если их нет, в первую очередь покрываю существующую функциональность тестами. Это страховка от регрессии.
- Декомпозирую задачу: Разбиваю большую переделку на мелкие, логические коммиты.
- Рефакторю итеративно: Вношу изменения небольшими шагами, постоянно запуская тесты.
- Документирую ключевые решения: Кратко комментирую в коде или PR, почему была выбрана та или иная структура.
-
Запрос обратной связи: После завершения работы я обязательно запрашиваю код-ревью не только у тимлида, но и у коллег. Это помогает выловить ошибки и делиться знаниями о новых подходах внутри команды.
Мой фокус — не просто слепо выполнить указание, а понять корневую причину, предложить эффективное решение и в процессе сделать кодовой базе лучше, сохранив или улучшив её функциональность.
Ответ 18+ 🔞
Слушай, история-то знакомая, просто пиздец. Ты приходишь, такой весь в белом, с горящими глазами, а тебе говорят: «Всё, что ты написал, — говно, переделывай». И волнение ебать, и терпения ноль ебать. Первая мысль — «какого хуя?». Но надо брать себя в руки, а то сейчас начнёшь материться и ничего не сделаешь.
Вот мой план действий, проверенный не раз, когда накрываешься таким медным тазом.
-
Уточнить, что за пизда с ушами. Нельзя просто взять и переписать. Надо понять, что конкретно не так. Я подойду и спрошу: «Слушай, а что именно не устраивает? Это жрёт овердохуища памяти, тормозит как черепаха в сиропе, или код выглядит так, будто его писал мартышлюшка после трёх бутылок портвейна?». Нужна конкретная цель: «Сделай так, чтобы этот запрос летал за 50 мс» или «Разбери эту сраку, чтобы новый чувак через полгода не плакал».
-
Самому вникнуть в эту кашу. Прежде чем что-то ломать, надо понять, как это говно вообще работает. Открываю модуль, смотрю связи, логику. Иногда в процессе находишь, что проблема не там, где все думают. А иногда понимаешь, что тимлид прав, и тут действительно пиздопроебибна архитектура.
-
Предложить не один, а пару вариантов. Нельзя просто сказать «окей». Надо показать, что ты думаешь. Например: «Вариант А — полный рефакторинг на три новых класса, займёт три дня, но будет чисто. Вариант Б — костыль на скорую руку, который залатает дыру за полдня, но потом всё равно придётся переделывать». Пусть выбор делает тот, кто платит за электричество.
-
Взять и сделать, но с умом. Тут главное — не накосячить ещё сильнее.
- Сначала тесты, ёпта! Если их нет — пишу. Это как страховой полис от того, чтобы после моих правок всё не разъехалось к хуям.
- Ломать — не строить. Не пытаюсь переписать всё за один присест. Делаю маленькие, осмысленные коммиты. Поправил одну функцию — проверил, что всё работает. Перетащил логику в другой класс — снова проверил.
- Комментирую неочевидные моменты. Пишу в коде или в пул-реквесте, почему сделал именно так. Чтобы через месяц не орать «какой пидарас шерстяной это написал?», а вспомнить, что это был я, и были веские причины.
-
Не стесняться просить посмотреть. Как сделал — вываливаю на всех. «Эй, народ, гляньте, не насрал ли я мимо?». Код-ревью от коллег — это святое. Они могут заметить то, до чего сам не допёр.
Суть в чём? Не надо воспринимать это как личное оскорбление или тупое указание. Это шанс разобраться в корне проблемы, предложить нормальное решение и в итоге оставить код в лучшем состоянии, чем он был. Чтобы не было стыдно. А если будет стыдно — значит, где-то проебали.
