Comments 272
Статья прекрасна. Именно такое code review здорового человека. Главное - польза, а не вкусовщина. А еще бывает review в духе: "надо сделать так, потому что иначе не будет слито, ибо я так сказал".
Справедливости ради, сказать "надо сделать так, потому что иначе не будет слито, ибо я так сказал" – это законное право мейнтейнера проекта, поскольку именно он отвечает за то, чтобы проект не развалился на части.
Конечно, лучшее до таких ультимативных формулировок не доводить, но бывает что персонажи не понимают ситуацию, и аппелируют в формате "я тут потрудился и пользу сделал (которая никому кроме меня не нужна), давайте вливайте", а то что этот код затруднит жизнь десятку других разработчиков его не волнует.
Хорошая статья как не стоит и как стоит вести себя на ревью, с примерами: https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like
Утро разработчиков начиналось с текстовых баталий. По итогу конфликты привели к развалу команды.
Кстати много таких и похожих советов есть в книге Терапия Настроения. И в целом, там как раз говорят, что надо стараться не ставить вторую сторону в защитную позицию в спорах, а лучше как нибудь с ней согласиться, чтобы таким образом погасить запал, скорее всего, таким методом можно было бы и токсичность автора в ревью усмирить ещё до разговора с начальством.
А так да, бывает, что мы очень увлекаемся чем-то и перестаем видеть окружающий мир, автор большой молодец, что не ушёл, а решил разобраться.
Бывает и обратная ситуация.
Слишком низкая "токсичность", отторгает измения и приводит к консервации команды работая как отрицательный отбор. В итоге получается команда в которой каждый хвалит соседа, при этом все сидят ту уже 5 и более лет, любой сильный сотрудник из команды очень быстро вымывается, и остаться только "лояльные" которые как специалисты на рынке не восстребованы. Проект при этом движется крайне медленно и представляет из себя сплошной технический долг.
Чтобы такого не происходило, нужно выстраивать культуру задавания вопросов. Если на очередной вопрос "почему мы не делаем X, ведь так же будет лучше?" получаешь ответ "не до этого сейчас, работать надо", то через пару попыток желание задававать вопросы и предлагать улучшения пропадает.
Когда то сам боролся с этим всем, но у всех некое «своё» видение «всего». Однако же если конкретизировать цели не абстракциями а цифрами и прилепить сверху печать — то работает оно железобетонно.
Например из недавнего. Прекрасный новонанятый кодер кое что сделал действительно очень хорошо. Однако же полезши в бд он же сделал сие очень плохо. И для него нет разницы, он применил практически один и тот же подход в этих двух местах. И его как раз таки не долго бодали за это. Потому что есть документы. В первом случае скорость не критична и так и написано на бумашке. А во втором случае нужна скорость 10млн строк минимум и так и написано на другой бумашке. Всякие споры тут же и прекратились. Человек мгновенно понял и переделал совершенно в другом стиле. «Силу» подписи и печати не стоит недооценивать.
вот бы еще пример такой бумажкиВы это серьёзно? :) Коммерческим кодом вряд ли делятся. Ну или делятся, но за большие деньги.
А причём здесь код когда суть про бумашку — спросите вы. А притом — отвечу я.
Ну ладно. Как обычно на пальцах. Что есть производственный процесс? Это некоторые люди осуществляющие деятельность. По сути они работают по программе. Т.е. это и есть программа. Программа исполняется в треде. Тредов больше чем один. Они конкурируют, блочат друг друга, выкидывают ексепшены. Суть менеджмента — это высокоуровневый диспетчер для обработки очередей, блокировок, эксепшенов и т.д. Так получается что менеджмент — это тоже программа? Ну конечно. Только высокоуровневая. Ни в коем случае не нужно понимать высокий уровень как нечто возвышенное, суть вовсе не в этом. Высокий уровень — это более абстрактные абстракции, не более того. Так вот я про то, что всё есть программа. Вот так и получается предприятие. Вопрос в том, как и кто пишет программу или уже написал. И в каком стиле. И ещё более существенный вопрос — а эта программа вообще написана? А если написана — сколько в ней ошибок, необрабатываемых исключений, каков процент простоя тредов и т.д. и т.п. Улавливаете мысль ага? :) Если не улавливаете — вы не программист. И делать вам в менеджменте нечего. Для директоров и прочих руководителей сообщу наистрашнейшую истину. Увольте за забор всех тех кто не является программистом. Это бесполезные существа. Увольте себя если вы не программист. Вы — бесполезное существо. Ну потому что исходя их того что написано выше — всё есть программа. Но пишут это ПО только программисты. Иначе никак. Иначе ваша Машенька с философским образованием и лучший друг Петька зам. с рыбного ПТУ вам всё и всегда будут пороть. Потому что они не программисты. Т.е. существа исключительно бесполезные.
А вот теперь вернёмся к бумашкам. Что есть бумашка в данном случае? А это формализованная обработка ексепшена на тред. Всего навсего. Но вы меня извините, я ещё раз напишу — коммерческим кодом вряд ли делятся. Так что примеров бумажек не будет.
А теперь подумайте хотя бы раз, джентльмены. Особенно из так называемого менеджмента. Какова ваша функция? И исполняете ли вы её? А вот сильно вряд ли. Более того, вы даже не понимаете зачем вы есть. Господа программисты, и вам просьба не обижаться. Теперь вы понимаете чем является вменяемый менеджмент. Это ваш верный друг и помошник. Потому что менеджмент за вас разгребает ваши ексепшены и прочие косяки лезущие из вашего треда.
Все прочие завихрения от каких то там экономистов юристов дизайнеров психологов и прочих дегенератов — значения не имеют. Вообще никакого. Единственное зачем нужны эти люди — они реализуют нужный интерфейс. Однако же на абстрактное ПО в целом — они совершенно не влияют.
Так вот я про что. А я про то, что пока нет программиста и программы — а нефиг мутить предприятие. Это заведомо 100% фейл. Чудес не бывает и никогда не будет. Такие дела.
п.с.: Имею собственную программистскую кантору уже как 20 лет, проблем нет, не было и не будет. Код исключительно написан и отлажен.
Коммерческим кодом вряд ли делятся. Ну или делятся, но за большие деньги.
Да ладно, ещё как делятся, бесплатно.
Если не улавливаете — вы не программист
Увольте за забор всех тех кто не является программистом. Это бесполезные существа. Увольте себя если вы не программист. Вы — бесполезное существо
Потому что они не программисты. Т.е. существа исключительно бесполезные.
экономистов юристов дизайнеров психологов и прочих дегенератов
Зачем же вот так лихо вешать ярлыки, и откуда столько ненависити к «непрограммистам»?
Да ладно, ещё как делятся, бесплатно.
То есть коммерческим кодом кто-то там где-то там чуть-чуть поделился, не означает «еще как деляться». Вот когда процент коммерческого кода, попавшего в outsource будет хотя бы 25%, тогда можно будет говорить об «еще как делятся». А сейчас это в основном исключение из практики.
Но если нужны примеры, где отдали 100%, без проблем. Вообще, есть куча проектов, которые изначально были открытыми, например Godot. А есть ещё Defold, который был изначально закрытым, а потом им поделились на 100%, отдав в опенсорс.
Есть и намного более популярные примеры, возможно вы слышали о них: Linux, Docker, Postgres, Golang и др.
«ещё как» означало — такое встречается очень часто.
"очень часто" — это сколько? 90% всего существующего коммерческого кода?80%? 50% хотя бы?
90% всего существующего коммерческого кода?80%? 50% хотя бы?
Ого какой сложный вопрос, а как же я это узнаю? Нужно обязательно в процентах? А зачем?
Я напомню, что изначально я ответил на фразу — «коммерческим кодом вряд ли делятся». Я показал, что делятся и привел примеры. При чем, это не парочка безымянных и малополезных проектов — их много, и среди них есть очень популярные.
Ого какой сложный вопрос, а как же я это узнаю? Нужно обязательно в процентах? А зачем?
Ну чтобы понимать, что вы подразумеваете под "очень часто". С моей точки зрения, "очень часто" предполагает распространенное явление, ну т.е. хотя бы 50%+ коммерческого кода пошарено. Если же пошарено ну где-то ~10% — то можно считать, что коммерческий код вообще не шарят.
Я напомню, что изначально я ответил на фразу — «коммерческим кодом вряд ли делятся». Я показал, что делятся и привел примеры.
Так факт "коммерческим кодом делятся" ни как не противоречит тому, что "коммерческим кодом вряд ли делятся".
Вот если 90% кода было открытым, это «очень часто» для вас? А если этим бы занималось всего 5% компаний? А если бы это приходилось на 1% предметных областей (к примеру, только базы данных были бы открытыми), это все еще очень часто? Ну или если бы только 1% это кода был бы достоен внимания, а остальное мусор?
Ну то есть, если вы решили, что я имел ввиду какую-то статистику, то почему именно такую?
Если дождь идет каждый час, это очень часто? А при этом он занимает всего 5% от общего количества времени в сутках?
Скажем, если я вижу, что каждый день десяток компаний отдаёт в опенсорс шикарные проекты, которые начинают пользоваться огромной популярностью, я могу сказать — это очень часто.
Так факт «коммерческим кодом делятся» ни как не противоречит тому, что «коммерческим кодом вряд ли делятся».
Почему не противоречит? Откуда вы знаете, что имел ввиду автор? Быть может, он имел ввиду — «коммерческим кодом НЕ делятся, но я в этом не уверен на 100%». То есть, он имел имел ввиду не процент от общего количества, а саму вероятность существования такого явления. А я ему показал — товарищ, посмотри, такое явление существует с вероятностью 100%. На что он бы мог ответить — «хмм, действительно! как же я ошибался!». Давайте ка мы сначала добьемся от него четкого определения, а уж потом продолжим дискуссию.
Погуглите RFC (Requests For Comments). Во многих популярных проектах они есть, вот тут есть примеры: https://github.com/search?q=rfcs
Повышение дружественности среды требует введения дополнительных мероприятии для сохранения ее конкуренции, это не простая задача.
Самое главное перед внедрением код-ревью в командах: это чтобы все члены команды понимали правила как делать код-ревью (на хабре есть статьи...и про то, как писать комментарии правильные и про скоупы для ревью и т.д.). Если понимания такого у других участников нет - вы можете апеллировать к руководству, на конкретном примере. Как правило многие внедряют код-ревью и думают, что их код сразу станет лучше, но на деле - это приводит к множеству конфликтов/споров и даже механизмов манипуляций.
Я проходил случаи и нарушения проведения код-ревью (к примеру ревьюер оставлял комментарий на чужой код), и случаи когда ревью занимается один человек, но его компетенции, как разработчика значительно ниже и умеет убеждать руководство (тоже плохо, руководство не понимает) и даже, когда код ревью тормозит срок выполнения задачи (типа накидывают косяков, которые в принципе для исправления надо переписывать чужие вещи).
В общем важно понимать, что код-ревью - это такая же условность и соглашение в команде, как и все остальные соглашения. При правильном подходе - это работает. При неправильном - порождает только массу проблем.
С другой стороны не идеальный в техническом плане проект, но над которым может более-менее эффективно работать вся команда, есть шансы успешно сдать.
Работодателя в конечном счёте интересует сданный проект. Да, техдолг и кривые решения удорожают разработку, но разбежавшееся команда может удорожить разработку гораздо сильнее любого техдолга.
Так что часто выгоднее выбирать решение, которые поддерживают большинство членов команды, а не которое правильное с точки зрения одного члена команды, но ему никто не верит — как минимум даже если решение окажется не очень хорошим, будет больше рук, готовых его поддерживать/переписывать. Исключение может быть разве что в каких-нибудь граничных случаях типа «один разработчик рок-звезда из Google, а вся остальная команда — студенты первокурсники», но обычно реальные отличия в уровнях подготовки не настолько сильные, как это видится разработчику, агрессивно продавливающем своё видение правильного решения.
- срок сидения в болоте прямо пропорционален этому нашему «профессионализму»
- … и возьмем мы тебя в это болото, только когда квакать будешь в унисон...
Несколько раз наблюдал картину, когда человек пришел в команду, захотел что-то изменить и начал предлагать то, что команда уже пробовала и, в итоге, сделала по-другому, потому что предлагаемый вариант не зашел.
Ну и, следует еще обращать внимание на компетенции. Очень часто человек, который захотел что-то изменить, не имеет ни опыта подобных изменений, ни квалификации, чтобы эти изменения внедрить и добиться их работоспособности. Он прочитал очередную книгу и решил, что все просто, достаточно расчистить поле и сразу прилетит самолет с подарками.
Встречают по одежке, провожают по уму — свою мысль нужно донести так чтобы её усвоили, а не просто бросить в воздух и надеяться что сама впитается. Это про команду
А бизнесу надо показать в чем конкретно проблема, автор об этом понял благодаря руководителю. «работает — не трогай» это про то, что «оно, по крайней мере, работает и мы это видим. А ты докажи, что видишь больше». Просто доказать сложнее, чем по верхам собрать инфу и с какими-то бест-практисами лезть все перестраивать непонятно зачем.
Не обязательно принимать все решения прямо в тот же спринт. Можно их чуть отложить на потом. Редко бывает что-то ну прям совсем срочное
> Да, техдолг и кривые решения удорожают разработку
А потом может возникнуть ситуация, что и в команду новые люди не идут, потому что легаси, и текущие спецы не могут устроиться на новую работу, потому что отстали от жизни
И вообще, в большинстве случаев работодатель нанимает новых людей по опыту. Но зачем, если в итоге этот опыт оказывается ненужен? А пилить код «от забора и до обеда» спокойно может и выпускник курсов
Не очень понимаю, почему по вашему "душнила" не снижает эффективности работы окружающих, если вы сами пишите, что "не дает дышать полной грудью" (не дает работать в полную силу, как я понимаю)?
Токсичному нужен именно конфликт, это основная его деятельность. Избавившись от одной драмы, немедленно создаёт две новых.
Мне нравится вариант - писать фидбэк на код ревью в формате "а почему тут сделано так, а не вот так?". И в качестве ответа ожидается либо переделка на второй вариант (при условии что он действительно лучше), либо аргументация в формате "первый вариант лучше, потому что..." или хотя бы "потому что нет времени переделывать на второй вариант"
"Как написал — так написал, переписывать не хочу".
"Вы задерживаете работу, у меня еще 5 историй в этом спринте. Надо было на груминге умничать."
А вы напомнили мне недавний пост от одного перца в общем чате (без задних мыслей, что страшнее): "А что это за билд такой CI? Он место в очереди занимает. Я удаляю если никто не отпишется щас.". Dunning-Kruger он такой.
Плюс настроили фейл CI если в проекте есть файлы с "#no-lint" (отключение линтера для конкретного файла). Отключение отдельных правил линтера позволялось, с обоснованием на ревью.
Из разряда «Код писал селёдкой пахло?», т.е. он подразумевает, что должно быть написано «вот так», а написано почему-то «так» и это уже ставит написавшего в оборонительное положение. Поэтому и ответ «по кочену» не то чтобы неожиданный.
Поэтому я обычно предлагаю либо посмотреть похожие куски кода с более коректной реализацией, как пример, либо начинаю немного из далека, чтобы прощупать поток мысли и понять почему так вышло, в большинстве слуаев это просто пробел в знаниях не фундаментальных, а локальных по проекту и не злой умысел или халатность.
«Как написал — так написал, переписывать не хочу».
Это ж классика! «Пилат же написал и надпись, и поставил на кресте. Написано было: Иисус Назорей, Царь Иудейский. Первосвященники же Иудейские сказали Пилату: не пиши: Царь Иудейский, но что Он говорил: Я Царь Иудейский. Пилат отвечал: что я написал, то написал.»
Но точно может быть, когда нужно пояснение про какое-то неочевидное решение.
Более того часто оказывается, что за счет того что человек использовал все модные паттерны он клал\не думал про общую архитектуру. В итоге несколько раз видел как после пары лет работы таких деятелей все их решения выбрасывались и переписывались с нуля, а сами деятели шли нести добро дальше рассказывая на собеседованиях как они переросли контору\коллег\здравый смысл.
Бывает и наоборот. Наняли снежинок с парой лет опыта багфиксов и уверенностью, что опыт и знания "не нужны". Товарищи просто фигачат линейно "from A to B" (=эффективность), злятся когда указывают на ошибки дизайна (они еще не научились делать A-to-B и дизайн одновременно). Злятся еще больше, когда не получается запустить кривульку и проходится переписывать, а времени на анализ опять нет — надо ведь фигачить, чего тут думать.
Самое веселое — не-программист хрен отличит одно от другого.
Какие именно ошибки? Как чинить будем?
Линейный код проще поддерживать и отлаживать.
Разные сложные решения нужны только в редких случаях. Типовые кейсы реально проще заткнуть чем-то простым вплоть до сайта на тильде вместо разработки мега портала.
Я допустим пишу на C# и занимаюсь вебразработкой и я не считаю, что должен знать JS. Отсюда все кто считает иначе посылаются далеко и на долго т.к. опыт показывает, что часто все эти гуру ничего кроме своих скриптовых языков не знают и в архитектуре не понимают ровным счетом ничего.
Я допустим пишу на C# и занимаюсь вебразработкой и я не считаю, что должен знать JS. Отсюда все кто считает иначе посылаются далеко и на долго.
Ну тогда я тоже в вашем формате попробую — идите в жопу с вашими советами.
Получилось? Понравилось?
Вы видимо реально плохо в разработке разбираетесь с такими рассуждениями.
Двумя постами раньше:
Это в 90% случаев ошибки менеджмента.
Так это ошибки разработки или менеджмента?
Бывает и еще более наоборот. Наняли снежинок с парой лето опыта багфиксов и уверенностью что опыт и знания у них "уже есть" и что "уже пора" — и начинают они делать код ревью. И — самое веселое — не-программист те отличит ни одного, ни другого, ни третьего.
На выходе остаются тонны неподдерживаемого кода, который правильным считает только сам автор.
Стандартная фраза любого программиста, который приходит на проект «Гавнокод какой то, надо всё переписать заново». Особенно это забавно, когда это его же код n лет назад (очевидно, что человек вырос и старое смотрится убого).
На что именно обижались получатели ревью, когда им указывают на ошибки и почему не сказали вам напрямую а пошли к начальнику? Взрослые люди редко обижаются на объективную критику.
Если слишком много проблем с качеством на этапе ревью, не означает ли это, что надо просто начать уделить немного больше внимания проектированию и синхронизации команды (чтобы делали в одном ключе)?
В основном были споры вокруг потенциальной поддерживаемости кода. Например, сделать код в общем виде, или оставить так, и потом зарефакторить. Шансы на то что это пригодится в будущем 50/50, поэтому возникали баталии
Взрослые люди редко спорят с объективной критикой. И многие этим пользуются. Мол, ну и что что я тебя криворуким назвал, объективно же, терпи))).
Взрослые люди редко обижаются на объективную критику.
Ложное утверждения. Значительно число взрослых людей, я бы сказал подавляющее большинство, но исследований не проводил, по этому значительное число, не способны воспринимать даже самую объективную критику.
Завернуть критику так, чтобы она была воспринята, это искусство по сложнее разработки, так же как воспринять адекватно любую форму критики.
Взрослые люди редко обижаются на объективную критику.
Так никто, надо полагать, и не обижался, просто люди не хотели тратить свое время на бесполезные вещи. Человек по скилам явно не тянет (видимо, джун, первый проект), при этом отвлекает постоянно. Вполне понятная реакция.
Вероятно, можно было бы сделать чище, но это проект уже с определенным легаси. Это нужно перераспределять ресурсы команды, тратить время и деньги компании. Чтобы… чтобы что?
Насколько это обосновано для проекта? Что скажут стейкхолдеры? Может быть не самое изящное решение, но сейчас, важнее для компании, чем идеально вылизанный код, но когда-то потом.
Попробуйте мыслить чуть глобальнее в рамках компании, тогда многое станет понятнее.
А вы зачем пошли туда где в офисе удобств никаких (ну улице что ли?...) и зарплаты невысокие? Для поднятия самооценки?
Я думаю понятие "глубинка" для IT это не та история)
Я не знаю. Однако, периодически работаю с коллегами из разных городов, слава удаленке.
Было бы неплохо это указать в комментарии, кстати.
А по теме - мой опыт общения с такими людьми говорит о том что они все же верно названы токсичными и ничего хорошего в проект не привносят. Если это не про вас - отлично.
Даже наоборот, руководитель привел пример, что все запросы клиентов удовлетворяются вовремя, коллеги довольны проектом.
Руководитель должен быть всегда примером, с которым не страшно пойти в бой
Руководитель это не командир полка, который ведет бравых разрабов в бой против заказчика. Руководитель это дипломат и менеджер, который видит что хочет заказчик и что хотят разработчики и налаживает между ними отношения, чтобы заказчик получал то, что он хочет, а разработчик то, что по контракту обещалось.
Не надо ваш личный опыт проецировать на все проекты.
В статье основной смысл в содержании код-ревью. Не здесь и сейчас исправь этот говнокод, иначе я тебе мозг сожру, а уважительное указание на наличие говнокода)
Я не знаю, где такому учат, но знаю, что если написать, что я не буду аппрувить твой говнокод, то 100% я буду токсичен. А если напишу, что тут эта фигня приведет к такой то проблеме или тут можно сделать лучше вот так, то процент гораздо ниже
"Чайка" — хорошая сказка.
Да, искушение представлять себя Д'Артаньяном Чайкой велико! Но проблема в том, что идеалистическо-романтическая парадигма вдребезги разбивается о реальный мир. Ну, потому что несовместима с его законами.
Почитайте "Затворник и Шестипалый". Это тоже сказка, но гораздо более жизненная.
Поэтому помимо насаждателя своей точки зрения. надо еще и проводить анонимное тестирования команды на предмет совместимости в коллективе.
А ещё у людей очень разные темпераменты. Можно иметь очень большой опыт и знания, но не желать портить себе настроение каждодневными агрессивными спорами.
Работал в неплохой компании, все отличные специалисты были, зарплаты были не высокие, хороший начальник, главное грамотный, который понимал как решать проблемы, команда работала сплочено, да и как человек просто золото, не конфликтный. Бывали споры, но все проходило в позитивном ключе. Был еще второй начальник — друг хозяина компании. Эти два начальника руководили проектами и развивали их. Хозяйин был неадекват, у него было 7 пятниц на неделю, к примеру согласовываешь проект, сдаешь что сделал за пару месяцев, а тебе в ответ все не так, переделывай, а до дедлайна осталась неделя. Или была девочка она перевыполнила план продаж за месяц в 5 раз по сравнению с другими специалистами, и ее лишили премии. Через пару месяцев она уволилась. В какой-то момент первого начальника руководство обидело, и основные специалисты вместе с этим начальником разошлись в дальнейшей стратегии развития, в итоге он ушел, а за ним еще несколько человек основной команды включая меня. В итоге, вскоре компания поплыла ко дну с другом хозяина начальником, а потом их за бесценок поглотила крупная компания, но прошло много лет, поглотившая компания сменила руководство и специалистов, повысила зарплаты, но так и не разгребла все проблемы… Важнее не экономика, а команда, если команда плохая и пассивная, то принципе ничего уже не поможет… В первую очередь все зависит от руководителя, и от комфортных условий для развития персонала, а если само руководство пассивное, то такие же сотрудники. Опросники показывают, что для людей более важны комфортные условия, чем зарплата. И люди предпочтут работу где комфортные условия, есть все для развития и ниже зарплата, чем ту в которой выше зарплаты и пассивные сотрудники. Это вам про экономику и содержание отдела.
А вот руководитель оказался очень даже профессиональным, потому что смог не просто указать на ошибки, а заставить автора самого понять, где он не прав.
Но нужно понимать, что с точки зрения бизнес-менеджмента то, что кажется адом разработчику, может быть приемлемой ситуацией: система в целом работает, затраты на поддержку в пределах бюджета, количество серьёзных жалоб от клиентов в норме. То, что где-то там внизу разработчики волками воют, менеджера не будет беспокоить до тех пор, пока не начнут увольняться.
Надеюсь, на момент этого случая вам было лет 25, не больше.
За старания лайк, но с картинкой я не согласен, все было не так
В подобных проектах впринципе обычно все жестко. Даже к форматированию придираются. Первый раз делают замечание, просят исправить, не исправляете в адекватный срок, отклоняют пул реквест, или если повезет кто-то перепишет правильно. Сломали коммитом что-то, по головке не погладят… Лично у меня было десятки раз, что даже отклоняли по совсем неадекватным причинам. Не конструктивность codereview решается банально за счет декларации как должен быть оформлен код, что можно делать, а чего нельзя. И в принципе должен быть опытный мейнтейнер.
Я работаю над apache cloudstack. Смотрите в моих статьях. И что? Культура review в oss куда дипломатичнее, потому что волонтеры, в отличие от нанятых за деньги, куда быстрее ногами голосуют. А вы работали?
Лично у меня было десятки раз, что даже отклоняли по совсем неадекватным причинам.
Ну как-то это не звучит "я работал над крупным... и мои mr отклоняли...". Может быть вы херню писали вот и отклоняли. Мы этого не знаем. Мой опыт говорит, что review в oss, поскольку русских там мало, очень нежный и компромиссный. А что насчет линтера, хидеров лицензий - это просто дисциплина на уровне нет разгильдяйству и не создадим юридического прецедента.
Ну то есть, вы начали "с крупных проектов", потом выбрали любой по своему усмотрению, который максимально подходил вам по точке зрения и привели его, распространив частное до общего.
Ну так дайте ссылку на https://lore.kernel.org/ с архивом предложенных патчей, если вы считаете, что мантэйнер был сильно не прав.
* Попытался исправить, помочь, направить, улучшить код
* Встретил сопротивление амебных некомпетентных исполнителей
* Не выдержал сопротивления, испугался, убежал поджав хвост
* Стал как все амебным некомпетентным исполнителем
Единственная причина, почему это произошло автор отец-одиночка с 2 детьми инвалидами на иждевении в ипотечной квартире. Других причин работать там не вижу. Через 3 года еле еле на джуна устроишься.
Если так будет продолжаться и дальше, то им придется со мной расстаться.
Такой поворот событий был огромным шоком для меня
У автора все закончилось нормально, но есть ситуации и хуже, когда не предупреждают, а сразу говорят «пиши по собственному». И критика не на уровне «тут можно написать немного лучше», а «вы совсем головой ударились, разрабатывать бек одновременно на двух фреймворках?! (и речь не о разных микросервисах, написанных на разных фреймворках)
И вариантов действий, в таких запущенных ситуациях, на мой взгляд, всего два (учитывая, как хорошо некоторые умеют врать и преподносить себя с лучшей стороны):
- После получения оффера сказать „мне все нравится, и я готов у вас работать, но дайте возможность взглянуть на код вашего проекта, например по скайп-связи, с расшариванием экрана“. Где можно будет взглянуть на уровень кода, который пишет команда, на тесты, на документацию, на CI/CD и пайплайны, попросить показать ревью (комментарии, обсуждения) мерж-реквестов и т.д.
- Иметь запас денег, который в случае кидалова на новой работе (вранье работодателя на собеседовании расцениваю именно как кидалово), позволит легко сказать „досвидос“, и спокойно поискать 2-4 месяца другую хорошую работу.
Очень классно, что во всей этой истории у Вас и руководителя получилось рабочее и конструктивное решение серьезной проблемы, респект обоим участникам процесса.
Забыл в каком фантастическом рассказе, но основная линия была в том, что федерация планет заподозрила, что человечество — токсичная цивилизация, и что надо их того.
Так вот, у них был офигенный фреймворк принятия таких решений (я себе перенял для борьбы с перфекционизмом). Если чего от себя придумал извините, но мне так больше нравится. Зацените:
- Судью, трансформированного в местного обитателя, посылают на планету, которую надумали exterminate.
- Судья находит подходящего местного обитателя, влюбляется, и живет вместе какое-то время в счастливых отношениях.
- В самый неподходящий момент приходит сигнал, и судья должен принять решение (став сперва полноценной частью цивилизации, которую надо приговорить).
- Если судья решает не нажимать кнопку, он остается на этой планете.
Когда во что-то веришь — надо быть готовым идти до конца. Если не готов — надо подумать, а так ли это на самом деле важно (и скорее всего забить).
Но ведь отдельно взятое существо, живущее в отдельно взятом месте может получить радикально разный опыт и сделать из этого разный вывод. Жизнь в гетто не тоже самое, что на рублёвке. Так что "мудрость" пришельцев в данном случае очень сомнительна.
я себе перенял для борьбы с перфекционизмом
Судя по тому что я все еще жив, кнопку вы не нажали, и на том вам и вашей избраннице спасибо!
"Антибиотик" Лукьяненко, если не путаю.
А вот очень похожая на сабж история была в рассказе «Мы не рабы» — с тем отличием, что Земля судила колонии, но грозило это в большинстве случаев не экстерминатусом, а серьезными ограничениями.
федерация планет заподозрила, что человечество — токсичная цивилизация, и что надо их того
Эталонное поведение SJW. «А нас-то за что?» (с)
Когда начал читать статью, думал прокомментирую: "Наивный автор, недавно устроился на работу на обычную должность, а ведет себя, как Senior на руководящей позиции."
Сам будучи на руководящих позициях, стараясь воплощать в жизнь перфекционизм, сталкивался с не пониманием высшего руководства по определенным вопросам. Тогда мне не так повезло, как автору с руководителями, но в итоге, и я путем жизненного тыка пришел к более сглаженным, мягким методам донесения мыслей и существования в рабочей среде.
Поэтому было приятно в конце статьи прочитать, как развилась судьба автора в конкретом случае, и в итоге порадоваться за нас всех)
Автор, спасибо, что поделились этой историей, пойду тоже подумаю, а так ли неправы те, кто называют меня токсичной)
В данном случае речь идет о корпоративном этикете и тактичности. На работе крайне важно поддерживать сплоченность коллектива, поэтому критиковать следует осторожно, не людей, а идеи. Например, «в целом решение приемлемое, но вот это и это я бы сделал иначе, вот смотри...» Обсуждение общего проекта — это сродни научной дискуссии, где мозговым штурмом ищут совместное решение. Умный руководитель обычно в таких ситуациях объясняет ситуацию новичкам, т.к. проблема общеизвестная, у профессиональных программистов (и других интровертов) в целом есть некоторые проблемы по части общения.
Мир open source это не работа, а скорее хобби и субкультура, с неформальной атмосферой. Поэтому там отношение к резким высказываниям более спокойное, поведение Линуса, например, вполне допустимо.
Сказал автор коммента «В чем проблема? Я бы пришел и поколотил его. Программистишки обычно трусливы, и с физической формой у них очень плохо.»
Если кого-то называют токсичным, то, возможно, так оно и есть.
Мир open source это не работа, а скорее хобби и субкультура, с неформальной атмосферой. Поэтому там отношение к резким высказываниям более спокойное,Да, так было еще лет 15 назад, но с тех пор мир вообще (и опенсорсный в частности) сильно изменились. Мне во FreeBSD приходилось сталкиваться с описываемыми проблемами, и я точно так же пришел к формуле «в целом мне без разницы, могу заапрувить и так». Это бывает непросто, особенно если вас действительно волнует качество какого-то кода, но, в конце концов, это всего лишь код, а ценителей ньюйоркского стиля с его bluntness и honesty нынче довольно немного.
поведение Линуса, например, вполне допустимо.Во-первых, Линусу прощается сильно больше других в силу масштаба фигуры, а во-вторых, даже он посчитал в какой-то момент нужным извиниться и взять тайм-аут, чтобы скорректировать своё поведение.
Ещё хуже, это если либо руководитель сам токсичный микроменеджер, либо ничего не понимает в теме и слепо доверяет мнению выскочки-душилы.
Вот тогда только или наверх идти, или валить.
Также я регулярно поднимал эту тему на ретроспективах и планированиях спринтов. Мне казалось очень важным обратить внимание коллег на эту ситуацию, и я сильно удивлялся апатии с их стороны.
Типичная ошибка человека, не видящего всей картины. Я тоже такой. :)
Дело в том, что разработчик видит только свой "участок фронта" - код. Но код - это не самое главное в бизнесе. Главное - клиенты, договоренности, сроки, издержки, планы начальства, красивые цифры в отчете, подковерные интриги и т. п. Разработчики о таких материях имеют довольно смутное представление, и это понятно.
Пример из жизни:
Есть огромный проект с кучей легаси. В коде проекта полным-полно директив условной компиляции. Директив очень много (десятки тысяч) и расставлены они автоматически - скриптом. Разработчик уверен, что 95% этих директив не нужны и что их можно сократить. Разработчик на 100% прав, но его инициативы вежливо отклоняются.
Причина проста: продукт уже прошел этап тестирования заказчиком и вот-вот будет отгружен. Сроки уже согласованы, договоры подписаны. Изменение тысяч файлов означает, что все тестирование нужно проводить заново, сроки поедут, по договорам придется платить неустойки и т. п.
Пример второй:
Проект средних размеров, но юнит-тестов в нем практически нет. Инициативная группа товарищей (для определенности - двое) пытается внедрить культуру юнит-тестирования: заводят на рабочей машине CI-сервер, настраивают на нем билды и проверяют все коммиты. Если коммит ломает сборку - система рассылает "письма счастья".
Почему-то инициатива не встречает понимания у товарищей. Руководители вообще занимают позицию "ну вы, конечно, для себя свою систему используйте, но от других ничего требовать не надо".
А причина проста: руководство знает, что наверху проект уже считается "не взлетевшим" и дело идет к его закрытию. На умирающий проект нет смысла выделять новые ресурсы (официальный билд-сервер для CI, джиру для багов сборки и т. п.).
Я попросил своего руководителя привести мне конкретные примеры токсичности в моем поведении.
Во-от, вот оно. Разработчик думает, что его не понимают из-за каких-то его личных отклонений. На самом деле вопрос надо было ставить иначе: а в чем причина того, что инициативы по ликвидации техдолга встречают с такой прохладой? Может, проект вот-вот сдают? Может, мы и так по срокам не успеваем и нам дай бог основной функционал доделать к сдаче? Или это вообще делается специально - этакий задел на будущее? Ведь пока мы правим баги, команду не разгонят.
Оказывается, если не настаивать на своем мнении, то у коллеги не включается чувство противоречия,
Это называется софт-скиллс. Не нужно идти на конфликт там, где от этого нет никакой пользы. Поэтому в англоязычных странах используются очень мягкие формулировки - could we please и все такое.
Вопреки популярному здесь в сообществе мнению "работу работать нужно, а не тратить время на эти бесполезные вежливые расшаркивания",
Это вовсе не популярное мнение. У людей, работающих в международных компаниях, уже давно есть понимание важности всех этих "расшаркиваний". Но вообще в русскоязычном IT-сообществе дуболомят часто, это да. Неспроста оно считается токсичным среди иностранцев.
Вообще, умение общаться с людьми, не вызывая у них негативных эмоций — это искусство, которое надо изучать и шлифовать.
Я часто встречал грамотных, квалифицированных специалистов в своем деле, которые совершенно не умели работать в команде — они всех считали тупыми неумехами, а себя суперзвездами. Только как правило получали ЗП эти суперзвезды меньше всех и от них избавлялись при первом же удобном случае.
На самом деле вопрос надо было ставить иначе: а в чем причина того, что инициативы по ликвидации техдолга встречают с такой прохладой? Может, проект вот-вот сдают? Может, мы и так по срокам не успеваем и нам дай бог основной функционал доделать к сдаче? Или это вообще делается специально — этакий задел на будущее? Ведь пока мы правим баги, команду не разгонят.
Так и есть это просто грязная и мерзкая манипуляция, которую автор принял и повелся на нее. Вот это токсичность, хоть и завуалированная. Жаль не все это понимают. Тут полностью с вами согласен. Все технические споры решаются только наводящими вопросами и уточнениями, пруфами, а не преходом на личности, и деланием человека неадекватом. Как только сменили контекст с технического на другой и перешли к личности, это кончились аргументы, и уже пошли грязные манипуляции против человека.
Со временем в команду пришли другие новички, тоже с идеей "надо все переделывать". Тут я и узнал себя со стороны и подумал: "наивные, еще не знают, во что они ввязались". Манипуляции не было, просто это занимает время осознать, как правильно подойти к переписыванию работающей продакшен-системы (не меньше года работы). В результате мне удалось переложить историю на язык бизнеса и продать её. Но это уже другая история, достойная отдельной статьи.
Дело в том, что руководитель хоть и выслушивал, но действий не происходило. Меня это не устраивало, и я продолжал накалять ситуацию. Тут важно заметить, что у кризису ситуацию привёл не один конкретный случай, а совокупность.
Самым лучшим выходом оказалось перевести разговор в текстовый вид. Это позволило закрепить текущее состояние и договориться об улучшениях
как правильно подойти к переписыванию работающей продакшен-системы
Если я правильно понимаю ситуацию, то это легко можно объяснить человеку, который готов слушать - это "операция на работающем сердце". Всё время операции система должна работать, причём правильно. Фазы тестирования, выведения в PROD занимают несколько недель (потому, что система должна проработать на beta неделю, ведь выходные отличаются по нагрузке от будних, а понедельник - от пятницы).
Поэтому, конечно, ряд операций (вроде форматирования кода) делается легко и ненапряжно, а ряд других операций - убирание условного кода очень тяжело.
-------------------------------------
С другой стороны, в других предметных областях скорость изменений может быть очень высока.
Тоже есть подобный опыт. Бывает, что коллега выкладывает на code review какую-то полную дичь. Где в классе вместо двух стандартных для подобной задачи методов isSupported / doSomething находится какая-то инициализация, хранение этого всего в свойствах и взаимодействие через 5 таких же кривых методов. На мои робкие попытки указать, что может стоит сделать как-то иначе, что-то улучшить следует стандартный ответ, что "это твое мнение, а у меня другое". И что делать в подобных ситуациях… Менеджер в коде понимает вряд ли больше.
На новом месте такое тоже может случиться. Сложно при устройстве на работу отследить такие вещи.
Вариант сеньора с хорошими софтскиллами: описать это в ревью, предложить решение (в общих чертах), завести под него багу с лейблом "техдолг". Потом, своим личным примером показать как надо – переделать на "нормальный" isSupported/doSomething. Ну и поднять тему "давайте везде делать так" на тиммитинге.
Если у вас нет преимущества в иерархии над автором исходного кода, то его решение как техдолг вы пометить не сможете, т.к. он его таковым не считает. И навыки аргументирования, конечно, развивать полезно. Но извне человека невозможно убедить, лишь он может принять вашу точку зрения.
Во так сделаешь какой-нибудь mock, чтобы потом было проще мерджить свою фичу. Реакция — избыточно и «слишком сложно», изменения откатываются без разговора, фича перепиливается. В итоге смотришь на свой коммит (который ты молча пилил), на репозиторий, и думаешь — а ну тебя в жопу, и возвращаешься туда, куда этот «сеньор с хорошими софтскиллами» добраться не может, а если ему так нравится, пусть дрючится сам.
А «сеньор с хорошими софтскиллами» еще больше убеждается в своей крутости, незаменимости и полезности, мол, пофиксил этого несмышленого коллегу.
Альтернативный вариант — написать «куда ты лезешь, говнюк, я не дебил и знаю что делаю, просто отойди и займись своими делами», но тогда уже тебя обзовут токсичным непрофессионалом, и это будет правдой.
Ну элементарное же манипулирование, основы, любой умный человек на Западе знает и умеет применять.
Но ведь можно сходить в Википедию и найти там соответствующее предложение с парой сносок на источники!
Спасибо, прочел с удовольствием.
Автору респект и уважуха.
Пока читал, зрела следующая мысль. Никто не любит чайка-менеджмент («прилетел-поорал-насрал-улетел»). Тем не менее, во всех конторах, где я видел код-ревью, оно или саботировалось (начальство думало, что оно есть, но по факту был просто лишний клик на аппрув в техпроцессе), либо вырождалось в чайка-менеджмент, только вместо одного чайка-начальника у тебя появлялось много чайка-коллег.
Я не знаю, это мне так (не)везло, или в код-серватории всё-таки проблемы? Самое лучшее, что видел (это было близко к моему идеалу), когда люди были адекватны и влезая в новую тиму сами просили взять над ними шефство. Такие, типа, «частные» код-ревью. Было, кстати, когда такой человек оказывался Коломбо: «Я, конечно, щас какую-нибудь глупость скажу...», а потом в шкафах скелеты обнаруживались, хе-хе.
P.S. Ага, слово «чайка» уже прозвучало в комментариях. Не дочитал.
Тут в соседнем посте рассуждают о том, что двор был лучшей школой жизни и социализировал на 10/10. А во дворе как: критика — предъява, нужно держать удар, иначе тебя раздавят. Так и живем. Жизненные привычки несовместимы с творческой атмосферой и больше воспроизводят атмосферу казармы. Со временем «твой код — говно» трансформируется в «извини, но твой код — говно», а затем — «не мог ли бы ты соизволить пофиксить свой говнокод?», и это считается большим прогрессом, практически объективной критикой, на которую нельзя обижаться.
Не знаю, по-моему, тут нет никакой связи. (Из своего опыта я её не вижу). Ну, например: у нас в одной команде был один... гопник дворово-социализированный элемент. Мужик в годах, кстати. Лет на 10 старше всех. Юмор, манера общаться — всё соответствующее. Так вот, он никогда не лез в чужой код и терпеть не мог, когда кто-то лезет в его. Между прочим, код он писал, мягко говоря, не тот, который хочется видеть. Но он тащил на себе супер-сложную задачу (типа, взять исходники Postgres и сделать на их основе новую СУБД для нашей платформы) и делал это хорошо. Ну, начальство поступило, по-моему, самым разумным способом в этой ситуации: просто заизолировало его проект и не лезло к нему. Пока он не дописал, гы-гы.
Напротив, в другом коллективе был такой мальчик: вежливый, с улыбочкой, но до того доставучий, и, главное, всё не в тему. Он не говорил: «Код — говно», он именно, что всеми этими карнеги-стайл-фишками оперировал. Проблема в том, что... эх, щас обидятся сказочные поняши... толку от него было, как от статического кодоанализатора. То, до чего он докапывался, БЫЛО ПРОБЛЕМОЙ ТОЛЬКО ФОРМАЛЬНО. Я бы предпочёл, чтоб мне по фене предъявили за то место, где ошибка в адресной арифметике приводит к порче памяти второго порядка (совершенно неотлаживаемая какашка), чем с тратить время на этого... вежливого лося. Короче, как в поговорке, «Хуже нет дурака, чем дурак с инициативой». Его опыт, кстати, хотели расширить на все команды, чтоб, значит, все мешали всем, но я это кино не досмотрел и чем закончилось — не знаю.
Ладно, давайте начистоту: я считаю, что код-ревью это подход к проблеме с неправильного конца. Когда ты лично несёшь ответственность за свои коммиты, когда в прод запушил какую-нибудь херню, а у тебя 10000 пользователей отвалилось (это у меня такое один раз было), ты сам начинаешь просить коллег посмотреть, проверить, разделить, тысызыть, с тобой ответственность, хотя бы моральную. При этом ты просишь, когда речь идёт о реально важных вещах. А когда какой-нибудь дурак, не разбирающийся в проблеме, над которой другой человек думает нон-стопом не первую неделю, лезет со своими «в гугле делают не так!» (ИМХО, одно из самых бесячих обоснований: гугл при разговоре не присутствует и сказать ничего не может, просто кто-то ссылается на его авторитет) — ну, см. текст статьи. Начальник правильно всё сказал автору. А формальные код-ревью просто по факту каждого коммита — это политика, поощряющая скорее второе, чем первое.
Но он тащил на себе супер-сложную задачу (типа, взять исходники Postgres и сделать на их основе новую СУБД для нашей платформы) и делал это хорошо.
Слышь пацанчег, это случаем компания не из тех, что даже толком копирайты на опен и либре офис не могут затереть и продвигают их «офигенный офис» в госреестр, чтобы протолкнуть в госзакупки и сделать деньги из воздуха? Эти компании даже в развитие софта и решение багов не вкладывали, и не возвращали часть кода опенсорс сообществу, чистое потребительство. Есть которые возвращают, но было несколько компаний именно таких. Про эту пару лет назад писали на нескольких ресурсах на тему импортозамещения… Очень похоже на одну из них и контингент соответствующий…
Там же стояло слово «типа». «Типа» значит «задача такого же уровня сложности». Чтобы, с одной стороны, не разглашать на публике подробности конкретного проекта (я считаю это неэтичным), а с другой — каждый мог оценить сложность. Нет, это не был Postgres (и вообще СУБД). Но по сложности похоже.
Я отвечаю на ваш (прямо скажем — не слишком вежливый) комментарий только потому, что разделяю ваше плохое отношение к тому, чтобы взять чужие исходники, а потом выдать их за свои, а тем более — получить на это госденьги. Люди, которые сделали т.н. «Фотон» (перебили копирайт в MultiEdit'е), мне глубоко отвратительны. Тем не менее, хорошо бы сначала было дождаться моего ответа, а потом изливать яд. Нет, в том проекте никаких госконтрактов не было, буква каждой лицензии была выполнена, и не было совершено ничего аморального.
А я вижу в каждом примере. Везде же одно и то же: репозиторий — это поле боя, а мы на войне.
Случай с молодым гопником из прошлого коммента: это тотальная война с ковровыми бомбардировками.
Случай с мудрым гопником, который уже подрос и силы уже не те: мой код — моя крепость. Позиционная война.
Случай с битым и затравленным гопником: это то, что я назвал «не мог ли бы ты соизволить пофиксить свой говнокод?». Пассивная агрессия, короче. Формально не докопаешься, но эмоциональный эффект тот же. Гибридная война, выбор 21 века.
В целом такой дворовой «человек человеку — волк».
А формальные код-ревью просто по факту каждого коммита — это политика, поощряющая скорее второе, чем первое.
Это политика, позволяющая максимизировать передачу информации между исполнителями. То, что при этом исполнители этот процесс превращают в поле боя — это нифига не здоровая фигня. Хотя как это починить я не знаю. Сам далеко не безгрешен.
Это политика, позволяющая максимизировать передачу информации между исполнителями.
...независимо от того, надо это или нет. Вот это и плохо (с моей точки зрения). Я за более гибкий подход и за передачу только той информации, которая нужна.
Выше я привел пример с переписыванием Postgres (на самом деле другого гиппопотама — видимо, надо это подчеркнуть, слово «типа» недостаточно). Не было бы ничего тупее со стороны любимого (кроме шуток — обожаю этих парней!) бывшего начальства, чем заставить, например, меня (или кого-то другого) ревьюить его правки. Что я мог там наревьюить? До имён переменных доковыряться? Нет, они заизолировали его проект и правильно сделали. Если бы я всё-таки был вынужден это ревьюить, я бы полгода только в тему вникал. Но я бы не вникал, я бы из такого дурдома уволился.
Тем не менее, мы друг друга периодически просили «просто посмотреть свежим взглядом». Или даже «поговори со мной об этом!» (кажется, это называется spiritual duck — был такой мем на StackOverflow, пока его не стёрли). Особенно, когда нужен был опыт (компетенция) другого человека. Зачем этот полезный поток информации забивать всем подряд — я не понимаю.
порче памяти второго порядка
Что это такое?
Допустим, вы аллоцируете под данные на 4 байта больше, чем нужно, а размер вписываете в начало буфера. Если в результате ошибки при работе с указателями вы запишете достаточно большое число (больше изначального размера) в середину этого буфера, это будет просто порча памяти. А если повезёт попасть в самое начало, то ваша порча памяти приведёт к тому, что при обработке данных (каждый элемент изменить по заданному правилу) будет перезаписана память за пределами буфера, т.е. порча памяти порождает порчу памяти следующего порядка. Не уверен, что термин общеупотребительный.
ты сам начинаешь просить коллег посмотреть, проверить, разделить, тысызыть, с тобой ответственность, хотя бы моральную.
Размазывание ответственности, во всех смыслах. Можно менее аккуратно писать код, товарищ проверит (плохо). Даже если случайно накосячил и это увидели, код будет правильнее и чище (хорошо). Ошибка прошла проверку и привела к аварии после выкатки — «это не только я виноват, но и кто проверял» (плохо).
Вообще, большинство проблем должно срезаться правильными тестами, и ревью только после автотестов… которые тоже надо писать и отлаживать.
Но тут ещё важный момент по реакции на прошедшие проблемы. Я вот сталкивался с тем, что даже за положенный стейж будет втык, и в этом случае «ревьюер» даже в большей степени нужен чтобы стрелки перевести если что. Стейж, который нужен именно для тестов и отладки. Ведь важно что? Чтобы проблемы не тронули клиентов, поэтому имхо правильно ПООЩРЯТЬ если удалось сломать тест — значит эта ошибка будет обработана и приняты меры чтобы этого не произошло с реальными клиентами. А свой контур — он пусть хоть 20 человек затронет, но это свои сотрудники, на лояльность клиентов к компании влиять не может, и большинство может совершенно безболезненно переключиться на другие тесты/задачи. А кого затронет, кто должен был строго со сломанным работать, тестировать например — в любом случае, мало кто работает на 100% эффективности, плюс любое действие и БЕЗдействие может стоить фирме куда бОльших денег. Бездействие — есть ошибка, про которую знают, но денег не хотели выделять, оно выстрелило, нужно тратить время и силы на исправление, уменьшение лояльности клиентов. Плюс нужны деньги на действие — исправление непосредственной ошибки (а не последствий выше), тесты, выкатки и прочее. Так что бездействие тоже может выйти боком, во много денег.
Куда меня понесло, и это только с 1 истории с одной прошлой работы…
Краткий итог — тестовые контуры нужно ломать, чтобы потом не ломался прод…
Размазывание ответственности, во всех смыслах.
Если размазывание ответственности в результате ситуативных (казуальных) code review —плохо, то что тогда сказать об обязательных code review на каждый пуш (как принято во многих местах)?
По-моему, держаться надо золотой середины. Что, собственно, я и написал.
Ну, начальство поступило, по-моему, самым разумным способом в этой ситуации: просто заизолировало его проект и не лезло к нему.
Так это худшее, что можно сделать! Теперь у них есть проект, в котором разобраться может только один человек. Что будет, когда он уволится? Почему нельзя было на этот проект, раз он такой крупный, выделить ещё хотя бы одного человека? Чтобы они работали вместе, друг-друга ревьювили, обсуждали технические решения и пр.
Я не знаю, это мне так (не)везло, или в код-серватории всё-таки проблемы?
Это вам так не везло (что не исключает проблем в консерватории, конечно).
Например, у меня прямо сейчас на работе практикуется код-ревью, и оно работает. Если что-то непонятно - просят пояснить за код, если где-то криво написано - просят исправить (с объяснением, что не так по мнению ревьюера). При этом к мелочам не цепляются.
Впрочем, это у нас коллектив здоровый. Бывали залетные товарищи, которые из код-ревью умудрялись устроить цирк с конями, но они надолго не задерживались.
Коллеги не всегда с ними соглашались, однако я не сдавался и настаивал на изменениях, потому что был на сто процентов уверен, что для проекта так будет лучше.
Точно лучше? Уверенность в своей правоте — не аргумент. Нужно уметь аргументировать свою позицию.
Порой споры принимали ожесточенный характер
Ожесточенные споры начинаются в тех случаях, где своим приоритетом вы ставите выплескивание накопившегося стресса на коллегу, а не получение положительных результатов в командной работе.
Свою позицию можно и нужно излагать четко и прямо. А для того чтобы к ней прислушивались, достаточно не переходить на личности и хотя бы немного постараться учесть сторону собеседника.
Сейчас например закрывается один проект который я сам начинал и вёл. Работает, мейтениться, функционала и расширяемости больше и дешевле второго проекта который нам втюхивают главная фирма после покупки нас и единственный аргумент почему мы мигрируем к ним, а не они к нам, это то что они уже втюхали туда в 10 раз больше бабла и не хотят признавать эту ошибку оффициально.
Так что сколько потраченных нервов и времени можно было бы сьекономить, особенно когда выясняли отношения с ФЕ говнокодерами из аутсорс фирмы.
Вы так говорите, как будто успех на рынке не зависит (или слабо зависит) от различного рода случайностей. К тому же более эффективная по совокупности компания вполне может проигрывать в какой-то из областей, в т.ч. и по технической части. Например, аналогичный продукт может требовать значительно больше ресурсов на поддержку и развитие, но быть лучше разрекламирован и пр.
немало технического долга, который меня сильно расстраивала остальных, видимо, не расстраивал. По всей видимости, никто не видел никакой проблемы, и этих людей было заметно больше чем один автор. Более того, когда автора попросили формализовать проблему, это закончилось тем что
но в итоге так и не смог привести внятного и весомого аргументаТак был ли вообще какой-то объективный техдолг?
Короче говоря, мне кажется что автор просто был юн и горяч, и его мнение по многим вопросам казалось ему самому очень важным, и он доставал этой «важностью» всех окружающих.
Хочу резюмировать комментарий вопросом, а почему вообще люди считают своё мнение заметно значимым? И часто более значимым чем мнение коллег.
а почему вообще люди считают своё мнение заметно значимым?
Потому что "Один я умный в белом пальто стою красивый". По ссылке есть попытка разбора, почему так получается, а в комментах хорошая фраза:
Мы все отлично понимаем, что намного умнее и лучше других людей. Важно никому об этом не говорить!
Респект автору, что умеет работать над ошибками. Редко встречал людей, анализирующих свои взаимоотношения с другими, а не встающих в позицию Д'Артаньяна. На последней работе два человека так закончили увольнениями.
Мне повезло сначала увидеть со стороны (на примере первого), как выглядит «токсичный» код-ревьювер, так что когда сам начал ревьювить код, уже мягче подходил к процессу. Так ведь на самом деле лучше работает.
Удивительный пример конструктивной работы над собой. На моей памяти такого четкого поворота никогда не было. Можно было на время погасить конфликтного коллегу вежливой (без сарказма) беседой, но через неделю другую случались приливы и дальше шло опять по-старому. Одного парня удалось понаблюдать в работе в новой команде на совершенно другом проекте. Он был помягче, но высокомерие и нетерпимость остались.
Что-то мне кажется, что история эта выдуманная :) в ней все персонажи очень положительные :), все действуют, на первый взгляд, правильно, но… Очень много вопросов возникает о таком персонаже как "руководитель". Такое нейтральное название — руководитель. Кто он, чем занимается, какая его реальная роль — не ясно. Он грамотно ответил, и разрулил проблему, но… при этом полностью игнорировал проблему до этого. Это как-то не сходится. Ну и некоторые использованные слова как-то плохо ассоциируются с простым разработчиком :)
Я так понимаю и бурное обсуждение вызвано именно нереальностью истории :)
С практической точки зрения, в подобной ситуации поможет хороший тим/тех лид.
История о том, как миддл стал сеньором
Кто-то написал неподдерживаемый код или сдублировал или устроил мэджик намбер — пресекать. «Перенесите это в переменную, это антипаттерн».
Кто-то назвал переменную не как вам больше нравится или поставил пустую строчку — пускай. Еще лучше какой-нибудь автолинтер прикрутить. Есть правило в автолинтере — линтер или автор сам исправит без ревью. Нет правила — значит либо добавляем после согласия и buy-in команды либо забиваем болт.
Тут-то до меня и дошло – смысла поднимать эту тему на митинге не было вообще никакого, потому что обсуждавшиеся там планы лишь слегка пересекались с нашим техдолгом и мое внимание к ним просто зря потратило время всех участников
А вот здесь возникает вопрос, почему совещание не модерировалось. Нужен кто-то, кто будет жестко удерживать собравшихся в рамках заранее определенной темы. Почему человека не остановили в самом начале, сказав, что поднимаемая им тема не относится к заранее заявленной?
Чтобы определить, является дискуссия оффтопиком или нет, нужно сначала дослушать выступающего до конца. А это уже отнимает время. Роль модератора полезная, но недостаточная, нужно еще и само-модерацией заниматься.
Чтобы определить, является дискуссия оффтопиком или нет, нужно сначала дослушать выступающего до конца. А это уже отнимает время.
Смотря, что человек говорит. Обычно не нужно слушать совсем до конца, чтобы понять, что именно человек хочет сказать.
Роль модератора полезная, но недостаточная, нужно еще и само-модерацией заниматься.
В идеальном варианте — да, но не всегда получается. Если человек действительно увлечен излагаемой идеей, и считает ее важной, то он вполне может потерять контроль.
технический прогресс последних десятилетий вытеснил более «староверческие» навыки типа риторики, чувства собеседника, ощущения своего положения в социуме, умения свободно высказать свою точку зрения по вопросу предполагающему более чем одно верное решение.
благо ваш руководитель оказался достаточного скила чтоб погасить конфликт и одновременно перевоспитать вас сохранив на рабочем месте. не всегда это удается.
Я ожидал что-то вроде, «у меня были токсичные коллеги и вот к чему это привело...»
Ну или «да, я понял, что я был в некоторой степени токсичный, и меня уволили, но у меня были к этому следующие серьезные основания...»
А тут вообще другая тема. Рад за всех — и за автора и за начальника и за коллег :)
Статья простая, но вместе с тем очень годная. Вынес даже для себя некоторые вещи, которые в пылу рабочих дней совсем не очевидны.
Если патчеписатель хочет, чтобы патч приняли — он спокойно воспринимает критику, правит код, спрашивает совета, обосновывает свою точку зрения. К патчу может быть овер 100 комментариев и они все в спокойном конструктивном тоне.
За шесть лет наблюдения за проектом я видел всего ОДИН случай, когда патчеписатель требовал, чтобы патч его был принят, в достаточно грубой манере. От него все отвернулись, патч был просто заигнорен разработчиками. Правда потом случилось смешное и патч был принят все же, потому что оказался корректным сам по себе.
Ну а то, что начальник из статьи оказался ОЧЕНЬ грамотным начальником и весьма достойно разрулил ситуацию — это редко бывает.
Если патчеписатель хочет, чтобы патч приняли — он спокойно воспринимает критику, правит код, спрашивает совета, обосновывает свою точку зрения.Всё так. На этом этапе он вынужден воспринимать критику, иначе его патч не примут. А дальше бывает по-всякому. Например, если чувак регулярно засылает в целом годные патчи (пусть не особо вылизанные, но он охотно их причесывает по просьбе ревьюера, или коммитер сам их приводит в надлежащий вид), то в какой-то момент чуваку могут дать коммит-бит, приставив на первых порах ментора. Часто бывает, что ментор ревьюит патчи вполглаза, а вскоре и вовсе дает automatic implicit approval. На этом этапе толерантность к критике у чувака обычно снижается, в том числе и потому, что теперь ему не требуется благосклонность ревьюеров — он уже коммитит свои патчи сам, без посредников. В худшем случае такой чувак сам становится ментором для новобранцев, посредственным и не умеющим привить им должную культуру разработки. Конечно, бывает и по-другому, но я немало повидал таких чуваков, не заинтересованных в улучшении своего кода и при этом болезненно воспринимающих практически любую критику или игнорирующих её вовсе.
Как менеджер с большим стажем, позволю себе дать небольшой совет.
Дело не в том, что люди обидчивы. А в том, что никто не видит всех нюансов целиком. А частный исполнитель не всегда понимает всю конечную задачу.
Поэтому возражения стоит высказывать не в духе «надо делать вот так», а «я тут вижу такую-то проблему с такими то последствиями». Потому что, во-первых, проблему чаще всего видите не вы один, и у такого положения дел есть свои причины. Во-вторых, если проблема и правда есть, человек сам исправит её, чаще всего лучше и правильнее, чем вы предлагаете. Советы давать можно, но советы, а не указания. Ну и, в-третьих, не переставайте фокусировать людей на конечной цели. Это вносит осмысленность в частные задачи, и позволяет всем не увязать в частностях.
Ещё раз: не говорите как делать, а указывайте на проблему и последствия. Это придаёт переделке смысл. «Так неправильно» это не указание на проблему.
После прочтения статьи понял только, что руководитель у ТС хороший.
Все думал, почему же автор однозначно идентифицируется как малолет... молодой и горячий неопытный разработчик. Все просто: даже не сделана попытка понять, почему на проекте все так а не иначе, пропущена фаза "попросил колег рассказать мне подробнейшим образом почему...".
senior: нужно добавить Фабрику Декораторов Фасада
Надоели все эти ревью и прочий бред.
— и когда джуниоры, еще студенты, только прошедшие лабу, приходили на проект со словами «там такоооой говнокод, там такооое, все надо переписать». А сами прочитали две книжки, но if с else еще толком связать не могут, а ЧСВ выше крыши;
— и когда приходишь на проект себе тихонько и через 2 недели понимаешь, что с существующей «архитектурой» самое малейшее изменение требует от тебя 2 дня багфикса с залезанием во все детали, а от QA — регрессию как минимум всего моделя. И что команда состоит на 80% из людей, которые фиксят баг перерисовкой всего экрана при сдвиге на каждый пиксель, не видят ничего в 30-ти синглтонов, беспорядочно дергающих методы друг друга, и broadcast notification-ах.
И самое интересное, что руководство все это устраивает. Потому что распил. Потому вместо 8 iOS-девелоперов хватило бы двух но толковых, но за 8 платят больше. Потому что даже так как-то, со скрипом, но проект заработает, а американское лобби продвинет его во все заправки штата Техас. И всем все равно.
Что я могу сказать? Универсального совета тут точно нет, нужно смотреть через призму своего опыта в каждом случае отдельно.
Лично я на первых не обращаю внимания — нужно просто холодно попросить список вещей, которые малыш видит как говнокод, с аргументацией почему он так считает и путями решения. 5% что-то сделают, 95% умерит свой пыл на первом же реальном кейсе. У малыша просто нет опыта, чтобы понять, почему люди писали так, а не так как написано в той классной статье — в той или иной степени все это проходили.
Во втором случае я не вижу причин не уйти, если там конечно не зарплата в 10к долларов чистыми и страховка в Принстон Плейсборо. И квартиры дают бесплатно. Тогда можно сидеть и терпеть. Но какой смысл бороться с ветряными мельницами? Пусть и правда сидят так дальше, раз всех все устраивает. Да, таких проектов даже большинство, ну и что, есть армия любителей таких проектов.
У меня есть знакомый, который на них специализируется. Устраивается на удаленку на не самую топовую зарплату на такой распил — там на 2.7к, там на 3.0. Работает там 2 часа, там 2 часа, единственная проблема — митинги иногда пересекаются. Но это всегда можно как-нибудь разрулить, тут уже хочешь жить умей вертеться. Как вам зарплатка в 5.7 чистыми в Брестской области в каком-то там сельсовете? И плевать он хотел на чистоту кода и архитектуру, лишь бы появиться на дэйли, каком-то еще митинге и сделать 2-3 коммита для потемнения ячейки в профиле гита.
Что-то меня понесло. В общем, я понял что для меня это не близко, надоело за джуниорами и просто не думающими людьми подчищать экскременты, и просто стал просить на собеседовании показывать код. Но в итоге просто нашел место, где нужно было потратить около месяца на доводку старого проекта, и новый стартовал с нуля — с плотной работой с графикой, звуком и всем что я люблю. И по-своему счастлив.
В общем, ищите свое и держите нос по ветру. Самое главное — понимать, чего на самом деле хочешь. Всех денег не заработаешь, а счастливы на работе единицы. Я иногда бываю счастлив. Это куда лучше чем у 90%.
Сам был новичком и обычно ошибки от недостаточного опыта и знаний чем от лени и злого умысла (что больше про опытных), да и учиться нужно многому, всё с первого раза не запомнишь. Но с нескольких повторов уже сами обычно начинают понимать и код всё лучше.
А ещё можно давать на рефакторинг их же код через месяц+, я тоже свой старый код иногда читал — ну и ерунда тут… Но работало.
Прежде чем что-то бежать менять нужно вникнуть в проект и понять всю его боль… бежать что-то менять после 2-х недель на проекте — это как-то опрометчиво.
Чтобы что-то явно менять — нужна явная санкция менеджмента, рефакторинг, тесты, качество кода на ревью — это всё про время, у менеджмента должно быть явное понимание на что мы тратим время и почему, поэтому, то, что менеджер в этой истории занял такую позицию — понятно и очевидно, пришел странный чувак — чего-то хочет, чего-то выступает.
Путей разрешения несколько, вариант первый — и самый логичный, искать другую команду, а не воспитывать эту. Работать надо единомышленниками, которые считают, что нормально — это убить 1.5 дня на рефакторинг перед выполнением задачи, которые перед комитом смотрят warring-и компилятора, у которых стоит плагин для sonarCube, смотрит цикломатическую сложность кода и не дает комитить явную фигню.
Должен быть devops — и внятное CI, отчеты sonarCube и кодопрокрытия тестами. Развиваться лучше в рамках такой команды.
Можно в текущей команде заработать авторитет и сделать так, чтобы тебя слышали и уже всё выше перечисленное внедрить здесь и сейчас, но не каждый проект даст с собой такое сделать в силу объективных по бизнесу причин. Но это тот ещё путь самурая. Я был в командах, в которых тесты писал я один, остальные фигачили как придется.
По подходу выше, отсутствие тех же тестов ни является критикал, т.к. всё же и так работает, а по-моему оно всё ломает, т.к. теже тесты определяют архитектуру решения. Хотя речь не только о тестах, тесты как пример. Даже подход работать хорошо в своем месте и никому на мозги не капать — не очень хорошо работает. В моем случае — находились люди, которые меняли мой код, получили упавшую сборку в CI (т.к. локально тесты никто не запускает), и тупо удаляли тест, который не работал. Короче, всё очень сложно.
Итог, заработать авторитет можно, возможно, даже тебя слушать начнут. Но без санкции менеджмента это всё равно гиблое дело, т.к. слишком много задач, которые нужно делать здесь и сейчас, а работы на перспективу сложно согласовать. На выходе, я лично размазывал эти работы по своим текущим задачам. Но и такого тоже на долго не хватит.
Все правильно, уметь договариваться и сдавать назад иногда - гораздо важнее чем тупо гнуть свою линию. Soft skills решают.
Между прочим, токсичность, агрессивность и раздражительность очень сильно коррелируют с депрессией, мне всегда жалко "плохих" таких людей)
потому что благодаря их активной позиции делаются те вещи на которые остальному большинству просто наплевать, и этот хвост долгов будет тянуться бесконечно….
Необязательно быть токсиком, чтобы указывать на проблемы. Можно это делать и более тактично
конечно необязательно)
но только нетоксики чаще всего не делают это - либо из лени, либо из излишней вежливости…
именно поэтому акционеры зачастую умышленно вводят токсиков в вялые команды… В этом смысле не надо путать тимлидов с акционерами. У тимлидов и акционеров чаще всего расходится подход к правильному ведению проектов. Именно поэтому первые обычно «просто умные», а вторые обычно «просто багатые» ))
Ну там и помимо этого «странностей» хватало, вроде авторитарного руководителя, который превратил утренние митинги в краткие рапорты с публичным разносом перед строем, по старым «добрым» армейским традициям (по этой причине я оттуда довольно быстро и свалил, несмотря на интересный проект и стек)
Если текущая версия не содержит каких-то фатальных багов, от которых развалится продакшен, то настаивать на своих комментариях не нужно.Поэтому мы и окружены продуктами, которые в целом работают, но оценку 5 баллов им почти никто из пользователей не ставит.
Можно подумать что пользователи проводят тщательные кодревью, перед постановкой оценок. Оценки зачастую такие неадекваты лепят.. что-то вроде: "прога ничетак, но у меня что-то после вчерашнего бухача башка раскалывается, потому больше двух не поставлю..". В итоге всем программа нравится, а вот общая оценка уже не пять звезд, а меньше.
Как меня чуть не уволили из-за токсичного поведения и что было дальше