Чи коли-небудь добре робити код непрацюючого коду?

Чи корисно вимагати введення лише робочого коду?

Ця фіксація не повинна залишати сховище у робочому стані як:

• ... ми перебуваємо на ранній стадії проектування, код ще не стабільний.
• ... ви єдиний розробник проекту. Ви знаєте, чому все не працює. Крім того, ви нікому не зупиняєте роботу, роблячи зламаний код.
• ... код наразі не працює. Ми збираємось зробити це великою зміною. Давайте покладемо на себе зобов’язання, щоб мати крапку для повернення, якщо справи стають потворними.

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

  1. локальні файли
  2. місце постановки
  3. здійснює в місцевому відділенні
  4. здійснює віддалену галузь особистої функції
  5. злиття з віддаленою developгілкою
  6. злиття з віддаленою masterгілкою
  7. злиття з віддаленою releaseгілкою

• ... вчиняти рано, вчиняти часто.

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

Додано: Є кілька високоголосних коментарів, які говорять про те, що на місцевому етапі можна робити все, що завгодно. Однак мене не цікавить технічна сторона питання. Швидше, я хотів би вивчити найкращі практики - звички, які люди, які багато років працювали в галузі, наймилі продуктивні.

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

Однією з філософій розгалуження (розділ «Розробка стратегії розгалуження та політики кодування» в розширених стратегіях розгалуження SCM - також читайте найкращі практики Perforce , її pdf, але йдеться про деякі інші деталі) - це те, що ви займаєтеся неподільною політикою.

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

(з найкращих практик Perforce)

Скажімо, у вас є гілки "release" (або "master"), з яких побудований реліз, і "trunk" (або "dev"), де розробники перевіряють робочий код. Це політика галузей. Зауваживши, що "робочий код" є частиною гілки політики "dev", ніколи не слід вчинити порушений код у відділенні dev. Часто трапляються такі речі, як сервери CI, підключені до цих гілок, і перевірка зламаного коду в dev може зіпсувати всі відділення і зламати збірку.

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

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

(з найкращих практик Perforce)

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

Тож гілка, скажіть, що ця гілка може зламати код і взяти на себе зобов'язання.

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

Так, поки це не галузь випуску.

В особистих галузях все йде і потім можна відмовитися, якщо експеримент не спрацював. Це одна з головних переваг DVCS: свобода

Значення вчинення зламаного коду ?: співпраця та експерименти

Так, це нормально, і я щось роблю.

Сенс введення коду, який не можна компілювати (принаймні, у галузях) полягає в тому, що іноді ваш код є незавершеним, але що виконану роботу досі варто економити та / або ділитися з іншими

Мої практики:

• спочатку написати тести
• wip (незавершене) зобов’язання хороші
• здійснювати часто (кілька разів протягом дня) і рано (зберегти "робочі" кроки)
• натискати після кожного вчинення (якщо ваші жорсткі диски виходять з ладу / автобус потрапить у вас).
• завжди спочатку працюйте у філіях
• коли можливо лише злиття робочого коду до головного
• інтерактивна база даних в git, щоб скребнути wips перед головним злиттям

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Побудувати / випустити відділення

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

Інші галузі: Зберігайте стан часто

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

Розглянемо ці приклади, коли збережений стан забезпечує значну користь:

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

Здійснення зламаної бази кодів добре, якщо це локально.

Чому?

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

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

1. час, який використовується для подальших функцій, зараз витрачається на виправлення помилок ...
2. скорочення розвитку не виконано ...
3. товар не відправляється вчасно

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

Я не думаю, що це нормально, щоб зробити зламаний код.

Що станеться, якщо

• Потрібна термінова гаряча виправлення. Кодова база знаходиться в порушеному стані. Ви змушені відкочувати, виправляти та розгортати.

• Хтось ще починає працювати в тій же гілці, не знаючи, що ви вчинили несправний код. Вони можуть переслідувати «червону оселедець», думаючи, що їх зміни щось зламали.

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

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

Відповісти на @WarrenT

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

Деякі питання, які допоможуть вам визначити, чи правильно вводити непрацюючий код:

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

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

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