Добрый день

Часто бывают спорные ситуации во время 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, сделанный по уму, за отсутствием тестов, очень способствует поиску багов и улучшению кода. Да даже и с тестами. Вообще, вещь очень полезная и нужная,
если использовать не как повод для ругани, а по своему изначальному предназначению.

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

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

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

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

Здравствуйте, 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>Вот после этого скорей всего будут замечания по существу, из не знаю, в начале функции сначала сделай обработку граничных условий, а только потом логику, шум из того что ты описал должен уйти.

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

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

I>>Вот после этого скорей всего будут замечания по существу, из не знаю, в начале функции сначала сделай обработку граничных условий, а только потом логику, шум из того что ты описал должен уйти.
A_L>Не всегда руководство принимает предложения по улучшению продукта. Например, сотрудник предлагает исходя из опыта как можно улучшить. Руководство формально соглашается, но в работу это не идет
Ну смотря что за доработки, если соглашается надо в дорожную карту вносить, а не поговорили и забыли, или обговорить что это сделаем вон с той задачей.
У нас целая страница на wiki есть с предложениями по улучшению, которые было бы неплохо сделать, но работать не мешает, а клиент за такие доработки не заплатит, берутся оттуда мелкие задачи когда человек новый в проект приходит как ознакомление и улучшение проекта. А большие задачи которые хотелось бы, только с обоснованием или в связке с пожеланием клиента который готов за доработки платить деньги.

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

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

Ты как "тварь дрожащая" должен выполнять, иначе бы не спрашивал тут.

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

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

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

Конечно. На то иерархия и выстроена.

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

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

С одной стороны вы говорите что TL цепляется за var и по комментариям, и аргументируете «программа ж работает». А с другой стороны — вы спрашиваете «продолжать ли вам отстаивать свое»? Определите для себя что для вас важнее — уметь работать в команде и уметь писать комментарии и внимать критику старших коллег при code review или продолжать отстаивать свои убеждения, которое вам навязано из ютубов и форумов (потому что в книга этого точно нет)?

Наконец, вы же с лидом делаете одно и тоже дело, вы достигнете большего успеха — если будете работать с лидом вместе, чем конфликтовать.

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

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

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

GIV>Ты как "тварь дрожащая" должен выполнять, иначе бы не спрашивал тут.

Почему "тварь дрожащая"? К тебе так обращаются?
Я спрашиваю что-либо когда мне хочется или удобно

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

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

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

R>С одной стороны вы говорите что TL цепляется за var и по комментариям, и аргументируете «программа ж работает». А с другой стороны — вы спрашиваете «продолжать ли вам отстаивать свое»? Определите для себя что для вас важнее — уметь работать в команде и уметь писать комментарии и внимать критику старших коллег при code review или продолжать отстаивать свои убеждения, которое вам навязано из ютубов и форумов (потому что в книга этого точно нет)?

R>Наконец, вы же с лидом делаете одно и тоже дело, вы достигнете большего успеха — если будете работать с лидом вместе, чем конфликтовать.

С одной стороны вы говорите что TL цепляется за var и по комментариям, и аргументируете «программа ж работает».

Я так не аргументировал

уметь работать в команде и уметь писать комментарии

Я умею работать в команде и писать комментарии и люблю слушать конструктивную критику по существу

которое вам навязано из ютубов и форумов

Это не правда

вы достигнете большего успеха — если будете работать с лидом вместе, чем конфликтовать

Смотря что считать успехом

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

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

Если речь идет о стилистических моментах, то спор имеет смысл только если обсуждаются именно они, а не конкретный pull request.
Если в команде они не формализован никак, то стоит конфликтные моменты расписать в wiki. Ты возможно не будешь с ними согласен, но это обычно "not а hill to die on". Извиняюсь за поговорку, но на ум ничего рускоязычного не приходит.

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

AL>Я так не аргументировал

Давайте попробуем с другого конца. Если вы не аргументируете, то я буду аргументировать. Есть пояснительная записка к каждой роли в проекте/продукте. У лида среди прочего предписано, что он отвечает за code review. Ни вы, ни другие члены команды, не скрам мастер/PM или начальник начальника, а лид отвечает и только лид. Второе зафиксируем, требования по ревизии кода почти всегда отличаются от проекта к проекту. И они же формируются лидом и артикулируются также лидом. Более того, сам процесс адаптации/изменения требований к code review непрерывен и постоянен. Зачем? Потому что технологии и языки развиваются и меняются. Поэтому если, например, стек проектов предполагает несколько версий с обратной совместимостью к версиям — могут появлятся и странные (на первый взгляд) требования к ревизии кода.

