Коли компресія версій занадто велика? [зачинено]

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

Для мене у мене виникають проблеми, коли я намагаюся зробити "малі зобов'язання", оскільки я забуваю або створюю щось, що створює щось інше, що створює щось інше. Потім ви закінчите такі речі:

Створена спеціальна вихідна черга

Бот
-Нове поле msgQueue, яке є не що інше, як SingleThreadExecutor
-sendMsg блокує, поки повідомлення не буде надіслане, і додає очікування між повідомленнями
надісланий
оновлено виклики -adminExist (див. контролер)
-Видалені дзвінки для відправки повідомлення

Контролер
-Нове поле msgWait позначає час очікування між повідомленнями
-Запуск плагінів служби переміщено до reloadPlugins
-adminExists переїхав із Сервера через глобальних адміністраторів. Перевірки на каналі,
серверний та глобальний рівень

Адміністратор
-Нові методи getServer та getChannel, які отримують відповідний об’єкт Адміністратор
належить до

BotEvent
-toString () також показує додаткові та додаткові1

Канал
-канальне поле перейменовано на ім'я
-Фіксована помилка в каналі (int)

Сервер
-Переміщені адмініструвачі до контролера

PluginExecutor
-Мінор тестування додано, буде видалено пізніше

JS плагіни
-Оновлений до змін рамки
-Замінено InstanceTracker.getController () на Controller.instance
-VLC говорити зараз у власному файлі

Різні оновлення та зміни проекту NB

---

Постраждалі файли
Змінити /trunk/Quackbot-Core/dist/Quackbot-Core.jar
Змінити /trunk/Quackbot-Core/dist/README.TXT
Змінити /trunk/Quackbot-Core/nbproject/private/private.properties
Змініть /trunk/Quackbot-Core/nbproject/private/private.xml
Змінити /trunk/Quackbot-Core/src/Quackbot/Bot.java
Змінити /trunk/Quackbot-Core/src/Quackbot/Controller.java
Змінити /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java
Змінити /trunk/Quackbot-Core/src/Quackbot/info/Admin.java
Змінити /trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java
Змінити /trunk/Quackbot-Core/src/Quackbot/info/Channel.java
Змінити /trunk/Quackbot-Core/src/Quackbot/info/Server.java
Змінити /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
Змінити /trunk/Quackbot-GUI/dist/README.TXT
Змінити /trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar
Змінити /trunk/Quackbot-GUI/nbproject/private/private.properties
Змінити /trunk/Quackbot-GUI/nbproject/private/private.xml
Змінити /trunk/Quackbot-GUI/src/Quackbot/GUI.java
Змінити /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java
Видалити /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java
Змінити /trunk/Quackbot-Impl/dist/Quackbot-Impl.jar
Змінити /trunk/Quackbot-Impl/dist/README.TXT
Змінити /trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar
Змінити /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
Змінити /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
Змініть /trunk/Quackbot-Impl/lib/javarebel.stats
Додати /trunk/Quackbot-Impl/lib/jrebel.info
Змінити /trunk/Quackbot-Impl/nbproject/private/private.properties
Змінити /trunk/Quackbot-Impl/nbproject/private/private.xml
Змініть /trunk/Quackbot-Impl/nbproject/project.properties
Змінити /trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js
Додати / магістраль / Quackbot-Impl / плагіни / CMDs / Оператор / hostBan
Змінити /trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js
Змінити /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js
Змінити /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js
Змінити /trunk/Quackbot-Impl/plugins/listeners/onJoin.js
Змінити /trunk/Quackbot-Impl/plugins/listeners/onQuit.js
Змініть /trunk/Quackbot-Impl/plugins/testCase.js
Додати /trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js
Змінити /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java
Додати / trunk / Quackbot-Impl / vlc_http
Додати /trunk/Quackbot-Impl/vlc_http/current.html
Змінити /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
Змініть /trunk/Quackbot-Plugins/dist/README.TXT
Змінити /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
Змінити /trunk/Quackbot-Plugins/nbproject/private/private.properties
Змінити /trunk/Quackbot-Plugins/nbproject/private/private.xml
Змінити /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java
Додати / trunk / Quackbot-Plugins / vlc_http
Додати /trunk/global-lib/jrebel.jar

Так ...

Отже, для запитань:

• Назвіть кілька факторів, коли комісія стає занадто великою ( неочевидний матеріал )?
• Як можна запобігти таким вчинкам? Будь ласка, вкажіть конкретні дані
• Що робити, коли у вас на напівранні стадії розвитку, коли справи швидко рухаються? Чи все-таки все в порядку величезні?

Для мене у мене виникають проблеми, коли я намагаюся зробити "малі зобов'язання", оскільки я забуваю або створюю щось, що створює щось інше, що створює щось інше.

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

