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

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

G>>Поговорить. Возможно я что-то не знаю.
$>Коллега пытался объяснить, но путается в показаниях. Сделал пару докладов по неведомой ###не. Не убедил.
Значит ты его не понял. Или не захотел понимать.

G>>Разговаривать. Если нет консенсуса, то привлекать третью сторону (начальника).
$>Начальник зааппрувил пул-реквесты коллеги.
Значит начальник его понял.

G>>$>Дискас.
G>>Смысл? Ответ очевиден.
$>Что делать?
Учиться слушать.

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

$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
$>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.

Шо? Опять?

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

LK>Рабочий пример. В компании был программист (ваш покорный слуга), поддерживал старые приложения. Пришёл новый начальник, создал "второй ит-отдел" из 4 человек и начал всё переписывать на питон. Я пытался объяснить, что кода много, и он запутанный (писала куча народа, уже давно уволившегося), что всё работает 16-18 часов в сутки, что работа идёт с деньгами, что мелкая ошибка может привести к приличному ущербу... короче, через 8 месяцев начальника уволили т.к. он обещал за полгода всё переписать, но не переписал.

LK>Да, потом пришёл ещё один инноватор ("доделывать дело раз уж начали"), но я уволился т.к. весь этот цирк — довольно нервный (куча инцидентов, и каждый раз приходится доказывать, что виноваты инноваторы, а не я и "мой старый код").

С какого языка или фреймворка переписывали на питон?
Так то мне нравится питон и для обсчета финансов ведь там готовые и оттестированные библиотеки, плюс отвязываемся от платформы. Не возникало желания поддержать инноватора, помочь make things happen?

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

А>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
А>Что вы будете делать?
А>Дискас.
Артем, это ты пытаешься понять со стороны других программистов тот твой выверт годовалой (ЕМНИП) давности, когда ты самовольно начал писать на функциональном языке вместо Джавы?

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

_AB>Артем, это ты пытаешься понять со стороны других программистов тот твой выверт годовалой (ЕМНИП) давности, когда ты самовольно начал писать на функциональном языке вместо Джавы?

Выводы сделаны, ошибки исправлены.

$>Дискас.
Да это вообще идеально! примеры правильной работы, когда люди договариваются.

Бывает сложнее:
— Коллега не предложил улучшение, а сразу его внедрил. Вы осознаете проблемы в 'улучшении', когда вылазят баги и Вам их править.
— Коллега написал новый модуль проекта в своем стиле с модным дизайном. Убедил начальника, что так надо.
— Коллеги, добавлявшие раньше 'свои' модули, поступали аналогично.
— Коллега затащил неведомую ###ю, которая роняет дебаггер. Переписать никто не даст тк все работает и уже в проде.
— Коллега-программист — математик (а так-то хороший человек). И Вам править его код.
— Коллега — он же заказчик, он же разработчик, пишет код криво, критикует Ваш код, жалуется Вашему начальнику.

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

$>Сценарии:

$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
Если улучшение объективно и измеримо решает какие-то проблемы, его стоит внедрять, если оно решает будущие проблемы, его стоит внедрить в будущем. За неоднократные конфликты на стилистической почве есть шанс вылететь, что у одной, что у другой стороны.


$>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
Юнит тесты и их формат обычно продукт договоренности команды (иначе без большой палки не работает). За попытки поставить что-то в одностороннем порядке вылетает первая сторона, за саботаж договоренностей второая.

$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
$>Что вы будете делать?
Документация. Любой редактор сейчас позволяет документировать и вставлять схемы прямо на ходу или поддерживать актуальный мд.

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

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

$>Что вы будете делать?
Разрешение конфликтов — это прямая и одна из главных обязанностей тимлидов. Соответственно единственна возможность — это сообщить о проблеме непосредственному руководителю и в этом случае это будет проблема непосредственного руководителя. Соответственно если у тебя конфликт с юниором, он фигачит мкдоды на тысячи строк с 20 уровнями вложенностями и отказывается править — объясняешь ситуацию и будет проведена беседа. Соответственно проблемный товарищь либо будет тебя слушать, либо будет ротация и с товарищем пересекаться перестанете, а нет пересечений — нет проблем.

