Обсуждение "How to enforce coding standards automatically."

[RXL]

https://forum.shelek.ru/index.php/topic,26526.msg266969.html#msg266969
Точнее, статью я еще не прочел, а пока только комментарий по ссылке.

Вот такой пример: разработчиком внесены изменения в код, он отлажен и протестирован, но за это время в репозиторий выли внесены изменения другим разработчиком (ну, мало ли по каким причинам).
Выходит, что нужно сливаться с репозиторием и тестировать все заново. Верно?
А ведь и после этого ситуация может повториться. Хорошо, если тестирование занимает не много времени, а если это длительный процесс?

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

[Dimka]

RXL, нужно делать полный build и тестирование. Нередко это делают ежедневно (или еженочно, если автоматизировано).

Если требуется всегда иметь рабочую версию в репозитории, архитектор определяет ветки (бранчи) изменений: от стабильной версии (где баги фиксят) ответвляет нестабильную (где допустимы указанные тобою коллизии); когда все изменения внесены, нестабильная ветка сливается со стабильной.

Т.е. это всё организационные вопросы.

[Dale]

Вот такой пример: разработчиком внесены изменения в код, он отлажен и протестирован, но за это время в репозиторий выли внесены изменения другим разработчиком (ну, мало ли по каким причинам).
Выходит, что нужно сливаться с репозиторием и тестировать все заново. Верно?
А ведь и после этого ситуация может повториться. Хорошо, если тестирование занимает не много времени, а если это длительный процесс?

Да, такая опасность теоретически действительно есть. Поэтому при использовании TDD нужно придерживаться ряда нехитрых правил.

Прежде всего, тесты должны проходить быстро, в идеале - порядка минуты на весь набор. Золотое правило TDD: тестирование не должно быть обременительным, иначе от него начнут отлынивать, а неполное тестирование - это отсутствие тестирования. Задержка от него должна быть незначительна.

Далее, итерации при гибких технологиях должны быть небольшими. При этом меньше шансов получить конфликт при слиянии версий, чем когда "зачекиненный" модуль подвергается коренной переделке и неделями болтается в рабочей директории разработчика.

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

Но, хотя указанная проблема действительно может иметь место, вообще говоря, данная статья не о тестировании, а о соблюдении стандартов кодирования. Коллектив может выработать свой собственный стандарт, заимствовать один из готовых стандартов (например, MISRA), или его может обязать к этому заказчик. За соблюдением стандарта могут следить специально уполномоченные люди, либо могут периодически проводиться коллективные обзоры кода на предмет таких нарушений. При этом многие нарушения можно обнаружить автоматизированными средствами. Вот примеры нескольких требований MISRA, которые вполне может проверить компьютер:

• 9 (req): Comments shall not be nested
• 13 (adv): The basic types char, int, short, long, double and float should not be used. Specific-length equivalents should be typedef’d for the specific compiler, and these names used in the code
• 14 (req): The type char shall always be declared as unsigned char or signed char. See rule 13
• 30 (req): All automatic variables shall have a value assigned to them before use

(Кстати, по поводу нарушения правила 13 у нас недавно была беседа в теме о выкрутасах компилятора C для PIC. Если бы мы уговорились следовать MISRA, вопрос вообще не мог бы возникнуть).

Вот именно о таких инструментах и идет речь в статье, поскольку вручную находить подобные промахи трудно, а правила языка они не нарушают, поэтому компилятор к ним претензий не имеет. Работают эти инструменты быстро и тормозить процесс не будут.

[RXL]

Спасибо, достаточно исчерпывающе.

Насчет intN_t и uintN_t совершенно согласен - для embedded лучше придерживаться строгих размеров типов. Не уверен, годится ли этот подход для РС, т.к. может оказаться просто не оптимальным (например, при переходя с 32-х на 64-битную архитектуру).

Dimka, сталкивался я с opensource (Redmine), где все наоборот: баги правят сразу в trunk, а вот стабильные версии ответвляют в branches и постепенно сливают туда изменения из trunk.

[Dale]

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

Суть ее в том, что еще с времен Брукса и его идеи "бригад главного программиста" существует традиция периодически устраивать обзоры кода, когда автор представляет на суд комиссии свое творение, а члены комиссии критикуют его по всем статьям - от явных ошибок и несоответствий спецификациям до стилистических погрешностей и неточных комментариев. При этом очень часто свежий незамыленный глаз легко находит ошибки, незаметные самому автору, и поэтому обзоры кода считаются весьма доступным, недорогим и эффективным средством повышения качества кода. Несоответствия стандартам кодирования тоже относятся к таким недочетам.

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

Вот как-то так задумывалось, но пало жертвой краткости...

сталкивался я с opensource (Redmine), где все наоборот: баги правят сразу в trunk, а вот стабильные версии ответвляют в branches и постепенно сливают туда изменения из trunk.

Подход, который упомянул Dimka, более традиционен: основная линия разработки идет в trunk; разные эксперименты ставятся в branches, и там же исправляются серьезные ошибки, которые требуют много времени, а останавливать разработку нельзя; Стабильные версии фиксируют в tags.

Кстати, весьма достойная тема для статьи - "Паттерны управления версиями". И актуальная для большинства, и в то же время весьма скудно освещенная в массовой литературе. Там же можно рассмотреть типовые структуры директорий проекта.

