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

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

Люди слушаются лучше, если вы относитесь к ним с уважением.

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

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

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

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

Но, к сожалению, он просто не может успокоиться в этом вопросе. Он постоянно подрывает мой авторитет, требуя, чтобы мы делали все по учебникам (например, по книге Джошуа Блоха «Эффективная Java») даже в тех случаях, когда это было бы пустой тратой нашего времени и не принесло бы ощутимой пользы для нашего продукта. Как я могу заставить этого младшего разработчика доверять моему опыту?

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

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

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

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

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

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

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

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

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

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

«Привет, я заметил, что мы не внедрили здесь хэш-код, есть ли для этого причина?»

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

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

Просмотрев код, я обнаружил проблему и написал тест X, демонстрирующий ее.

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

У вас есть утренние стендапы? или какие-то другие групповые встречи, на которых вы можете неформально упомянуть об этом.

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

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

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

1. Отделите код от его автора. Вы здесь, чтобы оценить первое, а не второе. «Этот код [X]» лучше, чем «Вы создали этот код [X]».
2. Быть конкретной. Не давайте расплывчатых описаний всей кодовой базы. «В X, Y и Z были бы признательны описательные комментарии относительно формулировки этой функции» гораздо ценнее, чем «Для меня это все по-гречески».
3. Будьте и вы на позитиве! термин для этого процесса — «проверка кода», а не «вербальная разделка кода» по какой-то причине. В большинстве опубликованных обзоров рецензент будет говорить как о хороших сторонах продукта, так и о плохих. Вы должны сделать то же самое.
4. Выбирайте свои сражения. Не относитесь ко всему как к нарушению условий сделки. Если это немного странно, но работает отлично, дайте ему в лучшем случае сноску и назовите его «незначительной проблемой» или «быстрым вопросом». Вообще говоря, если вам нужно открыть отладчик/декомпилятор, чтобы создать сценарий поломки, это не считается чем-то серьезным.
5. Убедитесь, что вещи, о которых вы говорите, не являются «теоретическими». Протестируйте приложение самостоятельно или поговорите с группой тестирования о том, что, по вашему мнению, может быть проблемой.

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

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

Выберите свои сражения

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

Будьте осторожны с дифференциалами превосходства

...когда ты младше, а они старше. По трем причинам:

1. Боссы (при условии, что старший разработчик имеет власть над ОП) обычно не любят, когда их поправляют их непосредственные подчиненные. Я не говорю, что так должно быть, но такова природа человека.
2. Старшие разработчики (включая меня) понимают, что им нужно больше работать, чтобы идти в ногу с младшими разработчиками, когда дело касается их знаний и технических навыков. Они могут быть очень чувствительны ко всему, что подкрепляет этот факт для них, например, когда их выставляют напоказ (особенно случайно снисходительно) младшие разработчики. Опять же не говорю, что так должно быть, но люди есть люди.
3. Старшие разработчики часто привыкли иметь дело с младшими разработчиками, у которых есть фишка на плече: они думают, что они гениальны, а старшие разработчики — дураки и позёры, и которые всегда ищут возможности, чтобы прояснить это. Так что, даже если вы не один из этих младших разработчиков, если вам покажется, что вы делаете то же, что и они, вы можете получить ту же реакцию, что и они: оборонительную позицию и крайнее недовольство. Опять же, это не идеально, но поставьте себя на место старшего разработчика.

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

Что делать в следующий раз

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

Супер хороший вопрос. Я люблю учиться, но когда кто-то оскорбляет меня, я чувствую, что должен бросить это дело. Я рекомендую проверить «стиль кодирования» ваших коллег и определить его сильные стороны, чтобы он не чувствовал, что все время, которое он потратил на обучение, было бессмысленным. ТОГДА ОПРЕДЕЛИТЕ ВОЗМОЖНОСТИ. Таким образом, вы демонстрируете сильные стороны в будущем, которые помогают компании, а также работают над теми «возможностями», которые вы уже определили. Я руковожу командами, предоставляя график на 30-60-90 дней, а затем хвалю изменения, в которых мы извлекли выгоду из «возможностей». Это работает очень хорошо и является справедливым способом идентифицировать лидеров и людей, которые не являются и не должны быть лидерами.

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