Вы переходите в другую команду — и уже в другой команде могут быть другие требования к ревизии кода (ниже напишу вам реальный кейс¹). И здесь нет никакого холивара, о котором вы говорите. Ибо, как лид сказал — так и есть. Точка. Потому что это его зона отвественности. Это обязаность лида, не ваша. Какой холивар? Да, стоит отметить что лид зачастую делегирует на кого-то еще код ревью (на усмотрение самого лида) синьору какому-то или мидлу, которого он видит в будущем синьором, но как я сказал раньше, только лид отвечает за процесс ревизии кода.

AL>

AL>которое вам навязано из ютубов и форумов

AL>Это не правда

А откуда у вас тогда такое мнение? Откуда вы это почерпнули? Какие книги? Или в ВУЗе вам это сообщили?

AL>Смотря что считать успехом

Это неуспех, только наоборот. Конфликт с лидом — я называю неуспехом.

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

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

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

AL>>Я так не аргументировал

R>Давайте попробуем с другого конца. Если вы не аргументируете, то я буду аргументировать. Есть пояснительная записка к каждой роли в проекте/продукте. У лида среди прочего предписано, что он отвечает за code review. Ни вы, ни другие члены команды, не скрам мастер/PM или начальник начальника, а лид отвечает и только лид. Второе зафиксируем, требования по ревизии кода почти всегда отличаются от проекта к проекту. И они же формируются лидом и артикулируются также лидом. Более того, сам процесс адаптации/изменения требований к code review непрерывен и постоянен. Зачем? Потому что технологии и языки развиваются и меняются. Поэтому если, например, стек проектов предполагает несколько версий с обратной совместимостью к версиям — могут появлятся и странные (на первый взгляд) требования к ревизии кода.

R>Вы переходите в другую команду — и уже в другой команде могут быть другие требования к ревизии кода (ниже напишу вам реальный кейс¹). И здесь нет никакого холивара, о котором вы говорите. Ибо, как лид сказал — так и есть. Точка. Потому что это его зона отвественности. Это обязаность лида, не ваша. Какой холивар? Да, стоит отметить что лид зачастую делегирует на кого-то еще код ревью (на усмотрение самого лида) синьору какому-то или мидлу, которого он видит в будущем синьором, но как я сказал раньше, только лид отвечает за процесс ревизии кода.

AL>>

AL>>которое вам навязано из ютубов и форумов

AL>>Это не правда

R>А откуда у вас тогда такое мнение? Откуда вы это почерпнули? Какие книги? Или в ВУЗе вам это сообщили?

AL>>Смотря что считать успехом

R>Это неуспех, только наоборот. Конфликт с лидом — я называю неуспехом.

R>⸻
R>¹ про обещанный кейс, часто бывает нужно сделать правки, которые затрагивают другие проекты. И как правило проводят ревизию правок лиды тех проектов, куда делались правки. И даже если вы директор департамента/CTO/PMO пофиг — правите так, как вам скажет этот лид. (Было что правилил комментарии в гите). Потому что нужно было их специальным образом оформлять — далеим от общепринятого. Хотя номанально, он (этот лид) может быть вашим прямым подчиненным. Потому что в code review — главный тот, чей проект. А это лид.

А откуда у вас тогда такое мнение? Откуда вы это почерпнули? Какие книги? Или в ВУЗе вам это сообщили?

От более опытных коллег с других команд. Все в сравнении
Книги разные бывают. Бывают книги в которых много "упрощений". Были проекты, в которых много оптимизаций, книжные примеры для того бизнеса бы не подошли

CC>Тогда такие срачи будут постоянно.

Да.

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

Нет. Диктатура может быть только до определенного уровня деталей. Диктатура вида "здесь можно комменты, а тут нельзя", сделает плохо.

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

A_L>Я спрашиваю что-либо когда мне хочется или удобно
Можешь же когда хочешь

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

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

S>Тот факт что так принято или деды так делали и мы будем -- ну такой себе аргумент.
Конфликт "один против всей команды" тоже продуктивности не добавит.

