Чи потрібно зберігати згенерований код у контролі джерела

Це дискусія, в якій я беру участь. Я хотів би отримати більше думок та точок зору.

У нас є кілька класів, які генеруються в час збирання для обробки операцій з БД (у цьому конкретному випадку з SubSonic, але я не думаю, що це дуже важливо для питання). Покоління задається як крок попереднього збирання у Visual Studio. Отже, кожного разу, коли розробник (або офіційний процес збирання) запускає збірку, ці класи генеруються і потім компілюються в проект.

Зараз деякі люди стверджують, що збереження цих класів у контролі джерела може спричинити плутанину, якщо ви отримаєте код, не відповідає тому, що було б створено у вашому власному середовищі.

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

Будь-які аргументи чи протилежні аргументи?

На даний момент я не виберу прийняту відповідь із зазначених вище причин.

Зберегти його в керуванні джерелами - це більше клопоту, ніж варто.

Ви повинні робити зобов’язання кожен раз, коли ви будуєте, щоб це було будь-якою цінністю.

Зазвичай ми залишаємо згенерований код (idl, jaxb речі тощо) поза контрольним джерелом, де я працюю, і це ніколи не було проблемою

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

Кожен раз, коли мені хочеться відобразити зміни у вихідному дереві на своєму особистому репо-репортажі, всі 'створені файли' відображатимуться як змінені та потребують початку роботи.

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

Залиште їх, а потім після складання додайте "ігнорувати" на кожен із створених файлів.

Подивіться на це так: чи перевіряєте ваші об'єктні файли в джерело управління Згенеровані вихідні файли - це артефакти, такі як об'єктні файли, бібліотеки та виконавчі файли. До них слід ставитися однаково. Більшість може стверджувати, що ви не повинні перевіряти згенеровані об’єктні файли та виконувані файли в керуванні джерелами. Такі ж аргументи стосуються і створеного джерела.

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

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

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

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

Також ви можете запобігти деяким проблемам таким чином, якщо, наприклад, коли-небудь порушиться генерація коду.

Ні, з трьох причин.

1. Вихідний код є всім необхідним і достатнім для відтворення знімка вашої програми станом на якийсь поточний або попередній момент часу - нічого більше і нічого менше. Частина цього означає, що хтось несе відповідальність за все, що зареєстровано. Взагалі я радий нести відповідальність за код, який я пишу, але не за код, який генерується внаслідок того, що я пишу.

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

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

Я дійсно не думаю, що ви повинні їх перевірити.

Звичайно, будь-яка зміна згенерованого коду буде або шумом - зміною між середовищами, або зміною внаслідок чогось іншого - наприклад, зміни у вашій БД. Якщо сценарії створення вашої БД (або будь-які інші залежності) знаходяться в контролі джерела, то навіщо вам також потрібні згенеровані сценарії?

Загальне правило - ні , але якщо потрібен час для генерування коду (через доступ до БД, веб-служб тощо), можливо, ви захочете зберегти кешовану версію в керуванні джерелом і врятувати всім біль.

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

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

Ми також не зберігаємо згенерований код БД: оскільки він генерується, ви можете отримати його за бажанням у будь-якій версії з вихідних файлів. Збереження цього було б схожим на зберігання байт-коду чи іншого.

Тепер вам потрібно забезпечити доступність генератора коду, який використовується в даній версії! Новіші версії можуть генерувати різний код ...

Залиште це.

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

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

Світ болю очікує тих, хто перевіряє створені файли!

Існує особливий випадок, коли ви хочете перевірити в створених файлах: коли вам може знадобитися будувати системи, де інструменти, що використовуються для створення інших файлів, недоступні. Класичний приклад цього і одного, з яким я працюю, - це коди Лекса та Якка. Оскільки ми розробляємо систему виконання, яка повинна будувати та працювати на величезній кількості різноманітних платформ та архітектур, ми можемо розраховувати лише на цільові системи, щоб вони мали компілятори C і C ++, а не інструменти, необхідні для створення коду лексингу / розбору для визначення нашого інтерфейсу. перекладач. Таким чином, коли ми змінюємо свої граматики, ми перевіряємо у створеному коді для її розбору.

приїхали трохи пізно ... все одно ...

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

Тому я б сказав: не ставте згенерований код під контроль версій, а генератор та його вхід.

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

У деяких проектах я додаю згенерований код до управління джерелом, але це дійсно залежить. Моє основне керівництво: якщо згенерований код є невід'ємною частиною компілятора, я його не додаю. Якщо згенерований код походить від зовнішнього інструмента, такого як SubSonic, у цьому випадку я б додав, якщо до керування джерелом. Якщо ви періодично оновлюєте компонент, то я хочу знати зміни в створеному джерелі на випадок помилок або проблем.

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

Завдання управління конфігурацією (керування версіями - лише одна частина) полягає в тому, щоб виконувати наступні дії:

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

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

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

Це означає, що ваш компілятор, бібліотеки тощо також повинні бути частиною CM.

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

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

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

Отже, чи зберігаєте ви генерований код: я б сказав «ні». Бінарні файли чи результати, які випускаються, включаючи інструменти, якими ви їх відтворили, я б зберігав. І тоді, немає необхідності зберігати їх у контролі джерел, просто зробіть гарне резервне копіювання цих файлів.

