SQM 20/24: Commits Density [software quality crash course] [eng sub]

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

• Рассматриваются системы контроля версий, такие как Git, Subversion, Mercurial.  

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

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

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

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

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

• Мерч с подачей, часто ассоциируется с мерджи в гетлабе.  

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

• Хэт манс - метрика, которая показывает динамику комитов.  

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

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

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

• Фичер бранч - шлюпка для разведки на острове.  

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

• Чем более дисциплинированы комиты, тем лучше программист.  

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

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

• В видео анализируются комиты из 33 тысяч мерж-реквестов.  

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

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

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

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

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

• инженеринга и стал отдельной сферой науки.  

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

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

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

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

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

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

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

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

• Авторы утверждают, что наиболее удобоваримые размеры комитов - от двух до четырех файлов и от шести до сорока шести строк в одном комите.  

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

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

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

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

• В видео обсуждаются три категории комитов: сингл коиц (от одного до ста строк кода), агрегейт (от ста до десяти тысяч строк кода) и реп-факторинги (более десяти тысяч строк кода).  

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

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

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

• Они предлагают делать короткие комиты, чтобы решить эти проблемы.  

• В 2010 году исследователи обнаружили, что 89% комит месседжей, сгенерированных машинами, были приемлемыми для понимания.  

• В 2020 году исследователи обнаружили, что 14% комит месседжей были пустыми, а 66% содержали менее 15 слов.  

• В 2021 году исследователи обнаружили, что 84% сгенерированных комит месседжей не теряли важную информацию.  

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

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

• Чат G5 и Юникскодер не справляются с автоматической генерацией комитов.  

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

• Предпочитать малые комиты большим.  

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

• Делать комиты, когда чувствуешь, что пора отдохнуть.  

• Не забывать делать комиты, когда отходишь от компьютера.  

• Не комитить автогенерированные файлы.  

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

• В тайтле комита должно быть не более 50 символов, остальные строки не должны быть длиннее 72 символов.