Чи є вчинення / перевірка коду щодня гарною практикою?

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

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

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

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

Редагувати: Я думаю, я мав би уточнити, що я мав на увазі "вчинення" в значенні цього CVS (він же "натиск"), оскільки це, мабуть, те, що Фаулер мав на увазі в 2006 році, коли він писав це.

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

Я не згоден з цим правилом і я згоден з тим, що сказав Мейсон Уілер . Я хотів би додати кілька ідей.

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

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

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

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

Всього мої 2 копійки.

EDIT

Ще одна причина проти передчасних комітетів, які мені прийшли в голову, - це те, що (дуже) баггі-версія не може бути перевірена. Якщо ви займаєтесь стволом і ваша тестова команда проводить тестування щодня, вони можуть не мати тестованої версії протягом декількох годин (або на день). Навіть якщо ви не намагаєтеся виправити помилку та просто відновити зміни, відновлення може зайняти пару годин. Скажімо, п'ять тестувальників, які працюють у вашій команді, ви витратили 5 х 2 = 10 годин часу команди через бездіяльність. Це сталося зі мною одного разу, тому я дуже намагаюся якомога швидше уникати передчасних зобов’язань в ім'я зобов’язань .

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

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

Обґрунтування цього два:

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

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

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

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

Одід дав дві важливі причини, щоб зробити код якомога частіше. Додам ще кілька:

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

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

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

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

Невеликі зміни набагато простіше в управлінні.

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

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

Я думаю, що більшість відповідей тут пропускає один із основних моментів у заяві Мартіна Фаулерса. Це пов'язано з постійною інтеграцією . Код, який не зареєстрований (висунутий / опублікований / об'єднаний) в основну лінію, не перевіряється.

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

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

Тепер, що добре в такому способі роботи?

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

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

Аргументи для перевірки щодня:

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

Аргументи проти перевірки щодня:

• Не потрібно чи не хочеться
• Ще не "прибрали" свій код, це безлад
• Не встигаєш

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

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

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

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

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

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

У сервісі Team Foundation ви можете "Покласти", що не є тим самим, як реєстрація, але просто робить резервну копію коду, щоб у випадку, якщо ваша машина помер, ви не втратили зміни.

Я також бачив програмні будинки, які мають "лінію розробника" та "основну лінію". Devs можуть безкоштовно зайти в рядок розробників, коли вони вважають за потрібне, і лише керівник команди має доступ до основної лінії, тому вони відповідають за копіювання коду з dev в main, коли воно готове до виробництва.