Но, по крайней мере, при наличии плохих задокументированных стилей кодирования, у тебя будет аргумент для спора.
И можно будет идти по пунктам, объясняя, почему так делать плохо. Но не на code review.

А превращать code review в религиозные войны по тому, как оформлять код...
Это не задача code review — определять, как оформлять код "правильно".
Задача code review — подтвердить, что код оформлен "правильно" с точки зрения уже принятых в проекте стандартов.

S>Тут через себя переступать приходится.
Чтобы что? Какова цель переступания?

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

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

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

A_L>Вы я так понимаю программист или у вас другая профессия?
А ты оверквоттер? Прояви уважение к собеседникам, отформатируй свои сообщения так, чтобы их читать было удобно.
К коду ты тоже так относишься, кстати?

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

A_L>Я умею работать в команде и писать комментарии и люблю слушать конструктивную критику по существу
А что "по существу", а что нет — решаешь в команде только ты, да?

Типа "качественно не влияют на работу приложения" — это существенно, это ты уже написал.

А то, что твой код понять сложно из-за того, что название переменных неудачные и вводят в заблуждение, например — это не существенно, да?

И что ты поленился написать комментарий к сложной, неочевидной логике — это тоже на работу приложения не влияет, значит не существенно?

А то, что ты спустя полгода сам не поймёшь, что там к чему без комментария и с хреновыми названиями переменных, а пофиксить надо срочно, клиенты теряют деньги из-за изменения обстоятельств, например, — это ерунда, "не влияет на работу приложения". Я всё правильно понял?

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

SD>Нет. Диктатура может быть только до определенного уровня деталей. Диктатура вида "здесь можно комменты, а тут нельзя", сделает плохо.
Посмотри как он здесь, на форуме, оформляет свои сообщения.
Оставить как есть, или, всё-таки, призвать диктатора-модератора?

Есть ли вероятность, что его код по небрежности оформления не особо отличается от сообщений на форуме?
ИМХО, немалая.

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

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

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

A_L>>Вот программист и делает свою работу, предлагая свои решения как будет лучше для компании. Это не связано с желанием работать/не работать
_AB>Нежелание убрать лишние комменты или добавить недостающие, переименовать переменные так, как понятно команде — это что?
_AB>Как это существенно улучшает позицию компании на рынке?

A_L>>Вы я так понимаю программист или у вас другая профессия?
_AB>А ты оверквоттер? Прояви уважение к собеседникам, отформатируй свои сообщения так, чтобы их читать было удобно.
_AB>К коду ты тоже так относишься, кстати?

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

_AB>Нежелание убрать лишние комменты или добавить недостающие, переименовать переменные так, как понятно команде — это что?
_AB>Как это существенно улучшает позицию компании на рынке?
Это субъективно, тут ты мне ничего не докажешь

_AB>А ты оверквоттер? Прояви уважение к собеседникам, отформатируй свои сообщения так, чтобы их читать было удобно.
_AB>К коду ты тоже так относишься, кстати?
Ты своим указывай как что делать

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

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

A_L>>Я умею работать в команде и писать комментарии и люблю слушать конструктивную критику по существу
_AB>А что "по существу", а что нет — решаешь в команде только ты, да?
С чего ты это решил?)


_AB>А то, что твой код понять сложно из-за того, что название переменных неудачные и вводят в заблуждение, например — это не существенно, да?

Почему неудачные? Может кто-то читает плохо и вводится в заблуждение? Бесполезно тут что-то тебе писать. Много промышленного кода написано в разных командах,
все кто хотел понять — понимали. Специально не придумывал названия переменных чтобы никто не понял

_AB>И что ты поленился написать комментарий к сложной, неочевидной логике — это тоже на работу приложения не влияет, значит не существенно?
Почему сложная неочевидная логика? Почему поленился? Обычный код, никакого rocket science

_AB>А то, что ты спустя полгода сам не поймёшь, что там к чему без комментария и с хреновыми названиями переменных, а пофиксить надо срочно, клиенты теряют деньги из-за изменения обстоятельств, например, — это ерунда, "не влияет на работу приложения". Я всё правильно понял?
Почему спустя полгода я не пойму? Почему хреновые названия?

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

думаю что драка до первой крови будет справедливо

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

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

vsb>Конечно. На то иерархия и выстроена.

