Які є хороші практики перед тим, як перевірити вихідний код? [зачинено]

Моя команда використовує сервер Team Foundation Server для контролю джерела, і сьогодні я виправив кілька програм із помилками та димом, перш ніж перевірити його, але забув прокоментувати якийсь код. (Цей код зробив інтерфейс трохи дивним.)

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

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

Ніколи не слід перевіряти коментований код. Якщо у вас є код, який потрібно коментувати перед реєстрацією, ви робите це неправильно.

Що стосується правил:

1. Отримати останнє
2. Виправити конфлікти злиття

3. Побудувати

   3.1 Виправити помилки побудови

4. Виконати тести

   4.1 Виправити зламані тести

5. Перейдіть до 1 (поки нічого нового не можна отримати)

Поскаржись лише тоді, коли всі кроки виконані.

Дивіться танець реєстрації .

Інші добрі практики:

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

Я не намагаюся тут бути занадто великим штаном, але припущення в цьому питанні (і всі, крім однієї з відповідей) здебільшого стосується централізованих VCS, таких як TFS, SVN, Perforce тощо.
Досить справедливо, це що використовує ОП.

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

Три речі, яких я не бачив в інших відповідях:

Додайте нові файли

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

Повернення незмінних файлів

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

Перевірте подану комісію

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

Дві речі, коли я використовую Git:

Атомні зобов'язання:

• Лише стадії індивідуальні функціональні зміни для фіксації.
• Зробіть зобов’язання якомога меншими. Зробіть їх легкими для виправлення, повернення та розуміння.
• Я використовую, git add --patchщоб розділити свою зміну на кілька частин, якщо це необхідно.

Перегляд відрізняється під час підбиття підсумків

• Я завжди реєструюсь, git commit --verboseщоб побачити різницю змін, коли я набираю своє повідомлення про фіксацію. (Або я використовую свій виправлений git-vim, щоб показати різницю.)
• Це значно полегшує перегляд змін та опис усієї комісії. Інколи на цьому етапі я вловлюю ненавмисні зміни. (Опис змін зміни допомагає вам думати про це.)

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

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

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

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

Шукайте та замінюйте прокляті слова ;-)

Якщо ви заїжджаєте в Windows, перевірте, чи у вашому коді немає таких невидимих ​​^ М символів - редактори в UNIX часто дають причини помилок / попереджень.

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

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

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

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

Коли це можливо, я люблю асоціювати реєстрацію з робочим предметом. Це дає вам деяку контекстуальну інформацію про ЧОМУ це було змінено, а не тільки ЩО було змінено. TFS має досить пристойну систему відстеження робочих предметів, тому це досить банально робити під час реєстрації.

(це додатково до перегляду різних моїх змін)

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

Таким чином, ваш набір змін (пов’язаний із робочим елементом) містить саме ті файли, які необхідні для задоволення робочого елемента.

Щоб об’єднати всі відповіді тут і дати повний контрольний список

1. [реєстрація / реєстрація] ви не повинні відвідуватись безпосередньо в потоці, в якому працюють інші. У вас повинна бути стратегія потоку: наприклад, на розробника - потік, в якому ви можете зареєструватися та перевіритись самостійно, не турбуючи інших: ваша робота буде будьте в безпеці, але у власному потоці розвитку так [лише у власному потоці розвитку]. З кожним реєстрацією ви пов'язуєте його із записом змін, щоб ваші зміни були атомними проти тієї зміни, яка називається набором змін (щоб ви могли поширювати окремі rfc / помилки тощо ... без необхідності доставляти "все").

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

3. [Повна версія] Якщо все нормально, перевірте всі зміни, які ви тільки що отримали з командного потоку: ваш власний потік оновлений

4. [Доставити] тепер доставіть вашу роботу в командний потік. Якщо ви не хочете доставити все, ви також можете вибрати, наприклад, 1 конкретну RFC з вказаними конкретними версіями файлів або набором вирішених / дефектів RFC.

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

6. [завершити доставку] завершіть вашу доставку, і ваша робота зараз у командному потоці.

Щоб зробити його складнішим: оскільки існує ймовірність того, що робота, яку ви доставили = ок, АЛЕ ви вже працюєте над подальшою версією, ви повинні базуватись завжди після доставки та вказувати, яку базову лінію ви бажаєте, щоб інші користувачі переобладнали . Це гарантує, що інші розробники отримують рекомендовану, а не останню версію потоку (якщо ви працюєте за таким сценарієм). Це також Потрійна перевірка, так що навіть якщо останні версії в командному потоці є "поганими", вони все ще не ті, на які інші перезавантажуються або переглядають, а ваш менеджер конфігурацій може, ніж об'єднати попередню версію з наступною версією, щоб скасувати ваша доставка.