Это в случае, если твой непосредственный начальник на твоей стороне. В случае, если у тебя разногласия с начальством, выхода по большому счету 2 — либо увольняешься ты, либо увольняется начальник. Я кстати был в такой ситуаации, уволился начальник, а не я, но на моей стороне был начальник начальника и конфликт был между начальством, а не мной, я просто остался при своем мнении а не начал прогибаться под начальника. С текущим вообще все идеально, взаимопонимание с полуслова — он понимает почему я так делаю, мне даже объяснять ничего не надо, я понимаю почему он принимает такие решения, мне тоже объяснять не надо, крайне приятно так работать. Ну а когда мнения расходились, я предупреждал, что будут проблемы и решение не сработает, соответственно проходит несколько лет, начальник понимает, что его решение было ошибочным и все приходит к моему решению.

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

PS Если что, clojure у нас не под запретом . А я изначально стоял за то, чтоб под конкретные задачи использовался максимально подходящий для их решения инструмент. 3 года потребовалось чтоб добиться этого. Но самое смешное, что сейчас большинство может просто охренеть от того, какой свободы для разработчиков удалось добиться и какого мегаконсервативного заказчика удалось пробить на магаэкзотику, не могу к сожалению говорить об этом, но кое кто, о ком точно никто никогда не подумает, и кто в России на слуху, де факто круче Тинькова со scala. Под экзотикой я даже не clojure и elm понимаю . Хоть там и маразмов от безопасников хватает, и это реальные маразмы, но по языкам программирования палок ни малейших.

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

$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.
пишите ему — не согласен потому что в PR comment ...

$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.
всё и так работает и так работает не вариант. вы должны обосновать свой дизайн. и коллега должен.

$>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.
дискуссия оффлайн

$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
откомментиться надо что это и почему. обязательно обоснуйте почему вам это не нравится


$>Дискас.
https://medium.com/palantir/code-review-best-practices-19e02780015f

G>>Разговаривать. Если нет консенсуса, то привлекать третью сторону (начальника).
$>Начальник зааппрувил пул-реквесты коллеги.
$>Что делать?
Уйти в отказ по своим задачам, "коллега сломал, коллега пусть и чинит, сам покрасовался на копейку а другим испортил на рубль"?
Во всяком случае, пусть начальник заведёт отдельный таск "переделки для совместимости с ломающими нововведениями коллеги" за отдельные жопочасы.

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

$>Сценарии:

$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.

Каков ваш статус? Оба синьеры? Если равноправные статусы, вы выкладываете свои технические аргументы вышестоящему начальству, и оно уже решает исходя из конкретных производственных нужд и приоритетов (не всегда видных программистам).

$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.

"Все и так работает" — не очень аргумент. При каких условиях работает? Пройдет ли верификацию на определенном этапе цикла разработки? Пройдет ли валидацию системы у заказчика? М.б. на горизонте будет расширение функционала, и его проще делать, если заранее усложнить систему, вводя доп. абстракции и проч. Сколько времени займет это улучшение, и есть ли это время? Куча факторов, и в каждом конкретном случае может быть свое оптимальное решение.

$>- Коллега ставит в известность о новых требованиях к юнит тестам в одностороннем порядке, по надуманным поводам- у вас все юнит тесты и так работали и вообще, у вас опыт юнит тестов больше.

Какие именно требования к юнит-тестам? Я видел "юнит-тесты", которые были на страницу каждый, с кучей ассертов и экспектов (и автор, видимо, вообще не понимал разницу между двумя), I/O в реальную ФС... их надо было выкинуть и переписать заново. По-хорошему, там надо было и продакшн код делапшеизировать сначала, но времени на это не было.

$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
$>Что вы будете делать?

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

G>Значит ты его не понял. Или не захотел понимать.
G>Значит начальник его понял.
G>Учиться слушать.
Это нефальсифицируемые условия без чётких критериев выполнения.

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

G>>Значит ты его не понял. Или не захотел понимать.
G>>Значит начальник его понял.
G>>Учиться слушать.
O>Это нефальсифицируемые условия без чётких критериев выполнения.
Какой вопрос такой и ответ.

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

O>Уйти в отказ по своим задачам, "коллега сломал, коллега пусть и чинит,

Коллега починил все существующие юнит тесты, которые сломались под ужесточенными требованиями. Но для всех новых юнит тестов в будущем, поставил условие в eslint. Соответственно, новые юнит тесты будут ломаться, если не соблюдать ужесточенные требования. А это лишние строчки кода, которые лень писать.

E> Но самое смешное, что сейчас большинство может просто охренеть от того, какой свободы для разработчиков удалось добиться и какого мегаконсервативного заказчика удалось пробить на магаэкзотику
Спасибо, такие как ты никогда не оставят нас без куска хлеба!

