Скільки зусиль йде на підтримку системи побудови?

9

У StackExchange Podcast № 09 зазначається:

Нещодавно в іншому дослідженні було розглянуто, скільки зусиль йде на підтримку системи збирання: від 30 до 30% усіх зусиль на розробку витрачається на підтримку системи збирання. Оскільки варіації є величезними навіть при роботі над подібними проектами.

Як називається дослідження, і де його можна знайти? Аудіо про подкаст не містить більше деталей.

Крім того, чи має хто-небудь посилання на інші дослідження, що стосуються тієї ж теми.

commandline-build-tool

— Ніл Мітчелл
джерело

3

Ого. Ніколи не думав, що магазин може витратити стільки часу на систему побудови. У нас є створена на замовлення система побудови, яка вночі створює всі (20 деяких) звільнення та (50 деяких) галузей розвитку (якщо зміни були внесені), запускає одиничні тести, зупиняє і запускає тестові сервери (один або більше за випуск та одна чи більше для багатьох галузей розвитку), результати електронної пошти тощо. Однак за 4 роки, коли я був у цього роботодавця, я не думаю, що ми витратили на це набагато більше, ніж пару тижнів людини, і це включає розширення можливостей нашого індивідуального рішення!

— Мар'ян Венема

Ось що відбувається, коли люди звертаються до чогось / когось і забувають додавати посилання ...

— wleao

Не знаєте дослідження, але результати можуть відрізнятися залежно від того, що ви визначаєте, "підтримуючи систему збірки". "Чи додавання або зміна файлів" є частиною цього? Налаштування інсталятора є частиною "підтримки системи збірки"?

— Doc Brown

1

Я ще не чув про подкаст, але це дослідження, ймовірно, документ із останнього ICSE , який називається "Емпіричне дослідження зусиль щодо обслуговування будівель" Шейна Макінтоша та ін. Перевірте пряме посилання (або офіційну сторінку DOI, якщо ви хочете метадані).

Їх дослідження зосереджується в основному на тому, як часто зміни вихідного коду впливають на збірку і скільки розробників в команді, як правило, займаються підтримкою збірки. Я пам’ятаю, що це цікаве дослідження, але мені було важко інтерпретувати цифри, як це часто трапляється з емпіричними дослідженнями, які намагаються знайти зв’язок між речами :)

— Декард
джерело

2

Я не маю для вас посилання, але якщо говорити з особистого досвіду, цей відсоток змінюється залежно від 2 основних моментів: 1) дизайн системи та складність 2) та особиста організація

Добре розроблена система потребуватиме мінімальних зусиль для підтримання, навіть якщо вона досить складна. Але якщо ваш персонал недостатньо навчений та організований з керуванням кодом, ви, ймовірно, будете витрачати довгий час на виправлення поганих конструкцій чи неправильних зобов'язань та подобань ...

Однак, коли у вас є середовище розробки, питання Q&A, RC та виробництво ... Це все впливає на процес переходу від розробки до фактичного виробництва.

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

— AJC
джерело

Якщо все, що ви інвестуєте, становить 5%, я б запропонував вам не вимірювати все або точно.

— mattnz

немає матових Ви використовуєте інше визначення. Більшість компаній, над якими я працював, не мають системи побудови, як на жодних серверах автоматизованої збірки, інтеграції в VCS (часто взагалі немає VCS, за винятком тих проектів, які вони можуть створити самостійно, що закінчується під радаром) тощо. У будь-якому "дослідженні" відсотка ресурсів, що використовуються для підтримки "системи побудови", вони в кінцевому підсумку перераховуються як витрачені майже нічого, якщо тільки не було розбито, щоб включити зусилля, витрачені на підтримку всіх сценаріїв ANT і Maven, щось рідко робиться.

— jwenting