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

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

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

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

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

Стоит ли продолжать настаивать на этом, особенно учитывая мое нынешнее затруднительное положение?

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

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

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

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

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

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

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

Пока вы исправляете свою среду разработки, записывайте все одноразовые шаги, которые вы вряд ли вспомните через несколько месяцев. Например: "Install [Tool] [Version] into [Folder]", или "Create an Environment Variable called [Name] set to [Value]", или "edit [Configuration File] and change [Line] to [Something else]", и т.д.

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

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

Проблема в другом: как вы говорите на вашем ПК он не компилируется, а на его системе все работает нормально.

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

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

Удачи

Ищите исправление, которое работает на обеих установках

Общий принцип в подобных ситуациях — правило скаута :

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

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

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

• Ускоряет разработку, отладку и/или развертывание.
• Он включает в себя функции, которых нет в других установках.
• Он имеет дело с обратной совместимостью, необходимой для взаимодействия с другими модулями.
• Переход на другую настройку может потребовать значительных усилий, чтобы остальная часть кода по-прежнему работала должным образом _(*) .

Плохие причины для этой настройки могут быть ...

• Лень или иное иррациональное сопротивление поддержанию среды разработки в актуальном состоянии («У меня все работает, я не буду ее трогать!»)
• Предвзятое отношение к более новым версиям как «непроверенное, поэтому небезопасное».
• «Мы всегда так делали»

Что вы можете сделать здесь, так это спросить своего старшего коллегу : «Почему вы используете это? Есть ли конкретная причина?». И они вам скажут. Может быть, их причина будет — по вашему мнению — хорошей и уважительной, или она будет — опять же по вашему личному мнению — плохой причиной. Но обратите внимание, что, скорее всего, они считают, что причина уважительная.

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

Чек-лист

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

1. Мои изменения ничего не сломают

Благими намерениями вымощена дорога в ад

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

2. Мои изменения не сделают вещи более запутанными или ненужными.

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

3. Мои изменения улучшат ситуацию

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

_{(*) У меня произошел сбой кода из-за простого обновления до новой подверсии комплекта разработки ... даже не второстепенной версии, а подверсии .}

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

Объясните, что и почему вы считаете неправильным, и выслушайте его ответы. Есть две возможности:

1. вы правы, и он поймет ошибку, не «раздраженный» вашим «смелым» заявлением.
2. вы ошибаетесь, и вы приложили усилия, чтобы понять код с ним, не заявляя, что он содержит ошибки.

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

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

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

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

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

глупые ошибки с моей стороны

Для этого есть исправление. ЕДИНИЧНЫЕ ИСПЫТАНИЯ ! Почему бы для каждой важной функции, которую вы пишете, не создать набор модульных тестов, которые знают ожидаемый результат для заданного ввода. Пока вы будете писать эти тесты, вы начнете думать о странных пограничных случаях во входных данных. Черт возьми, для некоторых ключевых функций вы можете даже сначала написать тесты и наблюдать, как они медленно меняют цвет с красного на зеленый по мере реализации вашего fn.

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

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

Вы не пожалеете.

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

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

Ответ заключается в стандартизации с использованием сервера сборки Jenkins или чего-то подобного.

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

Очевидно, что параметры компилятора и среда на сервере Jenkins являются ванильными и ориентированы на полностью действительную/настоящую сборку.

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

Использование такого сервера сборки выравнивает и стандартизирует игровое поле и обеспечивает полную согласованность конечного результата.

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

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

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