Іноді, коли ми перевіряємо історію фіксації програмного забезпечення, ми можемо побачити, що є кілька комітетів, які дійсно є ВЕЛИКИми - вони можуть змінювати 10 або 20 файлів із сотнями змінених рядків вихідного коду (дельта). Я пам’ятаю, що є такий вживаний термін для такого великого прихильності, але я не можу точно згадати, що таке термін. Хтось може мені допомогти? Який термін, який програмісти зазвичай використовують для позначення таких BIG та гігантських комітетів?

До речі, чи багато змін все разом є доброю практикою?

ОНОВЛЕННЯ: дякую, хлопці, за надихаючу дискусію! Але я думаю, що "кодова бомба" - це термін, який я шукаю.

(1) Бен Коллінз-Суссман : "..." кодові бомби ". Тобто, що ти робиш, коли хтось з'являється перед проектом з відкритим кодом з гігантською новою функцією, на яку пішли місяці? Хто має час на перегляд тисячі рядків коду? ... "

(2) Ден Фабуліч : "Бомба з кодом, або: Новачок з великими ідеями ... Кодова бомба - це настільки великий патч, що ніхто не може його переглянути".

(3) Google Summer of Code: Вказівки : "Вчинайтесь рано, виконайте зобов'язання часто ... Будь ласка, не працюйте цілий день, а потім виштовхуйте все в одній кодовій бомбі . Натомість, кожна фіксація повинна містити лише одне завдання які слід узагальнити у журналі повідомлення. "

(4) Джефф Етвуд : "кодові бомби ... Правило №30: Не темніти ...

Ми, мабуть, називаємо це поганим зобов'язанням . :)

Погана практика

І так, це, як правило, вважатиметься поганою практикою , оскільки це має негативні наслідки:

• що робить його важко розглянути ,
• що робить його важко легко і швидко схоплювати фіксації початкового наміру ,
• що робить його важко зрозуміти , як це вплинуло на код , щоб явно виправити або вирішити проблему ,
• що робить його важко зрозуміти , якщо зробити Таблиця розмірів з - за шуму інших , можливо , не зв'язаних між собою змін ВЗ немає (наприклад , невеликі прибирань або інші завдання).

Прийнятні випадки

Однак у вас можуть бути випадки, коли великі комісії цілком прийнятні . Наприклад:

• при злитті через гілки ,
• при додаванні нових джерел з іншим не-версіоніруются кодовою,
• під час заміни великої функції на місці (хоча вам краще зробити це у гілці, меншими комісіями звертатися до різних частин зміни, а потім об'єднати всю справу назад, щоб у вас було краще вікно про поступовий розвиток особливості та проблеми, які можуть виникнути на шляху),
• коли рефакторинг API впливає на багато класів нащадків та споживачів.

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

Крім того, я насправді не знаю і не думаю, що я коли-небудь чув спеціальну назву для великої прихильності. Потвор-монстр? Жир-фіксація?

Оновлення: відповіді Девіда Кері на посилання на помітних ІТ-акторів, що використовують термін «кодова бомба» (головне, Колінз-Суссман, оригінальний творець Subversion ). Як це (хоча поки що не можу сказати, що чув часто).

До речі, чи багато змін все разом є доброю практикою?

Ну, це не дуже добра практика тривалий час тримати зміни, впроваджувати різноманітні функції та виправлення помилок, а потім виконувати їх, що є одним із способів, коли може статися велика фіксація.

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

Отже, у цьому є більше, ніж просто дивитися на кількість файлів, доторканих до комітки.

Термін, який я чув, - це "приємні реєстрації" . І я не шанувальник їх. Мені подобаються менші зобов’язання, які гарантують, що більше нічого не буде порушено на розумному кроці проекту. Велике зобов’язання, як правило, загрожує проблемами, які виникають протягом певного часу, коли це станеться.

Я називаю це "типовим фіксацією SVN" або "завтра - день випуску"

Наскільки я люблю SVN, мене просто відключив той факт, що я не можу робити місцеві зобов’язання.

EDIT: вони зазвичай містять слова "речі" та "пиво" у повідомленні про виконання.

РЕДАКТУЙТЕ ПРОТИ: Необхідно максимально уникати внесення багатьох змін, хоча це не обов'язково і є поганою практикою. Мені легше переглянути короткий і стислий перегляд / перегляд. (у поєднанні з добре написаним повідомленням про фіксацію, поганий приклад див. у попередній редакції)

"Кусок коду з гарячим паром". :-)

• початковий комітет - проект, який не знаходився під контролем редакції, кинутий у SVN
• рефакторинг - архітектор має геніальне уявлення про зміну назв класів з / до Конвенції про іменування Smurf або про зміну кореня ієрархії пакетів
• формат коду - архітектор вирішив змінити відступ коду з 4 на 3 пробіли або змінити закінчення рядків з Unix на Windows (або відновити)
• П’ятницький вчинок - Джо завжди бере свою цілу тижневу роботу по п’ятницях о 16:30
• uuups commit - Тед помилково видалив кореневу директорію, зробив це, і тепер він знову завантажує всю ієрархію файлів у SVN

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

І розробники, які зелені для VCS, можуть забути розділити зміни на кілька невеликих комісій. Вони пам’ятають, що вони зобов’язані здійснити лише тоді, коли передадуть програму команді QA. Що ще гірше, щоб інші люди не бачили баггі-код, вони не виконують зобов'язання перед успішним тестуванням якості. Нарешті, вони не усвідомлювали, що вони здійснили вихідні бінарні файли, тимчасові файли та вихід лінкера, які справді створюють "великі" коміти.