В какой момент «конструктивная» критика вашего кода становится бесполезной?

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

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

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

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

Я чувствую себя действительно выделенным и разочарованным в этой ситуации. Мне стало намного лучше следовать ожидаемым стандартам, и я разочарован тем, что, например, когда я реорганизую часть кода для проверки ошибок ADD, которая ранее отсутствовала, мне только сказали, что я этого не сделал сделать ошибки достаточно многословными (и ветвь была отклонена на этом основании). Что, если я никогда не добавлял это для начала? Как он попал в код для начала, если это было так неправильно? Вот почему я чувствую себя настолько выделенным: я постоянно сталкиваюсь с существующим проблемным кодом, который я либо имитирую, либо реорганизую. Когда я имитирую это, это «неправильно», и если я рефакторину это, меня упрекают за то, что я недостаточно делаю (и если я иду весь путь, внося ошибки и т.д.). Опять же, если это такая проблема, я не понимаю, как любой код попадает в кодовую базу,

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

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

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

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

Похоже, что между вами и руководителем команды может быть непонимание. Для вас может быть полезно попросить о встрече с ним один на один и обсудить, что вы можете сделать, чтобы улучшить ситуацию. Вы можете привести что-то вроде: «Я чувствую, что мне все еще не хватает многих нюансов того, что я должен делать. Как младший разработчик, я хочу расти и совершенствоваться. Можете ли вы помочь мне в этом?» и посмотрим, что получится.

Звучит так, как будто вы воспринимаете это слишком лично. Не; такого рода вещи случаются постоянно.

Причины отказа от регистрации (именование переменных, качество комментариев, расположение конфигурации) кажутся мне достаточно стандартными.

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

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

Дополнение к другим ответам:

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

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

Новые парни, как и вы, OTOH, обычно жаждут руководства и знания, что правильно, а что нет. Кроме того, они могут поглощать обратную связь и изменять свои пути к лучшему. Они не установлены по-другому.

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

Так ...

... возможно, вы получаете больше отзывов только потому, что у вас есть потенциал, чтобы что-то из этого сделать. :)

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

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

Решение простое:

• Если это стандарт, следуйте ему.
• Если вы не понимаете стандарт, попросите разъяснений.
• Если ваша интерпретация стандарта или инструкций отличается от руководства группы, попросите разъяснений

Не делайте из этого битву; если вы попытаетесь заставить команду вести себя «неправильно», то даже если вы выиграете, вы проиграете. Выучите соответствующий урок и продолжайте расти.

Примечание автора

Несколькими годами позже; Я отредактировал это, чтобы более точно отразить, что я чувствую к ситуации. Я добавляю больше нюансов в свой ответ, потому что я больше узнаю о нюансах в этих ситуациях. Легко требовать «черного или белого» ответа, но мы все знаем, что это не так просто. Мой ответ теперь отражает это.

Из того, что вы описали; поведение, которое вы испытываете, никак не связано с вашим полом. Это не значит, что вы не подвергаетесь лечению по половому признаку (надеюсь, что нет), только то, что вы описываете, похоже, не связано с полом.

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

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

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

Теперь к вопросам, которые вы подняли:

Вы зарегистрировали код, который не соответствовал установленному им стандарту, поэтому он отклонил вашу ветку. Если бы я был на его месте, я бы не сделал то же самое таким же образом, но я бы позаботился о том, чтобы мои подчиненные (странное слово; потому что я не считаю лидера «превосходящим» людей, которых они вести, но он точно (неадекватно) описывает ситуацию) знает, что правильно делать. Если они не знают, каковы стандарты, это моя вина как лидера. Это до меня, чтобы исправить это. В этом случае вы, возможно, допустили ошибку, но сам факт того, что это произошло, означает, что вы либо 1) не сказали, что нужно делать, либо 2) не получили должного наставничества. Ни ваша вина.

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

Если ваша команда написала руководство по кодированию, следуйте им. Если они этого не делают, тогда должно быть какое-то соглашение сообщества для вашего языка (для .NET и C # у Microsoft есть стандарт, которому следуют многие компании).

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

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

Сказать «я доберусь до этого позже» - плохо. Позже никогда не бывает. Потратьте время, чтобы сделать это правильно. Там нет позже в программировании.

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

Нигде в вашем посте вы не упоминаете, как к окружающим относятся. Вы повторяете, что «чувствуете», что вас «выделяют», потому что вы «женщина».

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

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

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

Пожалуйста, перестаньте разыгрывать пол карты бесплатно . Я чувствую, что это недостойно и подрывает концепцию гендерного равенства.

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

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

Сделать это сделать сделать это правильно сделать это быстро

Так что, если ваш лидер принял решение отклонить ваш коммит, как профессионал он должен знать, чем он занимается.

Теперь я вижу, что в некоторых условиях это будет нормой. Тем не менее, критика не выглядит равномерно распределенной, что и приводит к моей следующей проблеме. Основой большинства этих проблем было то, что я находился в кодовой базе, написанной кем-то другим, и пытался быть минимально инвазивным. Я имитировал имена переменных, используемых в других местах файла. Когда я это сказал, мне прямо сказали: «Не подражайте другим, просто делайте то, что правильно».

Будучи младшим, трудно найти какой-либо путь в кодовую базу компаний.

Лучше всего: есть документированные стандарты кодирования - и вы, надеюсь, научитесь их контролировать.

Обычно: существуют недокументированные стандарты кодирования - и вы должны учиться методом проб и ошибок, или я должен сказать commit и _reject? Это часто бывает больно (как в вашем случае). Иногда это опасно с точки зрения качества кода и может привести к программированию культового груза , где нужно не только имитировать именование переменных, но и добросовестно копировать и вставлять структуры и шаблоны из базы кода, это должно быть сделано именно так. Не делай этого! Даже не копируйте существующие имена переменных.

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

И это приводит к другому (последнему) совету: следуйте правилу бойскаутов !

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

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

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

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

Причуды личности в офисе или на работе буквально бесконечны. Надеюсь, вы сможете узнать, кого избегать и когда избегать их. Также не будьте слишком строги к себе :-) Вы всегда можете бросить и найти другую работу!

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

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

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

Независимо от ситуации, вы должны взять под свой контроль и задать уточняющие вопросы. Будьте активны, если вы еще этого не сделали. Члены вашей команды и руководитель группы, скорее всего, будут уважать вас больше за то, что вы задали вопросы, чтобы уточнить правила регистрации. Вы также можете попросить «обзор после действия», где вы и ваша команда обсудите, что вы должны были сделать вместо этого и как вы может сказать разницу, насколько когда предпринять определенные действия, а когда нет.

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

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