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

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

Я большой сторонник того, чтобы пытаться устранить все предупреждения, исправить их, если это возможно, и для тех, которые рассматриваются и считаются безопасными, подавлять их. (То же самое касается моей религиозной одержимости маркировкой всех реализованных / переопределенных методов как @Override). Мой самый большой аргумент в том, что, как правило, предупреждения помогают вам находить потенциальные ошибки во время компиляции. Может быть, 99 из 100 раз, предупреждения незначительны, но я думаю, что царапина головы, которую он экономит за один раз, предотвращает серьезную ошибку, все это того стоит. (Моя другая причина - это мое ОКР с чистотой кода).

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

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

Спасибо

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

Вы можете сделать две вещи.

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

2. Соберите историю впечатляющих сбоев, возникающих из игнорируемых предупреждений. Поиск по сети «Обратите внимание на предупреждения компилятора» возвращает некоторые анекдоты.

Ваша одержимость @Overrideне является «одержимостью». Это хорошая вещь. Вы когда-нибудь ошиблись в названии метода?

Актуальное чтение здесь . C ++, но все еще актуально. Мне особенно нравится этот пример (мой комментарий к коду):

int searchArray(int to_search[], int len, int to_find)
{
    int i;
    for( i = 0; i < len; ++i )
    {       
        if ( to_search[i] == to_find )
        {
            return i;
        }
    }
    // should be returning designated 'not found' value (0, -1, etc)
}

В большинстве случаев предупреждение будет означать разницу между аварийным завершением приложения и ошибкой, которая фактически поможет вам отследить недостаток проекта и исправить его (например, безопасное приведение типов) или предположения приложения, а затем вести себя некорректно или ошибочной манере (что было бы в случае небезопасной типизации). Точно так же они также указывают на бесполезный или мертвый код, который можно удалить (недостижимые блоки кода, неиспользуемые переменные), что можно считать оптимизацией кода, или неучтенные случаи, которые будут обнаружены при тестировании, как в приведенном выше примере для C ++. Обратите внимание, что этот пример приводит к ошибке времени компиляции в Java.

Таким образом, исправление предупреждений имеет (как минимум) несколько преимуществ для управления:

1. Меньшая вероятность того, что код будет некорректно работать с данными, вводимыми пользователем, что для руководителей высшего звена, обеспокоенных имиджем компании и тем, как он обрабатывает данные своих клиентов, должно быть большой выгодой (tm). Сбой, чтобы помешать пользователю сделать что-то глупое, лучше, чем не дать сбою и позволить ему это сделать.
2. Если они хотят перестановить персонал, люди могут войти в кодовую базу без предупреждений (и не волноваться или жаловаться так много ..). Может быть, это уменьшит количество ворчаний или мнений по поводу ремонтопригодности или качества вклада Team X в Проект Y.
3. Оптимизация кода за счет удаления предупреждений компилятора, хотя и не дает каких-либо существенных улучшений во время выполнения, улучшит многочисленные показатели, когда дело доходит до тестирования:
   • Любые оценки покрытия кода, вероятно, увеличатся.
   • Тестирование граничных и недействительных тестовых случаев, скорее всего, будет успешным чаще ( среди прочего, из-за вышеупомянутой безопасной типизации).
   • Когда тестовый случай терпит неудачу, вам не нужно думать, связано ли это с одним из предупреждений компилятора в этом исходном файле.
   • Легко утверждать, что нулевые предупреждения компилятора лучше, чем тысячи. Никакие предупреждения или ошибки не говорят о качестве кода, поэтому вы можете утверждать, что качество кода улучшается, чем меньше предупреждений.
4. Если у вас нет предупреждений компилятора и введено одно или несколько предупреждений, гораздо проще узнать, кто вызвал их появление в кодовой базе. Если у вас есть политика «без предупреждений», это поможет им определить людей, которые не выполняют свою работу должным образом? Написание кода заключается не только в том, чтобы заставить что-то работать, но и в том, чтобы оно работало хорошо .

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

Я работал над проектом с похожими характеристиками в прошлом. Этот, в частности, был изначально написан на Java 1.4. Как только выйдет Java 5 с обобщениями, можно представить количество предупреждений, выдаваемых компилятором для каждого использования Collections API.

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

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

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

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

Если вы добились успеха, и ваша команда решает соблюдать предупреждения, вы должны предпринять пошаговый подход. Никто не может и не будет 10000 предупреждений за один раз. Таким образом, вы можете выбрать наиболее важные (те, которые являются ошибками с высокой вероятностью) и отключить менее значимые. Если они исправлены, снова увеличьте уровень предупреждения. Кроме того, вы можете начать с FindBugs, который предупреждает о коде, который почти всегда является ошибкой.

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

1. Определите «Сохранить действие» для каждого вашего Java-проекта, такого как кодирование кода, неиспользуемые локальные переменные, организация импорта (я думаю, что никто не возражает против такой очистки).
2. определить конкретные параметры компиляции для каждого проекта. Например, уровень компиляции (если ваш код должен быть совместим с 1.4 для очистки предупреждений, связанных с универсальным), назначение не имеет никакого эффекта (например, «x = x») и так далее. Вы и ваш партнер по команде можете заключить соглашение для этих элементов, и Eclipse сообщит о них как об «Ошибка» на этапе разработки после того, как вы согласитесь на ошибку компиляции.

Eclipse создаст некоторые файлы свойств для этих предпочтений в папке .settings, вы можете скопировать их в другие проекты Java и зарегистрировать их в SCM как часть исходного кода.

Вы можете проверить код Eclipse, чтобы увидеть, как разработчики Eclipse делают это.

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

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

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

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

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

Вам понадобится много терпения, чтобы убедить их, удаление предупреждений, когда парное программирование поможет другим приобрести привычку. Предложите им прочитать «Эффективная Java», пункт 24: «Устранить непроверенные предупреждения» (для общего сбора). И, вероятно, игнорировать много случаев, когда люди не следуют вашим советам;)

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

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

2. Установите CI-сервер, когда все тесты пройдены (если у вас нет тестов, напишите быстрый, который проходит, чтобы все видели, что он зеленый).

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

4. Обновите сервер CI, чтобы тесты не выполнялись, если есть какие-либо предупреждения. Менеджеры и руководители команд увидят, что это систематически повышает дисциплину команды, и никто не хочет отвечать за все сообщения об ошибках.

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