Это иерархия управления и ответственности, а не технической экспертизы.

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

A_L>Часто бывают спорные ситуации во время code review. Это либо опыт у людей разный, либо дело вкуса, какие-то "холиварные" темы
A_L>Например, писать/не писать комментарии, название переменных, использовать/не использовать var и т.д.. Список можно продолжать до бесконечности
A_L>Это те моменты, которые никак качественно не влияют на работу приложения. Т.е. например, это не о том как код используется больше/меньше ресурсов
Должен быть документ по coding style и, как продолжение, линтеры и форматтеры, прехуки и прочие "радости".
A_L>Team leader проверяет, вносит свои правки, а у автора кода другое мнение как лучше для проекта
Обсудить голосом/лично, если не можешь убедить, значит твоя позиция не достаточно сильная или ты чего-то не понимаешь/не видишь. Дальше делаешь как просят.
A_L>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
Зачем? Какая цель этого? Ты работаешь по найму за з/п.
A_L>Обратиться к кому-то "выше" за разъяснениями нет возможности
У Макконела было. Если просят поправить тривиальные вещи, то лучше поправить как просят и всё.

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

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

Если это непринципиальные моменты типа упомянутых, проще всего использовать code style,
желательно автоматически (набор правил, которые энфорсятся прямо в IDE, чтобы до review эти вопросы даже не доходили). Линтеры, рулесеты, вот это вот.
То есть, чтобы код написанный не по правилам, просто не компилировался. Займись лучше этим чем препирательством.

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

A_L>Team leader проверяет, вносит свои правки, а у автора кода другое мнение как лучше для проекта
Лида из кодеров начальник прокачивал? Хороший лид должен заниматься разруливанием конфликтов между сотрудниками (грубо говоря, Вася вчера сделал Пете 3 уступки, значит сегодня Петя должен сделать Васе 3, чтобы был паритет) и коммуникацией с PM, чтобы на погромистов не лился поток меняющихся каждую неделю требований, которые надо было сделать вчера.

A_L>Как поступать в подобных ситуациях — соглашаться с мнением team leader или продолжать отстаивать свое?
Открыть в голове счет. 10 часов потратил на написание кода, 1 час — на внесение правок, какими бы дурацкими они не были. Считай это издержками производства и успокойся. Если же выходит 5 часов правок на каждый час работы, то начинать искать другое место.

У меня так было — сидишь, продумываешь ортогональную декомпозицию, делаешь красивые уровни абстракции, а на ревью начинается — тут переименовать, там break вместо return, здесь аргументы поменять местами, и сиди переделывай все по нескольку раз. А что код делает, люди понимать даже не пытаются. Уволился — полегчало. Проект потом закрыли.

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

N>Если в команде они не формализован никак, то стоит конфликтные моменты расписать в wiki. Ты возможно не будешь с ними согласен, но это обычно "not а hill to die on". Извиняюсь за поговорку, но на ум ничего рускоязычного не приходит.
+1

"Не стоит выеденного яйца".

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

[...куча оверквотинга поскипана...]
_AB>>А ты оверквоттер? Прояви уважение к собеседникам, отформатируй свои сообщения так, чтобы их читать было удобно.
A_L>Ты своим указывай как что делать
А ты так ничего и не понял...
Символично!

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

SD>Нет. Диктатура может быть только до определенного уровня деталей.
Есессна, все хорошо в меру.

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

S>>Тут через себя переступать приходится.
_AB>Чтобы что? Какова цель переступания?

Для простейших вещей из 3-4 классов использовать DI контейнер. И DDD натягивать к месту и к не.

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

Q>Стандартная же тема — делаешь в курсаче пару намеренных косяков — препод их с чувством выполненного долга находит, ты правишь, тема закрыта. Потому что иначе к чему прикопаться — все равно найдет, а переделывать будет больше.

Метод ‘зеленая собачка’ художника Фаворского:

была гениальная история про известного старинного художника, который рисовал портреты всякой знати на заказ. и задолбали они его в конец, ибо принять сразу работу им было западло и они придирались, просили вдруг переписать их в другом костюме поверх старого и т.п. И художник придумал фишку — он в углу каждой картины рисовал маленькую зеленую собачку жутко противного вида, когда приходили заказчики, они первым делом замечали собачку и начинали орать «Что это за жуткая зеленая тварь?!» и художник говорил — «Ок, собачку убираем, все остальное в порядке, да?» Ну и они уже обессиленные и охреневшие от собачки соглашались

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

