Добрый день

Часто бывают спорные ситуации во время code review. Это либо опыт у людей разный, либо дело вкуса, какие-то "холиварные" темы
Например, писать/не писать комментарии, название переменных, использовать/не использовать var и т.д.. Список можно продолжать до бесконечности
Это те моменты, которые никак качественно не влияют на работу приложения. Т.е. например, это не о том как код используется больше/меньше ресурсов

Team leader проверяет, вносит свои правки, а у автора кода другое мнение как лучше для проекта

Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?

Обратиться к кому-то "выше" за разъяснениями нет возможности

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

A_L>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
А зачем тебе отстаивать?

Если ревью от вышестоящего товарища, надо делать как он сказал. Если ревью от коллеги, который придирается по мелочам, тут можно и поспорить. Хотя может быть лучше сделать как он просит и забить, если он не просит чего-то явно плохого и это не отнимет много времени.

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

A_L>Часто бывают спорные ситуации во время code review. Это либо опыт у людей разный, либо дело вкуса, какие-то "холиварные" темы
A_L>Например, писать/не писать комментарии, название переменных, использовать/не использовать var и т.д.. Список можно продолжать до бесконечности
И ровно те, которые описываются code style guides вашего проекта.

A_L>Team leader проверяет, вносит свои правки, а у автора кода другое мнение как лучше для проекта
A_L>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
Договориться, как "правильно", точнее, "как у нас принято" и делать так.

A_L>Обратиться к кому-то "выше" за разъяснениями нет возможности
Зачем вам обращаться к кому-то выше по вопросу, который должна для себя решить ваша команда?

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

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

A_L>>Часто бывают спорные ситуации во время code review. Это либо опыт у людей разный, либо дело вкуса, какие-то "холиварные" темы
A_L>>Например, писать/не писать комментарии, название переменных, использовать/не использовать var и т.д.. Список можно продолжать до бесконечности
_AB>И ровно те, которые описываются code style guides вашего проекта.

A_L>>Team leader проверяет, вносит свои правки, а у автора кода другое мнение как лучше для проекта
A_L>>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
_AB>Договориться, как "правильно", точнее, "как у нас принято" и делать так.

A_L>>Обратиться к кому-то "выше" за разъяснениями нет возможности
_AB>Зачем вам обращаться к кому-то выше по вопросу, который должна для себя решить ваша команда?

> _AB>И ровно те, которые описываются code style guides вашего проекта.
Нет code style guides на проекте

A_L>>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
_AB>Договориться, как "правильно", точнее, "как у нас принято" и делать так.

Если смотреть проект — там может быть по-разному

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

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

A_L>>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
G>А зачем тебе отстаивать?

Причин может быть много, они могут быть разные. Суть в том, что эта аргументация не совпадает с мнением другого человека. Зачем отстаивать? — Например, автору как специалисту видится, что его решение лучше для проекта. Или ему не хочется работать по принципу — бешеной собаке семь вёрст не крюк

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

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

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

A_L>>>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
G>>А зачем тебе отстаивать?

A_L>Причин может быть много, они могут быть разные.
А конкретно твои какие?


A_L>Суть в том, что эта аргументация не совпадает с мнением другого человека.
Как-будто кто-то менял свое мнение потому что ему кто-то что-то сказал

A_L>Зачем отстаивать? — Например, автору как специалисту видится, что его решение лучше для проекта.
А тиилид не специалист? или он хочет как хуже для проекта?


A_L>Или ему не хочется работать по принципу — бешеной собаке семь вёрст не крюк
Вообще-то программисту платят деньги за его работу, если руководитель считает что надо что-то поменять, то какие есть оправдания у рядового сотрудника кроме нежелания работать?

Здесь есть некоторое противоречие:

A_L>Это те моменты, которые никак качественно не влияют на работу приложения.
и
A_L>а у автора кода другое мнение как лучше для проекта

Т.е. все-таки влияет или нет?

Если влияет, то зафиксировать разногласия (с аргументацией) письменно, чтобы потом в случае чего указать по чьему настоянию сделано именно так, а не иначе. Заложить время на возможную переделку таких правок.
Если не влияет (названия переменных, var и пр.), то я бы ставил вопрос о бесполезности такого review, как субъективного, но по существу правок упираться вряд ли стоит (потом можно оппоненту предъявить зеркальные претензии по поводу его кода).
Как правило менеджера всегда волнуют сроки, и если регулярно указывать на то, что потрачено столько-то времени на очередной бесполезный holy war, то возможно удастся избавится от такой практики.

