Сначала сформулируйте вопрос сравнения
Сравнить исходники можно с разными целями: найти изменения после сдачи, проверить наличие доработки, выявить общие фрагменты или сопоставить реализации функции. Для каждого вопроса нужен свой состав объектов. Универсальный «процент одинаковости программ» часто скрывает больше, чем объясняет.
Установите происхождение обеих копий и конкретные состояния кода. Папка, выгруженная вчера, может содержать иную версию, чем переданный ранее пакет. Если связь с исследуемым периодом не подтверждена, сравнение остаётся технически полезным, но относится именно к представленным экземплярам.
Разделите собственный и сторонний код
В проектах могут присутствовать библиотеки, типовые шаблоны, тестовые данные и автоматически созданные файлы. Совпадение общей зависимости объясняется иначе, чем совпадение специфического алгоритма. Поэтому перед подсчётами составляют перечень групп материалов и описывают, что вошло в каждую группу.
Исключения должны быть прозрачными. Нельзя убрать неудобные файлы и назвать остаток всей программой. Для стороннего компонента желательно установить название, версию и основание такой классификации. Если происхождение неизвестно, файл не следует автоматически объявлять ни оригинальной разработкой, ни общедоступной библиотекой.
Отдельного внимания заслуживают ресурсы и конфигурация. Два проекта способны иметь одинаковые программные модули, но по-разному работать из-за правил маршрутизации, настроек доступа или схемы данных. Сравнение только файлов с выбранным расширением не охватывает эти различия.
Учитывайте представление текста и параметры инструмента
Разные переводы строк, кодировки и форматирование способны создавать заметный текстовый шум. Git предусматривает преобразования окончаний строк через атрибуты файлов. Это означает, что байты рабочей копии и способ хранения текста нужно учитывать до интерпретации отчёта. Git: gitattributes.
Нормализацию выполняют на производной копии, сохраняя исходный материал. При этом не все пробелы и переносы безразличны для смысла программы. Нужно знать язык и тип файла, а не просто включать игнорирование всех различий оформления.
Git также использует настраиваемые пороги сходства при выявлении переименований и копирования. Полученный показатель характеризует работу конкретного алгоритма над выбранными файлами, а не вероятность авторства. Git: git-diff.
После автоматического поиска исследуют конкретные фрагменты: назначение, структуру, последовательность операций и возможное общее происхождение. Полезно приводить примеры как совпадений, так и существенных различий. Одинаковая функция ещё не означает одинаковую реализацию, а различающиеся имена переменных не исключают сходства структуры.
Чек-лист корректного сравнения
- Назовите вопрос: различия версий, наличие функции или поиск общих фрагментов.
- Зафиксируйте происхождение, версии и контрольные суммы сравниваемых комплектов.
- Отделите зависимости, шаблоны, ресурсы и сгенерированные материалы с объяснением критериев.
- Сохраните перечень включённых и исключённых файлов.
- Укажите инструмент, его версию, настройки и выполненные преобразования текста.
- Проверьте ключевые совпадения вручную и объясните их техническое значение.
- Разделите установленное сходство и гипотезы о причинах его возникновения.
Условный пример: большой общий каталог
Предположим, в двух проектах совпадает большинство файлов. При разборе оказывается, что основную часть составляет одна и та же сторонняя библиотека. Собственные модули расчёта различаются, а общий шаблон интерфейса был получен из одного стартового проекта.
Первоначальный общий процент не исчезает, но его смысл меняется. В отчёте нужно показать результаты по группам и назвать общий источник, если он установлен. При этом совпадение редкого специфического фрагмента требует отдельного анализа: большой объём стандартных файлов не делает его несущественным.
Почему вывод об авторстве требует других материалов
Техническое сравнение само по себе не определяет, кто первым создал фрагмент, кто перенёс его и на каком основании. Для таких вопросов нужны история разработки, ранние экземпляры, материалы передачи и другие независимые сведения. Даже полное совпадение двух файлов устанавливает их идентичность, но не заменяет исследование происхождения.
Технические источники
Следующий шаг
Применить к вашей задаче
Опишите объект, спорный период и то, что сохранилось. Уточним, какие вопросы можно проверить. Доступы и архивы передаются после согласования.
Обсудить задачу ↗Услуги и разборы по теме
- Сравнение программ и исходного кода ↗
- Экспертиза исходного кода ↗
- Спор об объёме выполненных IT-работ ↗
Ещё по теме
- Журнал Git в споре о разработке: что показывает история и чего не доказывает ↗
- Что передать для исследования программы: комплект материалов без лишних данных ↗
- Приёмка доработки 1С: как проверить результат на понятных сценариях ↗
Материал описывает техническую подготовку и не заменяет индивидуальное исследование или правовую консультацию.