Как я могу иметь дело с коллегой, который не особенно заботится о качестве кода?

Должен ли я обсудить это с руководителем моей группы?

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

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

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

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

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

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

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

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

вещи, которые не должны быть на нашей основной ветке, на мой взгляд

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

Расплывчатые утверждения вроде «это делает код более читабельным/поддерживаемым/тестируемым/и т. д.». (или, что еще хуже, «такой-то и такой-то рекомендует») никого не убеждает изменить свои испытанные методы.

Помните, что «плохой» кодекс ваших старших выполнял свою работу целую вечность. «Выполнение работы» — одна из самых важных вещей в бизнесе. Рассказывая людям, что есть лучший способ выполнить работу, опираясь только на ваше «мнение», вы не убедите их пойти на риск.

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

В качестве дополнительного совета я надеюсь, что вы не будете использовать тон, который вы использовали в этом посте, когда намереваетесь убедить своих старших. «Ха-ха, вы, ребята, отстой, я научу вас, как это делается» определенно не сработает, «У меня есть предложение улучшить X, и я думаю, что это причины, по которым это принесет нам пользу. Что вы думаете?» имеет гораздо больше шансов быть принятым.

Я испытал это в моей предыдущей компании. Это не закончилось хорошо.

Мы вдвоем писали код, а старший коллега был большим поклонником копирования и вставки программирования. («Помните, с этим проблем нет».) Один и тот же блок кода был разбросан примерно 50 раз по кодовой базе, следуя одному и тому же мыслительному шаблону. Я мог бы жить с этим, хотя мне это не очень нравилось. Нулевые проверки через try...catchс пустой обработкой исключений были обычным явлением. Через некоторое время я начал рефакторить этот материал, и мне сказали, что я мешаю работе, потому что после изменений он больше не может программировать «по памяти», полагаясь на старую структуру. Несмотря на качество исправлений и устранение многих ошибок, мне сказали: «Я повредил код», потому что в бизнесе никто не заботится о мелких проблемах с кодом, и единственным критерием является выполнение работы за минимальное количество часов и удовлетворение клиента. Работа с кодом приводила к моему неудовлетворению, и я также пропускал дедлайны, не имея возможности «копировать-вставить» достаточно быстро, потому что я чувствовал, что не хочу становиться таким «быстрым и прямым программистом», каким я должен был быть.

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

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

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

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

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

Да, это то, что вам нужно (даже если вы думаете, что не сможете).

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

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

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

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

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

По поводу поста Человека в маске:

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

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

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

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

В-третьих, старайтесь концентрироваться на слабостях, которые имеют ощутимые проявления, а не зацикливаться на том, «как, по вашему мнению, должен быть написан хороший код». Избегайте субъективной критики (нет двух программистов, согласных во всех аспектах хорошего стиля). Сконцентрируйтесь на тех областях кода, к которым у вас есть законный интерес. Пишите тестовые примеры, которые терпят неудачу, и регистрируйте ошибки в них. Добавьте комментарии или TODO к коду, например «Здесь необходимо обработать сбой ввода-вывода».

Вы говорите , что строго следите за качеством кода, но не несете ответственности, так что с точки зрения компании это не имеет значения.

Важна позиция компании в отношении качества кода.

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

Если в отношении этого нет строгой политики компании, единственное, о чем я бы даже подумал (с вашим коллегой или руководителем), это то, что, вероятно, привело или приводило в прошлом к ​​взлому кода.

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

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

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

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

Исходя из слов опытного программиста, все, что вы говорите, в идеале следует избегать, но ни одно из них не обязательно относится к фразе «МЫ ВСЕ УМРЕМ!» строгость. Игнорируемые исключения или отсутствующие проверки null могут иметь катастрофические последствия, но иногда они могут быть функционально ненужными или намеренно опущенными. Именование классов вообще не влияет на выполнение на любом известном мне языке (несмотря на отражение) и, таким образом, гораздо менее серьезно, чем вышеупомянутые проблемы, которые могут вызвать проблемы во время выполнения, а также, как правило, полностью основано на мнении.

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

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

Ввести обязательные проверки кода.

Вы не в том политическом положении, чтобы просто требовать такого изменения политики, но вы можете предложить это другим членам команды и получить их поддержку. Как только значительное большинство из вас согласится, обсудите это с большей группой. Вот веская причина, почему вы должны их делать: https://www.atlassian.com/agile/code-reviews

Наш офис делает это, и мне это нравится.

Это поучительный момент

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

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

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

PS Я предлагаю вам не настаивать на немедленном ответе и быть готовым оставить все как есть.

Хотя качество кода должно быть важным, оно должно рассматриваться в контексте ожиданий руководства и уровня навыков членов команды. Желание стать лучше в этой области — это хорошо, но сосредоточьтесь на проблемах, а не только на симптомах.

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

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

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

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

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

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

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

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

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

* Я шучу.

Никто не любит болтунов.

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

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

Время отсеет тех, кто не увлечен своим делом.

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

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

Должен ли я обсудить это с руководителем моей группы?

Да.

Однако, прежде чем сделать это, прочтите и убедитесь, что вы поднимаете правильный « this ».

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

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

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

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

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

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

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

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

использованная литература

• Улучшение процесса проверки программного обеспечения с помощью шаблонов (pdf)

• Процесс разработки персонального программного обеспечения SEI: самосовершенствуйтесь