SQM 21/24: Builds [software quality crash course] [eng sub]

• Лекция о качестве программного кода и метриках, которые касаются репозитория в целом.  

• Рассматриваются метрики, касающиеся системы тестов, комментариев и билд систем.  

• Термин "континиус интеграйшн" был предложен в 1994 году.  

• Континиус интеграйшн - это процесс автоматической сборки и тестирования кода.  

• Сервер следит за изменениями в репозитории и собирает код для проверки на компилируемость.  

• Если код не компилируется, сервер сигнализирует о проблеме.  

• В 1997 году Майкрософт предложила идею непрерывной интеграции, где специальный билдмастер собирал код каждый день.  

• В 2006 году Мартин Фаулер ввел термин "континиус интегра" и предложил использовать метрику "длительность билда" для оценки качества практики.  

• В 1998 году Экстрим Программинг предложил принципы, включая "сначала пишем тесты, потом делаем все остальное" и "интегрируем несколько раз в день".  

• В 2006 году Фаулер предложил использовать юнит-тесты для проверки кода.  

• Фаулер предложил использовать метрику "длительность билда" для оценки качества практики непрерывной интеграции.  

• В курсе обсуждаются метрики для оценки качества тестирования и программирования.  

• Континиус интеграйшн - это процедура в проекте, которая позволяет обнаружить ошибки на ранней стадии.  

• Это уменьшает количество ошибок и позволяет их обнаруживать вовремя.  

• Если нет континиус интеграйшн, ошибки могут быть обнаружены только после интеграции кода в репозиторий.  

• Континиус деливери - это автоматизация сборки, упаковки и отправки продукта конечному клиенту.  

• Это позволяет сократить время на разработку и увеличить продуктивность команды.  

• Континиус деливери предполагает автоматическую сборку и отправку продукта по нажатию одной кнопки.  

• Обсуждение важности системы континиус интеграйшн для разработки программного обеспечения.  

• Система позволяет проверять качество кода ежедневно или постфактум, а также через префлайт-тесты или ресерч.  

• Увеличение частоты релизов и принятие пул реквестов.  

• Система сборки и контроля качества должны работать постоянно.  

• Континиус интеграйшн помогает избежать прокисших пул реквестов и повысить качество разработки.  

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

• Отсутствие страха сломать сборку позволяет вносить изменения в код с большим энтузиазмом.  

• В видео обсуждается использование Continious Integration (CI) для улучшения качества кода и уменьшения количества ошибок.  

• CI позволяет проверять изменения кода перед отправкой в продакшн, что делает процесс разработки более спокойным и расслабленным.  

• В видео анализируются метрики популярности проектов и использования CI.  

• Установлено, что проекты с большим количеством звезд чаще используют CI, но корреляция между этими показателями не установлена.  

• В видео обсуждаются результаты эмпирического анализа длительности билдов в проектах на GitHub.  

• Установлено, что средняя длительность билдов составляет несколько секунд, но некоторые проекты могут иметь длительность до 40 минут.  

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

• Однако, поддержание системы автоматических тестов и CI требует времени и ресурсов, что делает его трудозатратным и энергозатратным.  

• Автор обсуждает стоимость разработки с использованием континиус интеграйшн и юнит тестов.  

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

• Он подчеркивает, что хотя разработка с использованием континиус интеграйшн требует дополнительных усилий, в конечном итоге это будет быстрее.  

• Автор обсуждает флаги тестов, которые могут быть ненадежными и вызывать проблемы в сборке.  

• Он приводит статистику, согласно которой в неделю может происходить до десяти фейлов в системе.  

• Он также упоминает, что флаги тесты могут быть проблемой для больших систем сборки, таких как Google.  

• Он приводит пример, где 1,5% всех запусков сборки могут быть связаны с ошибками, вызванными флагами тестов.  

• Автор обсуждает, что флаги тесты могут быть причиной нестабильности в системе, так как они могут возвращать ошибки или не работать при повторном запуске.  

• Он также упоминает, что 84% переходов из состояния паз в состояние фейл связаны с флагами тестами.  

• Это означает, что многие тесты могут быть нестабильными и вызывать проблемы в системе.  

• Автор обсуждает, что история билдов может влиять на стабильность проекта, так как прошлая история может определять текущую стабильность.  

• Он также упоминает, что система сборки, которая моргает между красным и зеленым, может быть признаком проблем в репозитории.  

• В целом, автор подчеркивает важность понимания и управления флагами тестов и их влияния на стабильность системы.  

• В видео анализируется, как часто происходят провалы билд системы и как часто она переходит в красное состояние.  

• В последней колонке таблицы представлены цифры, показывающие, что в моем репозитории каждый второй билд красный.  

• Это нехорошо, и автор считает, что эта метрика является ключевой в оценке билд системы.  

• В видео говорится, что если количество билд фейлов увеличивается, то производительность программистов падает.  

• Это происходит из-за того, что программистам сложнее работать, когда билд красный, и они не верят в стабильность системы.  

• В видео обсуждается использование Gitlab и Gitlab Actions для настройки континиус интеграйшн в репозиториях.  

• Это позволяет программистам делать континиус интеграйшн прямо внутри репозитория и значительно улучшает качество кода и продукта.  

• В мультиплатформенной конфигурации тесты могут быть более хрупкими и чувствительными к ошибкам, что повышает их качество.  

• Важно делать тесты максимально неустойчивыми, чтобы они фейлились на разных платформах.  

• Погрешности чисел с плавающей точкой могут привести к фейкам.  

• Пример с генератором случайных чисел, где единица может быть 1.0, а не 0.99.  

• Тесты могут вызываться в разной последовательности на разных платформах, что может привести к фейкам.  

• Не отсортированные коллекции могут привести к фейкам, если они используются в тестах.  

• Вывод может быть разным на разных платформах, что может привести к фейкам.  

• Важно анализировать билд-процессы и их причины для улучшения качества тестов.