SQM 1/24: Lines of Code

• Новый курс, 24 лекции по 80 минут.  

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

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

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

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

• Важно понимать разницу между инженерным и научным подходами.  

• Инженерное решение: использование готовых инструментов и алгоритмов.  

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

• Примеры: создание архитектуры программного решения и проведение экспериментов.  

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

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

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

• Курс помогает стать как инженерами, так и учеными.  

• У каждого студента есть исследовательская тема.  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Курс будет мотивировать студентов на активное участие и достижение успехов в работе.  

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

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

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

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

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

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

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

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

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

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

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

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

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

• Пример: функция из 20 строк может быть качественнее, чем функция из 2000 строк.  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Легаси код содержит накопленный технический долг и проблемы с юзабилити.  

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

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

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

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

• Пример с метрикой "сайт", которая может быть снижена для улучшения читаемости кода.  

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

• Пример с длиной кода в Java: текущая длина 280 строк, цель снизить до 1000 строк.  

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

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

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

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

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

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

• Короткий код на Ruby означает более высокое качество кода.  

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

• Пример сжатия кода на Java: сокращение с 100 строк до 20 строк.  

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

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

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

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

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

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

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

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

• Важно изучать существующие исследования для улучшения кода.  

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

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

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

• Лайнзу поощряет короткий код, а другие метрики — более подробный.  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Метрика количества строк кода применима, но не всегда точна.  

• Метрика NSS non-statement count учитывает количество непустых строк кода.  

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

• NSS более точна, чем количество строк кода, и учитывает отдельные стейтменты.  

• Метрика SS считает только один стейт, даже если он содержит несколько строк кода.  

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

• Для Java SS умножается на коэффициент 2.8, для C++ - на 1.7, для Ruby - на 1.  

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

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

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

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

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

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

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

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

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

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

• Важно оценивать размер проекта и помнить эту цифру.  

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

• Оптимальный размер проекта для комфортного программирования составляет 10-50 тысяч строк кода.  

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

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

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

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

• Пример с Java: Роберт Мартин предложил идеальный размер класса в 200 строк кода, основанный на анализе открытых проектов.  

• Java в два раза более болтлива, чем Ruby, что может влиять на качество кода.  

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

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

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

• Использование Java упрощает работу, так как есть большой датасет для анализа.  

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

• Автор и его команда создали датасет с 750 тысячами Java файлов и почти миллионом строк кода.  

• Датасет включает метрики, такие как количество строк кода и строк комментариев.  

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

• Используйте таблицы для анализа данных.  

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

• Напишите скрипт для сбора данных, используя Python и библиотеки для парсинга Java-кода.  

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

• Напишите метод в виде инструкции, как проводить исследование.  

• Согласуйте метод с другими и выполните все шаги.  

• Запишите результаты в виде главы.  

• Укажите, какие шаги были выполнены и какие результаты получены.  

• Опишите, как метод был применен на практике.  

• Найдите похожие работы на Google Scholar.  

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

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

• Сделайте выводы на основе проведенного исследования.  

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

• Используйте факты и фантазию для убеждения читателя.  

• Напишите метод в виде короткой инструкции.  

• Описывайте шаги так, как будто вы рекомендуете их кому-то другому.  

• Укажите, какие результаты были получены.  

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

• Статья должна быть короткой, около четырех страниц.  

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