Чи слід застосовувати стандарти / стиль кодування за допомогою сервера безперервної інтеграції, що працює з інструментами статичного аналізу (напр., PMD, StyleCop / FxCop) і не виконує збірку, якщо стандарти не дотримуються? Які типи правил не слід використовувати для збоїв у складанні?
Відповіді:
Стандарти кодування повинні існувати з причини ... і невідповідність слід перевіряти.
Однак не всі порушення слід розглядати як помилки - так само, як і не всі порушення компіляції. Там, де ви проводите лінію, має бути компанія та інструментальне рішення.
Наприклад, MISRA визначає свої правила як «Обов’язкові» та «Консультативні» ... Я б припустив, що Консультативні органи дозволять продовжувати збір
Це не зовсім нечувано, і ви дізнаєтесь, чи вдасться вам працювати лише спробувавши це. Є кілька кроків, які ви могли зробити перед цим.
Спочатку команда повинна разом визначитися зі стандартами. Тоді такі інструменти, як ReSharper, слід використовувати, щоб повідомити розробникам, чи вони не дотримуються стандартів. Проведення експертної оцінки з кожного завдання може додатково допомогти.
Після того, як ці кроки будуть зроблені, можна було б розглянути можливість встановлення стандартних перевірок кодування на CI-сервер. Однак слід все-таки враховувати, якщо розумно мати перерву для не дотримання стандартів кодування. Ризик полягає в тому, що у вас буде багато зламаних складок, які можуть зменшити значення зламаної збірки.
Замість того, щоб робити перерву в збірці, ви можете запустити інструменти і дати їм створювати звіти. Якщо кодування стандартних порушень, здається, зростає, ви можете зібрати команду і зрозуміти, чому це відбувається.
Чи слід застосовувати стандарти / стиль кодування за допомогою сервера безперервної інтеграції, що працює з інструментами статичного аналізу (напр., PMD, StyleCop / FxCop) і не виконує збірку, якщо стандарти не дотримуються?
Ці постійні перевірки інтеграції повинні бути дуже, дуже швидкими. Будь-які значні затримки означатимуть, що ваші програмісти зроблять на себе зобов’язання та втратять свій розумний процес, очікуючи результатів. Зробіть це довше, і вони зроблять на себе зобов’язання і отримають чашку кави або поспілкуються зі своїми товаришами по службі про останнє неспокійне виступ якоїсь спортивної команди. Ці затримки є дуже контрпродуктивними. Деякі речі краще залишити для нічного складання чи перегляду коду.
Які типи правил не слід використовувати для збоїв у складанні?
Суб'єктивні, для початку. Як Ви застосовуєте правило "Кодекс повинен бути самодокументованим або добре коментованим"? Правило "немає магічних чисел"? Це речі, які краще залишити для огляду коду.
Ще одна категорія - порушення правил, які вже отримали відмову. Враховуючи будь-яку значну базу коду, неминуче буде якийсь фрагмент коду, де порушення стандарту - це правильно.
Нещодавно в рамках плану вдосконалення якості програмного забезпечення ми заздалегідь зашифрували серію кодових нюхань для інтеграції в наш процес збирання.
Ми будуємо багато, будучи додатком PHP, немає реальної компіляції, тому збірка - це дійсно тестовий аналіз / статичний аналіз / бігун, і ми можемо дозволити собі витратити на це кілька циклів.
У нас були проблеми з якістю коду, а також застарілий код із безліччю питань.
Починаючи з того, що якщо це не відбудеться, це буде проігноровано, ми почали підтверджувати зобов’язання проти нашого "бажаного" стандарту кодування, а також не виконати помилки, що не відповідають стандарту.
Обґрунтування технічного обслуговування припинилось, навіть найпростіший виправлення застарілого компонента вимагав від розробника переформатування величезних кількостей джерела, і збірка була порушена найчастіше. Потрібно сказати, що ми змінили помилки на попередження, і тепер вони є, ігноровані та "переважно" безглуздими.
Тому я б сказав це (дізнався з важкого досвіду).
Переконайтесь, що стандарт вашої кодової бази досить близький до стандарту, який ви застосовуєте, що вам не потрібно, щоб розробники миттєво переформатували томи коду. Або .. Ви готові і очікуєте збільшення зусиль.
Будучи невеликою командою з величезною потребою в доставці, ми не могли дозволити собі переключити команду на величезну операцію рефактора. Наші стандарти кодування зараз в основному обробляються вручну, і спадщина переписується як частина плану постійного вдосконалення.
Коли я сказав, що попередження "здебільшого" безглузді, то тепер ми використовуємо їх для запису статистики, яка дозволяє нам вимірювати кіпі, які повинні постійно показувати поліпшення.
Коли ми знову застосуємо нюхання коду, ми розпочнемо світло і введемо кілька нюхів одночасно, поки не буде застосовано стандарт.
Це буде залежати від вашої кінцевої мети та стратегії .
Примушення всіх добре згаданих стандартів на сервері CI може здатися дуже прибутковим. Однак це може бути не практичним для великої команди (більше 6 розробників), яка розробляється, якщо це робиться при кожній передачі сервера. Очікування вашого сервера на відповідь після здійснення НЕ повинно бути тривалим зволіканням. Це може призвести до простою.
Однак, цілком законно блокувати комісію, якщо код (фактично встановлений набір змін) має проблеми із залежністю або не компілюється. Однак, невдача коду через макет коду та деякого домовленості про іменування може бути надто суворим і не є життєво важливим обмеженням для правил фіксації сервера CI.
Але це може бути корисним правилом, якщо застосовувати його під час вечірнього збирання.
Крім того, інструменти для повторного факторингу можуть допомогти у впровадженні та навчанні стандартів - як, наприклад, використання Resharper або JustCode розробниками.