S>Для простейших вещей из 3-4 классов использовать DI контейнер. И DDD натягивать к месту и к не.
1. Какое это имеет отношение к теме обсуждения?
2. Ты можешь попробовать переубедить всю команду, привыкшую так писать, конечно. Но сдаётся мне, что не получится, если тим лид за них. Проще найти другую команду, ИМХО.

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

_AB>>А что "по существу", а что нет — решаешь в команде только ты, да?
A_L>С чего ты это решил?)
С того, что ты так и пишешь прямым текстом.

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

Соответственно, всё, что не совпадает с мнением "автора, как специалиста" автоматически неконструктивно и не по существу.

A_L>Почему неудачные?
По мнению других членов команды, которые читают твой код.

A_L>Может кто-то читает плохо и вводится в заблуждение?
Может, например, ты? Не допускаешь такой мысли?

A_L>Бесполезно тут что-то тебе писать. Много промышленного кода написано в разных командах,
A_L>все кто хотел понять — понимали.
Вопрос в том, сколько они при этом усилий затрачивали и вникали в логику кода, пытаясь понять, почему переменная названа так, а результат другой, например.

A_L>Специально не придумывал названия переменных чтобы никто не понял
Если бы кто-то специально такие названия придумывал, его надо было бы уволить.
А неудачные названия обычное дело. Особенно, если английский не родной.
Буквально сегодня просил одного программера переименовать в названиях методов Attachments на Files.
Он мне в ответ — я тогда на Objects поменяю, т.к. платформа, к которой методы обращаются, так называет файлы.
А посмотреть, что все другие методы, которые уже существуют в данном класе несколько лет, используют Files, человек не удосужился.
Тоже специалист, тоже виднее...

_AB>>И что ты поленился написать комментарий к сложной, неочевидной логике — это тоже на работу приложения не влияет, значит не существенно?
A_L>Почему сложная неочевидная логика? Почему поленился? Обычный код, никакого rocket science
Я тебе условно гипотетическую ситуацию предлагаю в качестве примера того, как комментарии могут качественно сказываться. В виде вопроса.
Но, если ты никогда не писал ничего сложного и неочевидного и не возвращался к этому куску кода спустя заметное время, тогда, конечно, суть вопроса ты понять не можешь.

A_L>Извини, ты странный и очень аггресивный. Навыдумывал кучу всего, что к реальности не имеет никакого отношения.
Извини, но это ты очень странный.

Я привёл тебе примеры, когда "писать/не писать комментарии, название переменных"(с) могут качественно влиять на работу приложения и работу команды. Примеры из реальной практики, кстати.

A_L>Дальше обвинил в этом абсолютно незнакомого человека и навешал на некого кучу ярлыков.
Ты не второй ник мразеца 19? Тот тоже неспособен в простейшую абстракцию...

И я тебя "обвинил" ровно в одном. Я констатировал твоё полное неуважение ко всем участникам форума, выражающееся в отвратительном форматировании твоих сообщений и куче оверквоттинга. И предположил, что к своему коду ты относишься точно так же, т.к. обычно люди не меняют привычки работы над своими текстами в зависимости от контектста.

CC>А ты так ничего и не понял...
CC>Символично!

Всему свое время, парень молодой, горячи (я надеюсь). А вообще 100% — отношение с руководителю с конкрутных позиций ни к чем хорошему не приводит, ибо нарушает суть вещей. Вероятность успешного хаджакингда в общем случае околоноля.

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

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

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

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

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

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

Если ревьюер не главный, то я в подобных случаях, когда сам делаю ревью и не считаю замечание принципиальным, сразу же отмечаю свой комент как Resolved/Closed что бы показать, что это просто минорное замечание ("лучшее" на мой взляд имя переменной или, например, использование out var в IDictionary<,>.TryGetValue(…)) которое автор может проигнорировать если сочтёт нужным.
Если ваш ревьюер сделал не так, что в коментах попробуйте выяснить, на сколько это принципиальное изменение с точки срения ревьюера. Если он считает это принципиальным, а вы принципиально с этим не согласны, пускай "главный" и решает. Обычно в ту или иную сторону разработчики способны сами договориться как сделать.

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