P.S. как уже писали, если есть утвержденный code style guides, то его следует придерживаться (но вполне можно поднимать вопрос о его изменении)

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

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

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

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

A_L>>>>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
G>>>А зачем тебе отстаивать?

A_L>>Причин может быть много, они могут быть разные.
G>А конкретно твои какие?


A_L>>Суть в том, что эта аргументация не совпадает с мнением другого человека.
G>Как-будто кто-то менял свое мнение потому что ему кто-то что-то сказал

A_L>>Зачем отстаивать? — Например, автору как специалисту видится, что его решение лучше для проекта.
G>А тиилид не специалист? или он хочет как хуже для проекта?


A_L>>Или ему не хочется работать по принципу — бешеной собаке семь вёрст не крюк
G>Вообще-то программисту платят деньги за его работу, если руководитель считает что надо что-то поменять, то какие есть оправдания у рядового сотрудника кроме нежелания работать?


> G>Как-будто кто-то менял свое мнение потому что ему кто-то что-то сказал
Люди могут менять свои мнения в ходе общения с другими

G>А тиилид не специалист? или он хочет как хуже для проекта?
Специалист, наверное хочет чтобы было как лучше

G>Вообще-то программисту платят деньги за его работу, если руководитель считает что надо что-то поменять, то какие есть оправдания у рядового сотрудника кроме нежелания работать?

Вот программист и делает свою работу, предлагая свои решения как будет лучше для компании. Это не связано с желанием работать/не работать
Вы я так понимаю программист или у вас другая профессия?

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

>> _AB>И ровно те, которые описываются code style guides вашего проекта.
A_L>Нет code style guides на проекте

Имеет смысл потратить время и выработать code style guide для проекта. По спорным моментам в этом процессе приоритет у того, кто несет ответственность. Вероятно, в вашем случае это тим-лид.

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

A_L>Нет code style guides на проекте
Тогда такие срачи будут постоянно.

В девелопменте нет места демократии, только диктатура.

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

M>Здесь есть некоторое противоречие:

A_L>>Это те моменты, которые никак качественно не влияют на работу приложения.
M>и
A_L>>а у автора кода другое мнение как лучше для проекта

M>Т.е. все-таки влияет или нет?

M>Если влияет, то зафиксировать разногласия (с аргументацией) письменно, чтобы потом в случае чего указать по чьему настоянию сделано именно так, а не иначе. Заложить время на возможную переделку таких правок.
M>Если не влияет (названия переменных, var и пр.), то я бы ставил вопрос о бесполезности такого review, как субъективного, но по существу правок упираться вряд ли стоит (потом можно оппоненту предъявить зеркальные претензии по поводу его кода).
M>Как правило менеджера всегда волнуют сроки, и если регулярно указывать на то, что потрачено столько-то времени на очередной бесполезный holy war, то возможно удастся избавится от такой практики.

M>P.S. как уже писали, если есть утвержденный code style guides, то его следует придерживаться (но вполне можно поднимать вопрос о его изменении)

M>Т.е. все-таки влияет или нет?

Не влияет,например, на то сколько приложение использует памяти или насколько приложение получится гибким в будущем. Т.е. "с точки зрения цифр и чего-то объективного, что можно
посчитать — разногласий нет"

Есть разногласия, которые скорее холиварные и субъективные. Например, как писал выше использовать практику self-documenting code или нет. И вот одному специалисту кажется так лучше, а другому нет) И боюсь случается так, что каждому сложно будет согласиться с аргументами другого

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

>> G>Как-будто кто-то менял свое мнение потому что ему кто-то что-то сказал
A_L>Люди могут менять свои мнения в ходе общения с другими
Могут не факт что будут.


G>>А тиилид не специалист? или он хочет как хуже для проекта?
A_L>Специалист, наверное хочет чтобы было как лучше
А тимлид хочет как хуже?

G>>Вообще-то программисту платят деньги за его работу, если руководитель считает что надо что-то поменять, то какие есть оправдания у рядового сотрудника кроме нежелания работать?

A_L>Вот программист и делает свою работу, предлагая свои решения как будет лучше для компании. Это не связано с желанием работать/не работать
То же самое делает тимлид и его решение — переписать часть кода, написанной программистом. В чем он неправ?

