Я работаю над огромным проектом (больше похожим на запутанную комбинацию десятков мини-проектов, которые не могут быть легко разделены из-за плохого управления зависимостями, но это другое обсуждение) в Java с использованием eclipse. Мы уже отключили ряд предупреждений в настройках компилятора, и в проекте все еще содержится более 10 000 предупреждений.
Я большой сторонник того, чтобы пытаться устранить все предупреждения, исправить их, если это возможно, и для тех, которые рассматриваются и считаются безопасными, подавлять их. (То же самое касается моей религиозной одержимости маркировкой всех реализованных / переопределенных методов как @Override). Мой самый большой аргумент в том, что, как правило, предупреждения помогают вам находить потенциальные ошибки во время компиляции. Может быть, 99 из 100 раз, предупреждения незначительны, но я думаю, что царапина головы, которую он экономит за один раз, предотвращает серьезную ошибку, все это того стоит. (Моя другая причина - это мое ОКР с чистотой кода).
Тем не менее, многие из моих товарищей по команде, кажется, не заботятся. Я иногда исправляю предупреждения, когда сталкиваюсь с ними (но вы знаете, что это сложно, когда вы касаетесь кода, написанного коллегой). Теперь, когда буквально больше предупреждений, чем классов, преимущества предупреждений сведены к минимуму, потому что, когда предупреждения настолько распространены, никто не потрудится изучить их все.
Как я могу убедить своих товарищей по команде (или полномочия), что предупреждения должны быть учтены (или подавлены при полном расследовании)? Или я должен убедить себя, что я сумасшедший?
Спасибо
(PS Я забыл упомянуть, что, наконец, побудило меня опубликовать этот вопрос, это то, что я с грустью заметил, что исправляю предупреждения медленнее, чем они выдаются)
javac
.-Wall -Wextra -Werror
(т.е. активировать большинство доступных предупреждений, относиться к ним как к ошибкам). Затмение C ++ почти непригодно для использования, хотя: /Ответы:
Вы можете сделать две вещи.
Укажите, что предупреждения есть по причине. Авторы компиляторов не помещают их, потому что они подлые. Люди в нашей отрасли, как правило, полезны. Многие предупреждения полезны.
Соберите историю впечатляющих сбоев, возникающих из игнорируемых предупреждений. Поиск по сети «Обратите внимание на предупреждения компилятора» возвращает некоторые анекдоты.
Ваша одержимость
@Override
не является «одержимостью». Это хорошая вещь. Вы когда-нибудь ошиблись в названии метода?источник
if (error = 0)
вместоif (error == 0)
. Кроме того, большое количество предупреждений также значительно упрощает поиск ошибок компилятора без необходимости просматривать множество предупреждений.Актуальное чтение здесь . C ++, но все еще актуально. Мне особенно нравится этот пример (мой комментарий к коду):
В большинстве случаев предупреждение будет означать разницу между аварийным завершением приложения и ошибкой, которая фактически поможет вам отследить недостаток проекта и исправить его (например, безопасное приведение типов) или предположения приложения, а затем вести себя некорректно или ошибочной манере (что было бы в случае небезопасной типизации). Точно так же они также указывают на бесполезный или мертвый код, который можно удалить (недостижимые блоки кода, неиспользуемые переменные), что можно считать оптимизацией кода, или неучтенные случаи, которые будут обнаружены при тестировании, как в приведенном выше примере для C ++. Обратите внимание, что этот пример приводит к ошибке времени компиляции в Java.
Таким образом, исправление предупреждений имеет (как минимум) несколько преимуществ для управления:
Обратите внимание, что я все еще начинающий разработчик, который мало знает об управлении проектами, поэтому, если я сказал что-то не так, пожалуйста, исправьте мои мысли и дайте мне возможность отредактировать, прежде чем вы откажетесь от моего существования :)
источник
Я работал над проектом с похожими характеристиками в прошлом. Этот, в частности, был изначально написан на Java 1.4. Как только выйдет Java 5 с обобщениями, можно представить количество предупреждений, выдаваемых компилятором для каждого использования Collections API.
Потребовалось бы некоторое время, чтобы избавиться от всех предупреждений, начав использовать дженерики. Это фактор, который необходимо учитывать, но когда вам нужно убедить кого-то (особенно вашего менеджера), что он нуждается в исправлении, вам понадобятся точные данные, такие как
Вы можете продолжать представлять счет, который демонстрирует, как вы теряете время и деньги, игнорируя «определенные» предупреждения, и кто-то поймет эту идею. Ключевым моментом является то, что не все предупреждения заслуживают внимания, по крайней мере, не сразу; Проще говоря, вам нужно будет установить приоритет предупреждений, которые необходимо немедленно устранить. Для начала рассмотрим те, которые имеют отношение к ошибкам, которые вы видите в своем проекте.
Вы также можете делать заметки в трекере ошибок, когда исправляете ошибки, что упомянутой ошибки можно было бы избежать, не игнорируя предупреждение (или, возможно, запустив PMD или FindBugs, если у вас есть CI или система сборки). До тех пор, пока существует достаточное количество ошибок, которые можно исправить с помощью предупреждений компилятора, ваша точка зрения на просмотр предупреждений компилятора будет верной. В противном случае, это деловое решение, и, как правило, не стоит тратить время на борьбу.
источник
Если вы добились успеха, и ваша команда решает соблюдать предупреждения, вы должны предпринять пошаговый подход. Никто не может и не будет 10000 предупреждений за один раз. Таким образом, вы можете выбрать наиболее важные (те, которые являются ошибками с высокой вероятностью) и отключить менее значимые. Если они исправлены, снова увеличьте уровень предупреждения. Кроме того, вы можете начать с FindBugs, который предупреждает о коде, который почти всегда является ошибкой.
источник
Я полностью согласен с вами, это лучшая практика, чтобы очистить предупреждения компиляции как можно больше. Вы упомянули, что ваша команда использует Eclipse в качестве инструмента разработки. Eclipse - очень хороший инструмент, который поможет вам очистить код и обеспечить согласованность стиля кода.
Eclipse создаст некоторые файлы свойств для этих предпочтений в папке .settings, вы можете скопировать их в другие проекты Java и зарегистрировать их в SCM как часть исходного кода.
Вы можете проверить код Eclipse, чтобы увидеть, как разработчики Eclipse делают это.
источник
У вас есть два способа избавиться от всех предупреждений (и я согласен, что это может скрыть небольшую ошибку):
Я считаю, что 1 в вашем случае неосуществим. Кроме того, это, вероятно, займет так много времени из-за количества предупреждений, которые будут отображаться в выходных данных о производительности, поэтому руководство все равно должно будет это знать.
Итак, мое предложение: поговорите с боссом, убедите его, что это бомба замедленного действия, и сделайте это официальной политикой.
источник
Я бы просто сказал им, что большинство из них являются незначительными предупреждениями, и важно, чтобы мы удалили их из списка. Так что мы не пропустим действительно существенное предупреждение в толпе, как это происходит!
источник
Вам понадобится много терпения, чтобы убедить их, удаление предупреждений, когда парное программирование поможет другим приобрести привычку. Предложите им прочитать «Эффективная Java», пункт 24: «Устранить непроверенные предупреждения» (для общего сбора). И, вероятно, игнорировать много случаев, когда люди не следуют вашим советам;)
источник
Эффективным подходом здесь будет установка сервера непрерывной интеграции, который автоматически создает проект и запускает тесты всякий раз, когда кто-либо проверяет код. Если вы еще не используете это, вы должны это сделать, и не очень сложно убедить других в преимуществах этого.
Убедите руководство / команду руководителей в преимуществах этого (предотвращение развертывания плохих сборок, раннее обнаружение ошибок, особенно тех, которые случайно влияют на другие части программного обеспечения, проведение регрессионного тестирования, раннее и частое тестирование и т. Д.)
Установите CI-сервер, когда все тесты пройдены (если у вас нет тестов, напишите быстрый, который проходит, чтобы все видели, что он зеленый).
Настройка электронной почты или других уведомлений о состоянии каждой сборки. Здесь важно указать, кто проверял код, что это было за изменение (или ссылку на коммит), а также статус + выходные данные сборки. Это важный шаг, поскольку он обеспечивает видимость всей команды как для успехов, так и для неудач.
Обновите сервер CI, чтобы тесты не выполнялись, если есть какие-либо предупреждения. Менеджеры и руководители команд увидят, что это систематически повышает дисциплину команды, и никто не хочет отвечать за все сообщения об ошибках.
(опционально), получайте удовольствие от этого, добавив несколько видимых панелей приборов, лавовые лампы, мигающие огни и т. д., чтобы указать на состояние сборки и кто ее сломал / исправил.
источник