_AB>>А ты оверквоттер? Прояви уважение к собеседникам, отформатируй свои сообщения так, чтобы их читать было удобно.
_AB>>К коду ты тоже так относишься, кстати?
A_L>Ты своим указывай как что делать

Простите, у меня вдруг возникло подозрение, что вы прежде чем писать здесь или позабыли или пропустили Рекомендации по написанию сообщений и правила поведения в форумах Разве так можно?

Там недвусмысленно сказано, что:

3. Запрещается излишнее цитирование (overquoting). Если вы отвечаете на письмо, цитируйте из него только те отрывки, которые действительно необходимы для понимания, о чём идёт речь. Наличие в сообщении трех цитат подряд или строки "X>Здравствуйте, Ник, Вы писали:" является причиной для бана.

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

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

vsb>>Конечно. На то иерархия и выстроена.

Pzz>Это иерархия управления и ответственности, а не технической экспертизы.

Обычно в компании есть иерархия по техничекой экспертизе. И тимлид в её рамках является высшим звеном, разве не так? Джуниор-Мидл-Синьор-Тимлид. В моём понимании — так.

Ну и, раз упоминаем про ответственность, то к ней и повышенные права должны прилагаться.

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

Pzz>>Это иерархия управления и ответственности, а не технической экспертизы.

vsb>Обычно в компании есть иерархия по техничекой экспертизе. И тимлид в её рамках является высшим звеном, разве не так? Джуниор-Мидл-Синьор-Тимлид. В моём понимании — так.

Задача тимлида — делегировать ответственность. Но не делать работу за подчиненных. Он не обязан быть самым крутым экспертом, его задача, как тимлида, управлять людьми. Кроме того, в группах с высокой экспертизой (т.е., занимающихся сложной, а не трудоёмкой работой) часто практикуется специализация. Не обязательно, чтобы все понимали во всём.

Ну и наконец, тимлид может быть просто очень занят. Он управляет несколькими людьми и взаимодействует с начальством.

vsb>Ну и, раз упоминаем про ответственность, то к ней и повышенные права должны прилагаться.

Права — да. Но переделывать работу за подчиненного — это управленческое фиаско.

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

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

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

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

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

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

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

на шарпах как-то давно был срач

Подход 1:
приватные поля класса как _field, константы UPPER_CASE, приватные методы getSmth, а публичные GetSmth

Подход 2:
в другом проекте баня почему-то упала и приватные поля, стали писать как field константы как CamelCase
на все мои аргументы что когда параметр метода идентичен полю класса, то обязательно приходится писать this — мимо кассы.
то, что в контексте сразу видно приватный метод, тоже мимо кассы и константы туда же.
так же были любители var
и когда в СКВ смотришь var someVar = GetData() то какого типа someVar вообще непонятно.


И там где была власть, был подход №1 и плевать я хотел на код стайлы микрософта.
В джавовом проекте видел интерфейсы с I, что в общем очень удобно, но у джавистов с этого "горит", хотя мне кажется, что удобно,
но в джаве так не принято, плюс jdk написан без префикса I.
Но для большой системы — удобно.

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

_>приватные методы getSmth, а публичные GetSmth
А это зачем?

_>на все мои аргументы что когда параметр метода идентичен полю класса, то обязательно приходится писать this — мимо кассы.
+1

_>то, что в контексте сразу видно приватный метод, тоже мимо кассы
А смысл в этом какой?

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

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

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

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

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

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

Краткосрочно — делать как говорит тимлид.

Долгосрочно:

1. Давить в себе это "мне больше всех надо". Вам с этим проектом (с этим куском кода) детей не рожать.
2. Искать другой проект, другую компанию — в надежде, что там будет не так.
3. Становиться тимлидом. Тимлидство бывает разное — и с перевесом в менеджмент, и с перевесом в программирование.

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

Q>У меня так было — сидишь, продумываешь ортогональную декомпозицию, делаешь красивые уровни абстракции, а на ревью начинается — тут переименовать, там break вместо return, здесь аргументы поменять местами, и сиди переделывай все по нескольку раз. А что код делает, люди понимать даже не пытаются. Уволился — полегчало. Проект потом закрыли.

Так они наоборот пытаются, но там return вместо break да и именования какие-то странные. Пойди разбери что этот код делает!

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

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

Хук-кросс шаг- ливер хук, аппер.