A_L>Вы я так понимаю программист или у вас другая профессия?
Программист

A_L>Team leader проверяет, вносит свои правки, а у автора кода другое мнение как лучше для проекта

Если тимлид вносит — выполнять. Если равный — не выполнять, если не согласен. Ну это если вопрос действительно не описан в документации и дело личных предпочтений.

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

A_L>>Вот программист и делает свою работу, предлагая свои решения как будет лучше для компании. Это не связано с желанием работать/не работать
G>То же самое делает тимлид и его решение — переписать часть кода, написанной программистом. В чем он неправ?

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

В данном случае тимлид (1) тратит свое рабочее время на то, что он в принципе не должен делать (2) разлагает свою команду, показывая неуважение к своим подчиненным.

Я б на месте топикстартера поговорил сначала с тимлидом, а потом с начальником тимлида. Если начальник тимлида считает, что тимлид все правильно сделал, надо менять работу.

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

vsb>Если ревью от вышестоящего товарища, надо делать как он сказал. Если ревью от коллеги, который придирается по мелочам, тут можно и поспорить. Хотя может быть лучше сделать как он просит и забить, если он не просит чего-то явно плохого и это не отнимет много времени.

А что, вышестоящий товарищ более компетентен по определению?

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

A_L>>Team leader проверяет, вносит свои правки, а у автора кода другое мнение как лучше для проекта
A_L>>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
_AB>Договориться, как "правильно", точнее, "как у нас принято" и делать так.

Ну а что в этом хорошего, если у людей, например, принято функциональность из 3х классов размазывать по ddd?
Тот факт что так принято или деды так делали и мы будем -- ну такой себе аргумент.
Тут через себя переступать приходится.

A_L>Есть разногласия, которые скорее холиварные и субъективные. Например, как писал выше использовать практику self-documenting code или нет. И вот одному специалисту кажется так лучше, а другому нет) И боюсь случается так, что каждому сложно будет согласиться с аргументами другого

Как уже писали предыдущие комментаторы, попытаться ввести некий code style guide в т.ч. правила введения документации.
После чего Вы (либо Ваши оппоненты) будут ссылаться на эти правила (либо на отсутствие таковых).

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

A_L>Добрый день

A_L>Часто бывают спорные ситуации во время code review. Это либо опыт у людей разный, либо дело вкуса, какие-то "холиварные" темы
A_L>Например, писать/не писать комментарии, название переменных, использовать/не использовать var и т.д.. Список можно продолжать до бесконечности
A_L>Это те моменты, которые никак качественно не влияют на работу приложения. Т.е. например, это не о том как код используется больше/меньше ресурсов

A_L>Team leader проверяет, вносит свои правки, а у автора кода другое мнение как лучше для проекта

A_L>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?

A_L>Обратиться к кому-то "выше" за разъяснениями нет возможности

Мои пять копеек.

ИМХО, когда это всё вылезает на code review, уже поздновато пить боржоми. Лучше заранее спрашивать про кодестайл, и про то, как его навязывают. А ещё лучше узнать, есть ли разбивка по модулям, насколько они изолированы и насколько их разработчик свободен в принятии решений внутри. И если что-то не устраивает, не соглашаться.

И ещё на ту же тему. Чем больше общения и споров в процессе написания (парное программирование и т.п. практики), тем лучше. При code review, когда всё уже написано, конфликты становятся гораздо болезненнее. (Поэтому я вообще плохо отношусь к традиционным, постфактумным code review — это хороший способ убить у людей чувство владения, и с ним всю мотивацию).

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

A>Мои пять копеек.
A>ИМХО, когда это всё вылезает на code review, уже поздновато пить боржоми. Лучше заранее спрашивать про кодестайл, и про то, как его навязывают. А ещё лучше узнать, есть ли разбивка по модулям, насколько они изолированы и насколько их разработчик свободен в принятии решений внутри. И если что-то не устраивает, не соглашаться.

Это именно задача cr, особенно когда новые сотрудники, особенного когда нету code styl'ов. Иначе просто никак.

A>И ещё на ту же тему. Чем больше общения и споров в процессе написания (парное программирование и т.п. практики), тем лучше. При code review, когда всё уже написано, конфликты становятся гораздо болезненнее. (Поэтому я вообще плохо отношусь к традиционным, постфактумным code review — это хороший способ убить у людей чувство владения, и с ним всю мотивацию).

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