"Здесь использовалось 100500 разных технологий, модных 20 лет назад. Написано демократичной командой в стиле кто-во-что-горазд и кто-как-умеет. Нужно 100500 часов времени(и столько же денег) на переписывание."

И правильно! Пусть жадные буржуи делятся с народом!

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

N> "Здесь использовалось 100500 разных технологий, модных 20 лет назад. Написано демократичной командой в стиле кто-во-что-горазд и кто-как-умеет. Нужно 100500 часов времени(и столько же денег) на переписывание."

А как нужно,
"Здесь использовалась 1 технология, модная на заре ЭВМ. Написано командой фанатиков в стиле "как бы чего не вышло". Нужно починить считыватель перфокарт из музея, чтобы понять, как это работает, но уже и схемы считывателя перфоракт не осталось.

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

$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.

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

$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.

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

Кроме того, крайне желательно, чтобы было нормальное разделение кода на подсистемы. Когда любой может вломиться в чужой код и всё загадить, а потом кому-то другому придется разгребать — не есть правильно.

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


N>$>Дискас.
N>Да это вообще идеально! примеры правильной работы, когда люди договариваются.

N>Бывает сложнее:
N>- Коллега не предложил улучшение, а сразу его внедрил. Вы осознаете проблемы в 'улучшении', когда вылазят баги и Вам их править.
Почему вам? На стэндапе говоришь, что есть такой-то баг, особо не вникал, но вроде как связан с фичей 'улучшение'. Все. Адекватные скрум мастера назначат этот тикет на коллегу. Адекатные коллеги (внедрившие 'улучшение') сами выступят и попросят назначить тикет на себя.
N>- Коллега написал новый модуль проекта в своем стиле с модным дизайном. Убедил начальника, что так надо.
А в чем проблема?
N>- Коллеги, добавлявшие раньше 'свои' модули, поступали аналогично.
А в чем проблема? Если у вас есть гайдлайны, то ссылаетесь на них. Если гайдлайнов нет, то каждый волен поступать как хочет.
N>- Коллега затащил неведомую ###ю, которая роняет дебаггер. Переписать никто не даст тк все работает и уже в проде.
Когда успел? Один наворотил делов, а на следующий день у всей команды не работает дебаггер и все молчат, так что ли?
N>- Коллега-программист — математик (а так-то хороший человек). И Вам править его код.
На стэндапе говорим, что наш текущий тикет тесно связан с кодом коллеги-математика (не буквально, конечно, а просто говорим "код связан с модулем Х", при этом кому надо, тот помнит, кто наворотил этот модуль Х). И что мы потратим некоторое время на рефакторинг. Все.
Другой вопрос, как код коллеги-математика прошел через все код-ревью и т.д...
N>- Коллега — он же заказчик, он же разработчик, пишет код криво, критикует Ваш код, жалуется Вашему начальнику.
Аутсорс, я так понимаю? Риски большие, так что консультируемся со своим начальником перед каждым ответным действием по этому вопросу. Иначе можно потерять заказчика, и при этом остаться виноватым в этом

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

__>$>- Коллега предложил улучшение, как он считает, но вы несогласны, что это улучшение кто-то просил, и вообще.

__>Каков ваш статус? Оба синьеры? Если равноправные статусы, вы выкладываете свои технические аргументы вышестоящему начальству, и оно уже решает исходя из конкретных производственных нужд и приоритетов (не всегда видных программистам).

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

__>$>- Коллега под предлогом фичи затащил какую-то неведомую ###ю, взрывающую вам мозг, отличающуюся от привычного вам кодописательства.
__>$>Что вы будете делать?

__>Буду писать в ревью, построчно, что не так, и как надо бы переделать. Если нетривиальный коммит или потенциальная правка, созвонюсь с коллегой, чтобы обсудить, что и почему.

Это в теории. А по факту даже в тех компонентах, в которых хорошо разбираешься, делать ревью это очень трудоёмкое занятие. Поэтому часто оно делается очень поверхностно. А если разбираешься в компоненте плохо (а такое часто), то в серьёз делать ревью как-то самонадеянно.

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

C>$>- Коллега саботирует ваш PR, просит переделать на, как он считает, более правильный дизайн. Но у вас всё и так работает.

C>Пусть обоснует письменно, чем конкретно этот дизайн более правильный. Если из-за него потом возникнут проблемы, тыкать его носом.

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