PS взрослеть нужно.

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

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

Ну вообще по разному бывает. У меня был случай, когда я в фабрике сделал крошечное expression tree, которое в рантайме делала лямбду. Весь код пару строк и прекрасно работало. Тим лид явно видел такое вперыве и начал давить, что сложно, непонятно и вообще это читинг и настаивал на понятном и громоздком ифе. В итоге проще было согласиться.

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

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

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

A>Ну вообще по разному бывает. У меня был случай, когда я в фабрике сделал крошечное expression tree, которое в рантайме делала лямбду. Весь код пару строк и прекрасно работало. Тим лид явно видел такое вперыве и начал давить, что сложно, непонятно и вообще это читинг и настаивал на понятном и громоздком ифе. В итоге проще было согласиться. Но в данном контексте это явно не тот случай

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

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

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

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

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

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

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

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

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

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

По-хорошему должен быть coding-style в проекте. Если претензии от равного по должности коллеги — можно поспорить и вежливо послать если не согласен.
Если выходит дело на уровень выше, то принимать то, что сказал тим-лид.

Я думаю проблема в том, что ты принимаешь работу близко к сердцу("общее дело", "как лучше" итп). По факту все решают свои проблемы, реализуют свои амбиции, зарабатывают денежку итд...и ты всем до лампочки по большому счету со своим мнением.

Хочешь иначе — создавай свой бизнес (там правда будут другие проблемы).

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

A_L>Часто бывают спорные ситуации во время code review.

Можно носить с собой нож, баллон, травмат, в особо трудных случаях -- сайгу.

A_L>Например, писать/не писать комментарии, название переменных, использовать/не использовать var и т.д.. Список можно продолжать до бесконечности

Насколько я помню, в JS между var и let таки есть разница, а без первого и второго переменная вовсе
получается глобальной. За такое сразу табло бьют.

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

1. Один программист должен уметь читать код написанный другим, а не залупаться, что им там привычно или нет.

2. Целью code review является выявление возможных ошибок и неприемлимых практик программирования,
а не подсчёт числа пробелов или выравнивание скобочек по линейке приложенной к экрану.

3. Поскольку разбота делегирована конкретному сотруднику, то он и отвечает за её результат и принимает
конкретные решения, как именно задача будет решена. Это краеугольный камень.

4. Другие сотрудники должны обладать правом вето на внесение кода в репозиторий при наличии
обоснованных и задокументированных (в системе где делается ревью) претензий. Не должно быть
устных ответов, мол "я посмотрел, мне там что-то не понравилось". Либо плюсик, либо минусик
с описанием проблемы. Иначе будут динамить.

5. Ревью должно делаться полностью, а не в таком режиме, что посмотрел следующий файлик, нашёл
отсутствующую точку в комментарии, и так по кругу. Потому, что иначе сроки растягиваются в
бесконечность. В идеале, на ревью должен даваться один рабочий день. Потому, что растягивание
ревью хороший способ срывать сроки коллегам. На следующий день должен быть обязательно поставлен
плюсик или минусик как факт того, что ревью делалось. И это должно быть обязанностью ревьювера
связаться с автором кода и выяснить вопросы, если они есть, а не автор должен дёргать за рукав
ревьювера, которому каждый день некогда. Работа менеджера -- обеспечить выполнение ревью в
заданные сроки. Выполнение ревью это прямолинейная работа которую просто нужно сделать, это
рабочая обязанность. Отложить свою работу и сделать. Отговорок здесь не может быть.

6. С придурками лучше не работать и сразу идти на выход. Увы.

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

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

В любой программисткой конторе раз в квартал, полгода, год выдают премию. На отдел положена фиксированная сумма,
которая должна быть распределена руководством путём оценки сотрудников. Программистам понятие игры с нулевой
суммой наверное должно быть понятно и очевидно. И одной из стратегий является затягивание чужой работы.

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

fk0> В любой программисткой конторе раз в квартал, полгода, год выдают премию. На отдел положена фиксированная сумма,

Сколько работаю, ни разу не видел такого порядка вещей. Это в каком мире такое происходит в _любой_ программистской конторе?

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

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

fk0>И одной из стратегий является затягивание чужой работы.

Более распространенный случай — просто борьба за повышение. Кто-то "сделал полезные указания", а кто-то "сделал недостаточно хорошо, и ему сказали как надо исправить".