SQM 12/24: Dead Code [software quality crash course] [eng sub]

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

• Рассматривается феномен "мертвого кода", который может быть причиной проблем с качеством кода.  

• Мертвый код может возникнуть из-за необходимости или рефакторинга.  

• Ученые считают, что наличие мертвого кода в репозитории создает проблемы для мейтена билити кода.  

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

• Авторы эмпирического анализа в 2003 году отметили, что наличие мертвого кода влияет на качество программирования.  

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

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

• Исследование, проведенное в 2016 году, показало, что в четырех программных продуктах, написанных на Java, обнаружено 540 неиспользованных методов, что составляет 10% от общего количества методов.  

• Это указывает на проблему с мертвым кодом в программных продуктах.  

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

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

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

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

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

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

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

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

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

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

• Автор провел эксперимент, в котором он проанализировал 240 репозиториев на Java.  

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

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

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

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

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

• Это может привести к росту размера репозитория и усложнению его управления.  

• Централизация: все игры и библиотеки хранятся в одном репозитории.  

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

• Синхрониз бейс: разработка идет в одной ветке, без активного ветвления.  

• Третье измерение: разработка на двух языках, с разными жизненными циклами.  

• Бэк-портинг: исправление дефектов в одной версии и их перенос в другую версию может быть сложным.  

• Комплектность: все зависимости и версии модулей хранятся в одном репозитории, без версий.  

• Крупные компании используют монорепозитории, но автор считает эту идею вредной.  

• Отсутствие версий может привести к сложностям в управлении и поддержке кода.  

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

• Монолитная репозитория может быть сложной для настройки и поддержки.  

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

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

• Репозитория содержит 86 терабайт данных, что может быть трудно загрузить на компьютер.  

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

• В моем понимании, это недостаток, так как репозитория слишком большая и неподъемная.  

• В прошлом, крупные компании имели десятки, сотни и даже тысячи серверов, на которых устанавливались одни и те же системы, такие как Linux, Apache, nginx, PHP и другие.  

• Это требовало много времени и усилий для настройки каждого сервера.  

• Появились средства автоматизации, такие как Chef и Puppet, которые упростили процесс настройки серверов.  

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

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

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

• Это позволило автоматизировать процесс настройки и установки контейнеров на серверах.  

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

• Он считает, что это проблема, которую нужно решать, а не просто игнорировать.  

• Инкапсуляция, на его взгляд, важнее, чем видимость кода.  

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

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

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

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

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

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

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

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

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