Здравствуйте, 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>И одной из стратегий является затягивание чужой работы.

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