Правильна відповідь - "Це залежить". Це залежить від потреб клієнта. Якщо ви можете відмовити код до певного випуску і протистояти будь-якому зовнішньому аудиту без нього, ви все ще не на твердій основі. Як розробників нам потрібно розглядати не лише «шум», біль та дисковий простір, а й те, що перед нами стоїть роль генерувати інтелектуальну власність, і можуть виникнути юридичні наслідки. Чи зможете ви довести судді, що ви зможете відновити веб-сайт саме так, як бачив його клієнт два роки тому?

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

Мої два центи.

Тут є хороші аргументи «за» і «проти». Для запису я будую систему покоління T4 у Visual Studio, і наш параметр "поза коробкою" за замовчуванням призводить до перевірки генерованого коду. Вам потрібно працювати трохи важче, якщо ви не хочете робити реєстрацію.

Для мене ключовим фактором є розходження генерованого виходу при оновленні або самого вводу, або самого генератора.

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

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

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

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

3. Ви просто не на 100% довіряєте виходу свого генератора від випуску до випуску. Існує велика цінність від інструментів генератора, навіть якщо вони не побудовані та не підтримуються з урахуванням суворості постачальника компілятора. Випуск 1.0 може бути ідеально стабільним для вашої програми, але, можливо, у 1.1 є кілька глюків для вашого випадку використання. Крім того, ви змінюєте вхідні значення і виявляєте, що використовуєте новий фрагмент генератора, який ви раніше не використовували - потенційно ви здивовані результатами.

По суті, все це зводиться до зрілості інструментів - більшість генераторів коду бізнес-додатків не наближаються до рівня, який роблять компілятори або навіть інструменти рівня lex / yacc протягом багатьох років.

Обидві сторони мають вагомий та розумний аргумент, і важко домовитися про щось спільне. Системи керування версіями (VCS) відстежують, які розробники файлів розміщують у ньому, і мають припущення, що файли всередині VCS розробляються вручну розробниками, а розробники цікавляться історією та зміною між будь-яким переглядом файлів. Це припущення зрівняє два поняття: "Я хочу отримати цей файл, коли я роблю замовлення". і "Мене цікавить зміна цього файлу."

Тепер аргументи з обох сторін можна переформулювати так:

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

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

Підсумок

Я візьму git як один із прикладів, щоб проілюструвати, що я маю на увазі.

• git status не повинен показувати створені файли за замовчуванням.
• git commit має містити згенеровані файли як знімок.
• git diff не повинен показувати створені файли за замовчуванням.

PS

Гакі-гачки можна використовувати як спосіб вирішення, але це було б чудово, якби git підтримував це на самому світі. gitignoreне відповідає нашій вимозі, оскільки ігноровані файли не перейдуть до ДКС.enter code here

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

Крім того, вона є частиною кожного "знімка", який ви робите зі свого сховища програмного забезпечення. Якщо це частина програмного забезпечення, то вона повинна бути частиною сховища.

Я б сказав, що так, ви хочете поставити його під контроль джерел. З точки зору управління конфігурацією ВСЕ, що використовується для створення збірки програмного забезпечення, має контролюватися, щоб воно могло бути відтворене. Я розумію, що згенерований код легко відтворити, але можна зробити аргумент, що він не той самий, оскільки дата / часові позначки будуть різними між двома побудовами. У деяких сферах, таких як уряд, вони вимагають багато разів. Це робиться.

Загалом, згенерований код не потрібно зберігати у керуванні джерелами, оскільки історія редагування цього коду може бути простежена за історією редагування коду, який його генерував!

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

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

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

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

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

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

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

1. За допомогою кодових файлів у керуванні джерелом потенційно ви зможете скласти код, не використовуючи крок попередньої збірки Visual Studio.
2. Коли ви робите повне порівняння між двома версіями, було б непогано знати, чи згенерований код змінювався між цими двома тегами, не маючи вручну перевіряти його.
3. Якщо сам генератор коду змінюється, ви хочете переконатися, що зміни у створеному коді змінюються належним чином. тобто якщо ваш генератор змінюється, але вихід не повинен змінюватися, тоді, коли ви перейдете до введення коду, не буде різниці між тим, що було створено раніше, і тим, що генерується в коді зараз.

Я б залишив згенеровані файли з вихідного дерева, але поклав би його в окреме дерево збірки.

наприклад робочий процес є

1. нормально перевірити / вимкнути / змінити / об'єднати джерело (без будь-яких створених файлів)
2. У відповідних випадках перегляньте вихідне дерево на чисте дерево збірки
3. Після складання перевірте всі "важливі" файли ("справжні" вихідні файли, виконувані файли + згенерований вихідний файл), які повинні бути присутніми для аудиторських / регуляторних цілей. Це дає вам історію всіх відповідних згенерованих кодів + виконуваних файлів + будь-чого, за кроком часу, пов’язаного з випусками / тестуванням знімків тощо, і відключається від щоденної розробки.

Можливо, в Subversion / Mercurial / Git / тощо є хороші способи зв'язати історію реальних вихідних файлів в обох місцях разом.

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

ОНОВЛЕННЯ: Я задав це питання, оскільки я дійсно вважав, що є одна остаточна відповідь. Дивлячись на всі відповіді, я можу з високим рівнем впевненості сказати, що такої відповіді немає. Рішення повинно прийматися на основі більш ніж одного параметра. Читання інших відповідей могло б стати дуже хорошим керівництвом щодо типів питань, які ви повинні задавати собі, коли потрібно вирішити це питання.