• відповідь від істинності буває 2 рази: на кроці 2 та 6
• відповідь від «Одід» про танець при реєстрації: idem, але додатковий шар доставки та перезавантаження при реєстрації / виїзді, щоб переконатися, що ви працюєте ізольовано, а помилки завжди легко усуваються навіть на більш пізніх етапах
• відповідь відповів guildsbounty: отримати найновіший - це крок 2. Для збірки: це дійсно залежить, якщо у вас є збірка ... у моєму світі у вас є вхідні дані з моделей даних, текстових документів, аркушів вимог, налаштування даних з informatica, siebel, і т. д., і так, також Java-код, .net-код тощо ..., що всі повинні поєднуватися разом. Отже, тут насправді немає «збірки», але більше інтеграції, що вище, залежно від того, якщо цей єдиний, наприклад, збірка із вашого «коду» інтегрується з усіма іншими речами, оскільки ви не можете точно знати, чи це інтеграційний матеріал і залежно від у їхніх тестових середовищах це може бути складено, необхідні речі або при більш високих поставках інша збірка, оскільки вона потребує чогось від іншої команди.
• відповідь від guildsbounty на коментування та необхідна: я думаю, що будь-яке середовище, в якому ви не маєте інтеграції ВЕРСІЇ та зміни в наборах змін (і тип: дефекти, RFC, гарячі місця), не є зрілим. Я думаю, що це хаос, якщо ви не можете, наприклад, автоматизувати нотатки про випуск із кількістю поданих помилок та rfcs, які можна натиснути на точні версії, на які торкаються (оскільки, наприклад, версія 1 та версія hello.c 3 можуть бути доставлені, але версія 2 не слід було доставляти, тому що цей матеріал буде частиною пізнішого випуску, але деякі нооби вже ввели його) (значить, це означає ручне рішення, ЯКЩО ви також хочете вийняти версію 3 привіт. c АЛЕ зняття версії 3 означає, що ви також повинні вилучити всі інші версії, які торкнулися цього RFC / дефекту, тому вам потрібно мати можливість легко та швидко за допомогою інструменту, щоб вийняти повну річ) (навіть якщо кілька розробників працювали над частинами той самий RFC), але принаймні вам потрібні речі навколо нього, щоб визначитися з ним тощо ...). Додаткова документація завжди зручна, але, поєднуючи набори змін, ви отримуєте повне коло: версія <- набір змін <- робочі елементи <- квиток / rfc / дефект <- вимога. Значення: ви знаєте, які вимоги повністю або повністю поставлені: одна вимога має декілька RFC або помилок або що завгодно. У RFC є кілька робочих предметів для декількох осіб. цей робочий елемент відповідає набору змін, що існує у наборі версій (наприклад, версії 1 та 3 hello.c в потоці інтеграції, які звичайно НЕ версії 1,
• коментар від luis.espinal: не розбивайте збірку, перевіряється в ребазі та переносять доставку ... Є більш високі поставки для "менеджерів випусків та створення мейстрів", які повинні бачити набори змін та базові лінії як свою інформацію. "Ніколи не працюйте безпосередньо на головній гілці" так, структура потоку може бути великою або простою, але по суті: розробники мають власний потік, вони доставляють до командного потоку, який доставляє до потоку випуску. -> щоб поставки з усіх команд (наприклад, команда з документації, команда з вимогами, команди розвитку,

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

Деякі з наведених нижче застосовуються більше, ніж інші (або в різних формах), залежно від вашої SCM, і ось тут:

1. Не порушуйте збірку - перевірте лише компільований код.
2. Прокоментуйте свої реєстраційні картки (і, можливо, ваші виїзди, якщо SCM дає вам такий варіант.)
3. Не тримайте речі без перевірки протягом тривалих періодів часу.
4. Заїжджайте часто (якщо можливо, кілька разів на день)
5. Етикетка змістовно.
6. Етикетки регулярно.
7. Ніколи не працюйте безпосередньо на головній гілці.
8. Кожен випуск у виробництво повинен мати власну етикетку (і, якщо можливо, лише гілку, що відключається від головної гілки). Коли це можливо, зробіть те ж саме для тестових релізів UAT / Integration / Pre-production.
9. Ви повинні мати можливість будувати саме те, що є на виробництві, з того, що є у вашій SCM та на етикетці.

ПРИМІТКА : деякі пункти вище здаються досить очевидними, але ви не повірите, скільки людей насправді працює над основною галуззю або вносить зміни в виробництво спочатку, а потім створюють дельти, щоб перейти на контроль версій ... безпосередньо на головну гілку. .. і з етикетками. Солодкий, як зброджена жовч, змішана з немитим соком пахви ... так, так.

Майте особистий контрольний список. Почніть пустувати, коли заплутаєтесь, при вході. Коли він набуде другого характеру, видаліть його зі списку.

Виконати тести. Якщо вони пройдуть, перевіряйте це. Якщо ви зіпсуєте і якась річ пройде тести, тоді напишіть тест.

Ми робимо наступне ...

1. Тест - Ми хочемо переконатися, що він працює. Принаймні, ми хочемо знати, що це нічого не порушує.

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

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

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

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

Запустіть свої тести на пристрій, над якими ви так старанно працювали. Зелений - це добре.

Переконайтесь, що ваш код правильно відформатований (наприклад, для Java: виберіть код і натисніть Ctrl-Shift-F у Eclipse). Але будьте обережні, роблячи те саме для цілого документа.

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

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

Шукайте частини змін, які можуть входити як окремі одиниці.

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

Я вважаю за краще перевірити в кожному рефакторингу окремо, власний опис змін, як це:

РЕФАКТОРИНГ: Перейменуйте X на Y

X мав сенс раніше, тому що ... але зараз це має бути Y. Це пов'язано з роботою над номером 9.

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

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

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

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

Я тримаю місцевий hpo repo для своєї роботи.

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

Я не стверджую, що це найкращі, але вони працюють на мене.

Коли я пишу код, на який я знаю, що він не призначений для реєстрації, я додаю перед ним рядок, що містить "// TEMP:", а після нього - "// END TEMP.". Це разом із тим, що робити різницю перед тим, як зареєструватися, обіцяє, що я не перевіряю цей код помилково.

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

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