SQM 1/24: Lines of Code

• Курс состоит из 24 лекций по 80 минут.  

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

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

• Инженерный подход: решение прикладных задач с использованием накопленных знаний.  

• Пример: ремонт трубы с использованием инструментов.  

• Научный подход: обобщение решений и доказательство их применимости через эксперименты.  

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

• Ученый проводит эксперименты для подтверждения своих гипотез.  

• Пример: сравнение алгоритмов сортировки на множестве массивов.  

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

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

• Не все студенты смогут довести исследования до конца, но это ценный опыт.  

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

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

• Компании ценят сотрудников, которые вносят вклад в науку.  

• Автор делится опытом найма сотрудников и важности научных публикаций.  

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

• Принцип скептического подхода в науке: доказательства важнее веры.  

• В науке нет презумпции невиновности, как в юриспруденции.  

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

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

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

• Необходимо предоставить доказательства его эффективности.  

• Доказательства могут быть экспериментальными или формальными, как у Эйнштейна.  

• Публикации на конференциях подтверждают доказательства и теоремы.  

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

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

• Преподаватель может помогать в написании статей и давать рекомендации.  

• Успех курса оценивается по количеству опубликованных статей.  

• Рекомендуется активно участвовать тем, кто стремится к карьерным успехам.  

• Курс состоит из 24 лекций, каждая из которых посвящена одной метрике.  

• Цель курса – измерить качество программного кода, выпускаемого программистами.  

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

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

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

• Преподаватель будет помогать студентам в оформлении и анализе данных.  

• LOC Line of Code — одна из первых метрик для программистов.  

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

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

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

• Не рассматривается код, который еще не прошел компиляцию.  

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

• Практикующие программисты часто считают, что работающий код уже хорош.  

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

• Нет единой системы ценностей для оценки качества кода.  

• Пример с функциями: 20 строк против 2000 строк.  

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

• Споры о качестве кода часто заходят в тупик.  

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

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

• Пример с функцией из 20 строк: выше мейнтейнабилити.  

• Чем короче код, тем легче его поддерживать.  

• Пример с книгами: короткие книги легче читать.  

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

• Нет единой метрики для измерения мейнтейнабилити.  

• LOC напрямую влияет на мейнтейнабилити.  

• Мечта создать единую метрику для оценки мейнтейнабилити.  

• Возможность использования ИИ для оценки мейнтейнабилити.  

• Пример с тысячей программистов, оценивающих код.  

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

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

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

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

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

• Связка между размером кода и его читаемостью очевидна.  

• Негативный импорт очевиден, но метрики пока нет.  

• Анализ кода в продакшене предотвращает написание ненужных условий.  

• Контроль качества кода и функциональное тестирование важны.  

• Повышение качества кода снижает количество дефектов в продакшене.  

• Функциональные дефекты связаны с читаемостью кода.  

• Трудно поддерживаемый код неизбежно ведет к дефектам.  

• Пример с сортировкой: изменения в коде могут привести к дефектам.  

• Новый программист может внести изменения, не понимая код.  

• Неправильные изменения могут привести к дефектам в продакшене.  

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

• Некачественный код ухудшается при внесении изменений.  

• Деградация кода приводит к "легаси" коду.  

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

• Нельзя продолжать вносить изменения в "легаси" код.  

• Необходимо требовать бюджеты на повышение читаемости кода.  

• Хороший программист должен настаивать на инвестициях в качество кода.  

• Введение метрик для улучшения качества кода.  

• Пример с метрикой "сайт" и её снижением.  

• Важность работы с несколькими метриками для общего улучшения.  

• Пример с длиной класса в Java.  

• Снижение средней длины класса с 2800 до 1000 строк.  

• Влияние снижения длины класса на maintainability.  

• Скептицизм разработчиков и ученых по поводу метрики "лайн код".  

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

• Влияние размера кода на его качество.  

• Сравнение языков Java и Ruby по "болтливости".  

• Java требует больше строк кода для реализации алгоритма.  

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

• Возможность чрезмерного сокращения кода.  

• Вопрос читаемости кода при сжатии.  

• Необходимость комбинации метрик для улучшения кода.  

• Опасности чрезмерного сжатия кода.  

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

• Примеры, когда сжатие может быть оправдано.  