[RXL]

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html

Вот, к примеру, два паттерна: ветвление для релизов и ветвление для фич.

Пример release branches (плюс еще и ветки на багфиксы)

Вот еще: http://www.cmcrossroads.com/bradapp/acme/branching/#Participants


Кстати, интересный раздел по злоупотреблениям: http://www.cmcrossroads.com/bradapp/acme/branching/#BranchingTraps

[Dale]

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

Или, может, просто я к нему давно привык и он мне кажется более естественным... Я изучал управление версиями по этой книге: https://forum.shelek.ru/index.php/topic,26526.msg254406.html#msg254406 .

[RXL]

Dale, вторая дока более общая и, возможно, ориентирована на другую VCS.


"Pragmatic Version Control using Subversion"
Интересно, существует ли это в переводе и как может называться?

[Dale]

Да, но теги не являются особенностью SVN. Я пользовался ими до SVN, когда на предприятии стандартом была CVS. Сейчас вместе с Visual Studio в ходу Visual SourceSafe, там тоже подобная структура (хотя в духе Microsoft некоторые термины заменены другими, аналогичными; например, вместо tag там label). Так что паттерн выпуска релиза достаточно универсален.

Добавлено через 3 минуты и 59 секунд:

"Pragmatic Version Control using Subversion"
Интересно, существует ли это в переводе и как может называться?

Я давно слежу за книгами издательства Pragmatic Programmer, с удовольствием перечитал многие из них. Ни единой не видел в переводе, не только эту. Похоже, наши издатели предпочитают работать с гигантами типа O'Reilly.

[RXL]

Я выложил у нас копию - благо она доступна в инете в виде pdf, но на поиск нормальной скачки уходит время.

Добавлено через 9 минут и 9 секунд:
Думаю, что статья на эту тему была бы полезна.

[Dale]

Еще рекомендую обратить внимание на эту, близкую по теме: http://pragprog.com/book/auto/pragmatic-project-automation . Сам на нее давно точу зубы, только никак не решусь погрузиться, это же надо на одном дыхании осваивать, от начала до конца.

[Dimka]

Dimka, сталкивался я с opensource (Redmine), где все наоборот: баги правят сразу в trunk, а вот стабильные версии ответвляют в branches и постепенно сливают туда изменения из trunk.

Я исхожу из аксиомы, что даже в релизе присутствуют пока не найденные баги. Поэтому мне не очень понятно, как можно, с одной стороны, оперативно исправлять баги и рассылать патчи пользователям, и, с другой стороны, работать над следующей версией - изменяя имеющиеся и добавляя новые фичи. Это должны быть разные ветки. Но исправление багов должно происходить в обоих ветвях (если в новой ветке соответствующие места не были модифицированы до потери бага).

Сейчас вместе с Visual Studio в ходу Visual SourceSafe

Я бы сказал, сейчас вместе с Visual Studio в ходу TFS (Team Foundation Server) - особенно это касается Team Suite редакции. В частности, там есть автоматизация сборок для solution и тестирования (если специальный проект тестов включён в solution), подсистема Work Items - как нечто среднее между списком задач (с ответственными и отчётами о состояниях), bug-list (с историей правок) и репозиторием для проектной документации; и ещё развитая система авторизаций и управления доступом (если это нужно какой-то команде).

[Dale]

Я бы сказал, сейчас вместе с Visual Studio в ходу TFS (Team Foundation Server) - особенно это касается Team Suite редакции.

Когда нам прислали коммерческое предложение на весь комплект TFS (лицензии на рабочие места + серверные лицензии), руководство настоятельно рекомендовало поплотнее закатать губы. Там получилось чуть меньше $12.000 на рыло разработчика. Довольствуемся более скромными редакциями по цене ~4.000. Полагаю, по этой причине у нас в стране TFS - не самый популярный продукт, народ больше налегает на бесплатные альтернативы.

[Dimka]

Dale, ты прав. Я с TFS работал в рамках среднего размера компании (до нескольких сотен человек), и она - золотой и платиновый партнёр MS, так что все такие решения доставались либо бесплатно, либо с существенными скидками.

[RXL]

Dimka, сталкивался я с opensource (Redmine), где все наоборот: баги правят сразу в trunk, а вот стабильные версии ответвляют в branches и постепенно сливают туда изменения из trunk.

Я исхожу из аксиомы, что даже в релизе присутствуют пока не найденные баги. Поэтому мне не очень понятно, как можно, с одной стороны, оперативно исправлять баги и рассылать патчи пользователям, и, с другой стороны, работать над следующей версией - изменяя имеющиеся и добавляя новые фичи. Это должны быть разные ветки. Но исправление багов должно происходить в обоих ветвях (если в новой ветке соответствующие места не были модифицированы до потери бага).

Очень просто: релизы не патчат. Вместо этого выпускают новые версии с багфиксами и новыми фичами.

[Dimka]

RXL, если это продукт, выбрасываемый на рынок для неопределённого круга частных пользователей - да. Если это разработка для конкретного заказчика, и она связана с какими-то критическими процессами и/или работой организации, внедрение новых фич отделено от багфикса. Внедрение - это процесс, который должен быть согласован и синхронизирован со всеми пользователями, проведено обучение, разработаны и своевременно выполнены процедуры перехода. Патч же ничего такого не предполагает - это просто замена исполняемых файлов.