Як я переконаю своїх товаришів по команді, що ми не повинні ігнорувати попередження компілятора?

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

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

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

Як я можу переконати своїх товаришів по команді (або повноваження, які є), що попередження потрібно вирішувати (або придушувати, коли повністю розслідувати)? Або я повинен переконувати себе, що я божевільний?

Дякую

(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 з дженериками, можна уявити кількість попереджень, викинутих компілятором для кожного використання API Collections.

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

час, витрачений на помилки у застарілому або нестандартному сумісному коді (стандарт - це стандарт кодування проекту), якого можна було б уникнути.

Ви можете продовжувати представляти законопроект, який демонструє, як ви втрачаєте час і гроші, ігноруючи "певні" попередження, і хтось здобуде ідею. Ключова частина полягає в тому, що не всі попередження варто переглянути, принаймні, не відразу; простішими словами, вам потрібно буде встановити пріоритет попереджень, які потребують негайного вирішення. Для початку розглянемо ті, що стосуються помилок, які ви бачите у своєму проекті.

Ви також можете робити примітки в трекері помилок, коли виправляєте помилки, що зазначеної помилки можна було уникнути, не ігноруючи попередження (або, можливо, запустивши 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. (необов’язково) отримуйте приємне та примхливе ставлення до цього, додаючи кілька видимих ​​панелей приладів, лавових ламп, миготливих вогнів тощо, щоб вказати статус конструкції та хто її зламав / виправив.