• Нет объективной метрики для оценки кода.  

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

• Стандарты написания кода помогают избежать субъективности.  

• Стандарты кода, такие как стайл-гайды, определяют принципы написания кода.  

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

• Чекиры напоминают о нарушениях форматирования.  

• Метрика "лайнзу" стремится к снижению количества строк кода.  

• Другие метрики, такие как читаемость, могут конфликтовать с "лайнзу".  

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

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

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

• Чем сложнее код, тем ниже его читаемость.  

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

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

• Важно поощрять как короткий, так и подробный код.  

• Жесткий автоматизированный контроль качества кода важен.  

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

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

• Программисты часто выделяют функции для уменьшения количества строк кода.  

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

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

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

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

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

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

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

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

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

• Метрика NCS Number of Statements подсчитывает количество отдельных операторов в коде.  

• В отличие от Lines of Code, NCS учитывает комментарии и символы, такие как точки с запятой.  

• В Java NCS считает количество открывающихся скобок и символов точки с запятой.  

• Пример кода показывает, как NCS считает количество операторов.  

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

• NCS более точен, чем Lines of Code, особенно для языков, где комментарии и пустые строки учитываются.  

• Метрика кода СС учитывает только полные строки кода, включая комментарии и пустые строки.  

• Для разных языков программирования требуется разный коэффициент для перевода СС в строки кода.  

• Пример: для Java СС умножается на 2.8, для C++ — на 1.7, для Ruby — на 1.  

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

• Компьютер ожидает стейтменты как цельные команды, а не отдельные строки кода.  

• Многострочные инструкции могут усложнять чтение кода программистами.  

• Метрика кода делится на три составляющие: комментарии, пустые строки и остальной код.  

• Для анализа функциональности интерес представляет только третья категория.  

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

• В ядре Linux около 27.8 миллионов строк кода.  

• Предположительно, комментарии составляют около 20%, пустые строки — около 7%, остальной код — около 73%.  

• Для проверки можно использовать скрипт lint для подсчета строк кода.  

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

• Для проверки можно клонировать ядро Linux и запустить скрипт lint.  

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

• Программисты часто не знают размер своих проектов.  

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

• Размер проекта измеряется строками кода, а не классами или функциями.  

• Количество строк кода — универсальная метрика для оценки размера проекта.  

• Пример: проект с миллионом строк кода в 20-30 раз меньше, чем Linux.  

• Опыт автора: максимальный проект — 220 тысяч строк кода.  

• Большие проекты следует разбивать на подпроекты.  

• Комфортный размер проекта — 10-50 тысяч строк кода.  

• Проекты свыше 50 тысяч строк кода рекомендуется разбивать на части.  

• GitHub хранит 30 миллионов строк кода в одном репозитории.  

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

• Роберт Мартин предложил идеальный размер Java-класса — 200 строк кода.  

• Анализ нескольких опенсорсных проектов подтвердил эту цифру.  

• Java в два раза более болтлива, чем Ruby.  

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

• Промежуточный код обычно более объемный, чем исходный язык.  

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

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

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

• Собраны датасеты с метриками для Java-файлов из опенсорсных репозиториев.  

• Данные включают более 750 тысяч Java-файлов и почти миллион строк кода.  

• Исследователи могут использовать эти данные для своих исследований.  

• Анализ данных по таблицам.  

• Возможность дополнительного анализа с использованием парсера.  

• Использование Python и опенсорсных библиотек для парсинга Java-файлов.  

• Сбор данных.  

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

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

• Выполнение шагов метода.  

• Запись результатов в главе "Результаты исследования".  

• Указание конкретных цифр и данных.  

• Поиск похожих работ на Google Scholar.  

• Цитирование актуальных статей.  

• Указание недостатков предыдущих исследований.  

• Формулирование выводов на основе анализа данных.  

• Сравнение текущих данных с данными прошлых лет.  

• Возможные направления для будущих исследований.  

• Написание раздела "Метод" как рецептуры.  

• Описание шагов для достижения целей исследования.  

• Избегание прямого упоминания своих действий.  

• Пример статьи объемом четыре страницы.  

• Изучение формата статей на конференциях.  

• Планирование отправки статьи на конференцию в марте-апреле.