Try again…

Бывает такая ситуация на ревью, когда замечания критические… вплоть до несогласия с реализованным решением и просьбой найти другой подход. Причины такой реакции могут быть разными, и важно понимать их, чтобы не воспринимать критику в штыки, а использовать для роста.

Почему это происходит?

☝️ Недостаточный опыт и знания разработчика. Этому часто сопутствует боязнь показаться глупым или несостоятельным, если попросить помощи у коллег на берегу. Но парадокс в том, что именно опытные разработчики задают «глупые» вопросы до старта, чтобы не переписывать всё потом. Спросить совета — это проявить заботу о продукте, а не слабость.

☝️ Стремление быстро и поверхностно закрыть задачу. Скорость — главный враг качества. В спешке мы не замечаем неочевидных моментов, идём прямолинейным путём, забывая посмотреть на задачу под другим углом. Если кажется, что на правильное решение нет времени, знай: время на переписывание костылей и ловлю багов обязательно найдётся.

☝️ Слишком сложное, запутанное, неархитектурное решение. Явные неоправданные усложнения и неоптимальные конструкции никуда не годятся. Решение должно быть понятно каждому, кто будет с ним работать в будущем. Неочевидные моменты на ровном месте увеличивают сложность всего проекта и замедляют команду. В долгих и сложных задачах глаз «замыливается», и трудно построить полный путь. Глядя на первую итерацию, коллегам легче подсветить недостатки и предложить более элегантный вариант.

☝️ Внедрение и использование лишних сомнительных зависимостей. Если у вас есть библиотеки или функционал, который нужно допилить или адаптировать, часто лучше сделать это своими силами. Каждая новая зависимость — это не только чужой код, но и потенциальные уязвимости, увеличение размера проекта и необходимость изучения этой библиотеки всей командой. Внедрение лишних зависимостей ради одной операции усложнит проект без весомой причины.

☝️ Код явно плох. Тут может быть много причин: от усталости и перегрузки до банальной несостоятельности в конкретный момент. Причины индивидуальны, и подход к последствиям тоже должен быть гибким. Задача лида или тимлида здесь — понять, что стоит за плохим кодом: перегруз или пробел в знаниях.

Как я к этому пришёл и что помогает сейчас:

В моём пути как разработчика были разные замечания и просьбы переделать решение. И это нормально. Не боги горшки обжигают, и решения сразу не могут быть совершенны. Благодаря компетентным коллегам конструктивная критика способствовала моему росту. Со временем, набирая опыт, я начал действовать на упреждение: строить путь к решению, анализировать альтернативы и только потом приступать к реализации. Но даже сейчас я не гнушаюсь пробовать другие варианты, если с первого раза не получилось взять задачу «с наскока». Иногда полезно вынести подход на обсуждение до того, как написаны тонны кода: набросать архитектуру, показать коллегам, получить апрув на идею. Или сразу открывать черновик пул-реквеста (Draft, WIP), чтобы поймать архитектурные ошибки на раннем этапе.

Будьте внимательны в своих решениях, принимайте советы от коллег. Даже критика бывает полезна, если относиться к ней как к инвестициям в общее качество и свой рост.

#it #lead #mrkrivedko #главноедвигаться #гп

Try again… | Сетка — социальная сеть от hh.ru