Проблема з великими комісіями:

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

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

(Інший випадок, коли ви робите початковий імпорт, але це НЕ проблематично з точки зору перерахованих вище питань.)

Принцип єдиної відповідальності.

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

Дуже часто буває, що у вашій робочій копії є багато окремих непов'язаних або напівзалежних змін. Це називається "проблема заплутаної робочої копії", і цього насправді дуже важко уникнути навіть дисциплінованим розробникам. Однак і Git, і Mercurial дають вам інструменти для її вирішення - вибір git add -p або chunk та черги Mercurial у TortoiseHg відповідно.

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

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

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

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

Початковий імпорт - це, мабуть, найбільші зобов’язання, які ви коли-небудь мали мати. Налаштування системи з нуля? Зрозуміло, є кілька великих зобов'язань. Після того, як ви вирівняли це, хоча настав час організувати все.

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

Цей приклад демонструє занадто великий комітет.

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

Щоб практикувати менші комісії, робіть нотатки у своєму блокноті (або в Блокноті) того, що ви вже змінили чи додали. Введіть, перш ніж він стане довгим списком або перед тим, як внести зміни коду, не пов’язані з тим, що у вас уже є в блокноті.

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

1. Запуск моделі з 3 місяців тому
2. Якщо помилка все ще виводиться, запустіть модель з 4,5 місяців тому
3. ... повторюйте, поки я не знайду прихильність, яка дає поганий результат

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

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

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

Наприклад, ви можете змінити кожен примірник __macro1на __macro2велику базу коду, яка змінює 200 файлів. 200 зобов'язань у цьому випадку не було б доцільним.

Що ви хочете в кінцевому підсумку - це можливість витягнути сховище під час будь-якої окремої редакції та працювати над збіркою. Ви змінилися з libfooна libbar? Я сподіваюся, що зміни також включають оновлення сценаріїв складання та Makefiles (або все, що застосовується).

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

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

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

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

Це не так питання "не робити великих зобов'язань", як робити невеликі зобов'язання - ідеальна істота для здійснення невеликих самодостатньо змін.

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

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

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

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

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

Принаймні, привчайте себе до виконання завдань, коли ви думаєте про себе: "Мені подобається мій прогрес досі, і я не хочу втрачати його, якщо зміни, які я збираюся внести, - це катастрофа". Тоді у вас є можливість скористатися VCS, щоб зняти будь-які тупики, які ви намагалися, або спеціальний код налагодження, який ви додали, щоб відшукати проблему. (наприклад, з git reset --hardабо rm -rf *; svn update)

Немає жодного жорсткого і швидкого правила, немає розділової лінії, повз яку ваша комісія завелика.

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

Я маю на увазі такі рекомендації:

• Один коміт повинен включати зміни лише для одного виправлення помилки
• Одне зобов’язання не повинно включати більше півроку роботи
• Один коміт не повинен порушувати збірку

Звичайно - це те, що я маю на увазі - YMMV. Різні розробники надають перевагу різному рівню деталізації.

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

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

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

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

Використовуючи dvcs, ваш робочий процес може виглядати так:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

Використання централізованого ПК

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

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

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

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

Повідомлення фіксації мають бути лише одним рядком (а для git максимум 60 символів). Кількість введеного коду має бути достатньо невеликою, щоб утримувати описове повідомлення в межах цієї межі.

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

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

git citool може дозволити вам вибрати, які конкретні номери файлу (або які конкретні рядки) зробити в певному фіксації, так що ви можете розбити (не перекриваються) зміни, внесені до одного файлу, на кілька комітетів.

(Схоже, ви використовуєте Subversion. Я не знаю, який інструмент робить це для Subversion, але ви можете розглянути можливість використання git-svnадаптера Subversion для git, який змінить ваше життя.)

Чим більше комісія, тим більша ймовірність, що ви зламаєте збірку та отримаєте виплату рештою своєї команди. Я намагаюся вносити зміни два рази на день. Незадовго до обіду і перед тим, як поїхати додому. Тож @ 12:00 та 16:30 я намагаюся зробити все працюючим і готовим до виконання. Я вважаю, що ця практика працює для мене.

Щоб відповісти на ваші запитання:

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

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

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

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

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

Я також хотів би зазначити, що правила трохи змінюють такі системи управління версіями (DVCS), як Mercurial та Git. У випадку, коли ви використовуєте одне із них, ви здійснюєте виконання кожного разу, коли ви внесли зміни, але ще не перевірили його, а потім перейдете до центрального сховища, коли воно працює. Це бажано, оскільки воно дозволяє переглянути більше змін у вашому коді, не переживаючи про порушення збірки.

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

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

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

До мене розробник ніколи не використовував систему контролю версій.

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