Здравствуйте, Igore, Вы писали:

I>Здравствуйте, Aleksei_Lekomtsev, Вы писали:

A_L>>Часто бывают спорные ситуации во время code review. Это либо опыт у людей разный, либо дело вкуса, какие-то "холиварные" темы
A_L>>Например, писать/не писать комментарии,
I>Если я прошу написать комментарий значит или мне не очевидно зачем этот код нужен или что он делает(надо написать), или по стилю кодирования у нас тут должен быть комментарий, даже если он очевидный из разряда // Запрос ФИО
A_L>>название переменных,
I>Должно быть по стилю кодирования
A_L>>использовать/не использовать var и т.д..
A_L>>Список можно продолжать до бесконечности
I>Максимально вынести в стиль кодирования, желательно с обоснованием

A_L>>Это те моменты, которые никак качественно не влияют на работу приложения. Т.е. например, это не о том как код используется больше/меньше ресурсов
A_L>>Team leader проверяет, вносит свои правки, а у автора кода другое мнение как лучше для проекта
I>То что ты описал это чисто стиль кодирования, он составляется с участниками команды и потом все его придерживаются, после того как попишешь в разных стилях, просто будешь принимать то как исторически сложилось в проекте

A_L>>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
A_L>>Обратиться к кому-то "выше" за разъяснениями нет возможности
I>1) Есть ли общий стиль кодирования? Если нет, предложи сделать его, и вынести его для обсуждения всей командой
I>2) После стиля добавить линтер который будет поддерживать стиль
I>3) Если код не по стилю, сборка не должна собираться, в идеале настроить чтобы у всех был локальный прогон перед пушем в репозиторий.
I>Вот после этого скорей всего будут замечания по существу, из не знаю, в начале функции сначала сделай обработку граничных условий, а только потом логику, шум из того что ты описал должен уйти.

Не всегда руководство принимает предложения по улучшению продукта. Например, сотрудник предлагает исходя из опыта как можно улучшить. Руководтсво формально соглашается, но в работу это не идет

Здравствуйте, Igore, Вы писали:

I>Здравствуйте, Aleksei_Lekomtsev, Вы писали:

A_L>>Часто бывают спорные ситуации во время code review. Это либо опыт у людей разный, либо дело вкуса, какие-то "холиварные" темы
A_L>>Например, писать/не писать комментарии,
I>Если я прошу написать комментарий значит или мне не очевидно зачем этот код нужен или что он делает(надо написать), или по стилю кодирования у нас тут должен быть комментарий, даже если он очевидный из разряда // Запрос ФИО
A_L>>название переменных,
I>Должно быть по стилю кодирования
A_L>>использовать/не использовать var и т.д..
A_L>>Список можно продолжать до бесконечности
I>Максимально вынести в стиль кодирования, желательно с обоснованием

A_L>>Это те моменты, которые никак качественно не влияют на работу приложения. Т.е. например, это не о том как код используется больше/меньше ресурсов
A_L>>Team leader проверяет, вносит свои правки, а у автора кода другое мнение как лучше для проекта
I>То что ты описал это чисто стиль кодирования, он составляется с участниками команды и потом все его придерживаются, после того как попишешь в разных стилях, просто будешь принимать то как исторически сложилось в проекте

A_L>>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
A_L>>Обратиться к кому-то "выше" за разъяснениями нет возможности
I>1) Есть ли общий стиль кодирования? Если нет, предложи сделать его, и вынести его для обсуждения всей командой
I>2) После стиля добавить линтер который будет поддерживать стиль
I>3) Если код не по стилю, сборка не должна собираться, в идеале настроить чтобы у всех был локальный прогон перед пушем в репозиторий.
I>Вот после этого скорей всего будут замечания по существу, из не знаю, в начале функции сначала сделай обработку граничных условий, а только потом логику, шум из того что ты описал должен уйти.

Не всегда руководство принимает предложения по улучшению продукта. Например, сотрудник предлагает исходя из опыта как можно улучшить. Руководство формально соглашается, но в работу это не идет