Судебная экспертиза исходного кода на JavaScript

Спорите с подрядчиком об интернет-магазине, личном кабинете или портале: в суде такой спор почти всегда сводится к соответствию сделанного техническому заданию — что заказали, что сдали и можно ли считать это принятым. У JavaScript ответ на этот вопрос имеет особенность, которой нет у других языков. Один и тот же язык работает в двух средах: в браузере посетителя и на сервере под управлением Node.js. Браузерная часть при этом публична — её код отдаётся каждому, кто открыл страницу, и снять копию можно, не дожидаясь суда. Серверная часть, наоборот, доступна только владельцу. Экспертиза исходного кода на JavaScript — специализированное направление экспертизы процесса разработки программного обеспечения. На выходе вы получаете заключение с описанием объектов, методов и ограничений, пригодное для суда и для переговоров.

Если спор уже начался, сохраните то, что исчезает первым. Браузерную часть зафиксируйте сегодня же: она меняется при каждом обновлении сайта, а прежние сборки сайт нигде не хранит. Как снять копию за четверть часа и чего она стоит в споре — ниже, в разделе «Что сохранить прямо сейчас». Не переписывайте историю изменений в репозитории — хранилище исходных текстов, где сохраняется каждая правка, — не удаляйте ветки и метки, не переустанавливайте пакеты на спорной площадке, там, где приложение развёрнуто.

Задачу разбираем бесплатно. Файлы для него присылать не нужно: достаточно описать ситуацию и перечислить, что у вас есть.

Какие споры разбираем

С такими спорами приходят, когда разногласия касаются того, что можно проверить, — состояния приложения и зафиксированного хода работ, а не только толкования договора. Определите заранее, о какой версии, площадке и периоде речь: без этого исследование теряет предмет.

Чаще всего это такие ситуации:

• подрядчик сдал интернет-магазин, личный кабинет или портал на React, Vue или Angular, а вы считаете, что заявленное техническим заданием не выполнено;
• стороны спорят, какие требования реализованы, какие сделаны иначе, а какие не работают в описанных условиях;
• интерфейс ломается в конкретном браузере или на мобильном устройстве, и это приводят как довод о несоответствии;
• в корзине, счёте или отчёте расходятся суммы — копейки на позицию, заметные деньги на обороте;
• серверная часть на Node.js падает под нагрузкой или теряет данные при обмене с платёжной, учётной или партнёрской системой;
• фоновые задачи не отработали: письма не ушли, заказы не выгрузились, статусы разошлись;
• подрядчик ушёл, а переданный комплект не собирается или неполон;
• нужно проверить, не использован ли чужой код и на каких условиях подключены пакеты из открытых хранилищ.

Если ваш вопрос звучит иначе, точнее начать с соседнего исследования: о качестве кода — экспертиза качества исходного кода, о заимствовании — сравнение исходного кода, о деньгах и объёме — экспертиза объёма и стоимости выполненных работ. Если спорная система написана на другом языке, смотрите экспертизу кода на Java или на Python.

Не знаете, на каком языке написана ваша система? Выяснить несложно: язык обычно назван в техническом задании или в актах, его знает подрядчик, а если спор о сайте — браузерная часть почти наверняка на JavaScript, даже когда серверная написана на другом языке. Если ясности нет, позвоните: направление определим сами и без оплаты, по адресу сайта и описанию спора.

Чем это отличается от экспертизы сайта

Разница в объекте, и от неё зависит, какие вопросы вообще можно поставить. Экспертиза сайта смотрит на ресурс как на целое: доступность, содержимое страниц, факт публикации, работоспособность для посетителя. Здесь объект другой — исходный код и работы по его созданию: что написано, что из этого попало в поставку, соответствует ли оно заданию, чем объясняется ошибка.

Выбирать так. Если нужно зафиксировать, что было опубликовано на сайте в конкретный день, вам к экспертизе веб-сайтов. Если спор с подрядчиком о том, сделана ли работа и почему приложение считает неверно, — сюда. Задачи нередко идут вместе, и тогда их объединяют в одном исследовании.

От аудита кода отличие другое: аудит смотрит вперёд и предлагает, что переделать, а экспертиза обращена назад — она устанавливает проверяемые факты о зафиксированном состоянии приложения так, чтобы другой специалист мог повторить проверку и прийти к тем же наблюдениям.

Две среды исполнения — и два разных объекта

Это и есть главное отличие. Браузерная и серверная части живут по разным правилам, и материалы для них собирают по-разному.

Разница проявляется в трёх вещах:

• Доступность кода. Браузерную часть отдаёт сам сайт: её можно сохранить в любой момент вместе с адресом, датой и контрольной суммой. Серверную часть на Node.js без содействия владельца или без решения суда получить нельзя.
• Воспроизводимость. Серверное приложение поднимается на стенде и ведёт себя предсказуемо. Браузерное зависит от устройства, версии браузера, расширений и настроек посетителя, поэтому «не работает» проверяют в названных условиях и эти условия фиксируют.
• Следы. На сервере есть журналы. В браузере их нет вовсе, если специально не подключена служба сбора ошибок вроде Sentry, — поэтому по клиентской части выводы чаще опираются на сам код и на воспроизведение, а не на записи о произошедшем.

Поэтому браузерную часть спорной версии сохраните сразу, не дожидаясь назначения экспертизы. Через неделю на сайте будет другая сборка, и доказывать придётся уже по чужим копиям. Как снять такую копию и что сделать, чтобы она весила в споре больше, описано ниже.

Сборка, минификация и карты исходного кода

Ещё одна особенность JavaScript: в браузер почти никогда не попадает то, что писал разработчик. Исходные тексты проходят через сборщик — Webpack, Vite, esbuild или подобный, — который склеивает модули, переименовывает переменные и удаляет пробелы и переносы строк — это и называют минификацией, — чтобы файл грузился быстрее. Результат называют бандлом: он работает так же, но читается плохо.

Часть проектов пишут на TypeScript — надстройке над JavaScript с проверкой типов, — и тогда в поставку уходит результат его компиляции, а не исходный текст. Для спора это важно: сравнивать переданное с опубликованным нужно с учётом того, что между ними стоит сборка.

Выручают карты исходного кода — служебные файлы, которые сборщик выпускает рядом с бандлом и которые сопоставляют его строки с исходными. Здесь важна одна оговорка: сам текст исходников карта возвращает только тогда, когда несёт его копию внутри себя. Сборщики умеют выпускать карту и без такого включения — тогда в ней остаются сопоставление позиций, исходные имена и ссылки на файлы, которые обычно нигде не опубликованы. В первом случае восстанавливается почти полный текст, вплоть до комментариев; во втором — имена, границы модулей и структура каталогов, но не текст. Что именно представлено, проверяют и указывают, а не предполагают.

Искать карту нужно в двух местах: рядом со сборкой, отдельным файлом, и внутри самого файла сборки — карту умеют встраивать прямо в его последнюю строку, и тогда по соседним адресам её не найти. Принимать карту на веру тоже нельзя: это утверждение сборки о самой себе — отдельный файл, который изготавливается и правится независимо от неё. Поэтому представленную карту сверяют с представленной сборкой обратным отображением и сверкой объявленных имён файлов, а для обоих файлов фиксируют адрес, дату получения и контрольные суммы. Отдельно отличают сжатие от запутывания. Минификация делает файл компактным и обратима настолько, насколько позволяет карта; обфускация — намеренное запутывание, когда строки шифруются, поток управления искусственно усложняется, а имена заменяются на бессмысленные. Она законна, но резко сужает круг вопросов, на которые можно ответить, и факт её применения фиксируют как обстоятельство, влияющее на определённость выводов. Если карты нет вовсе, остаётся разбор бандла: состав модулей, подключённые библиотеки, логика работы — этого достаточно для сравнения и для многих вопросов о функциях, но не для выводов об оформлении кода. Наличие, вид и происхождение карты фиксируют отдельно: это техническое обстоятельство, влияющее на определённость ответа.

Что может установить эксперт

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

При достаточных материалах вы получите ответ о следующем:

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

Есть и то, чего ждать не стоит. «Сайт работает медленно» или «интерфейс сломан» — не технические утверждения, пока не названы измеримый критерий и условия: какая операция, в каком браузере, на каком устройстве и по какому пункту требований. Поведение у посетителя зависит от его окружения, и эксперт отвечает за то, что воспроизвёл сам, а не за то, что кто-то видел на своём экране. Отсутствие записи в журнале не означает, что события не было: сначала выясняют, что именно система записывала, а у браузерной части журналов обычно нет вовсе.

Техническое не переходит в правовое автоматически. Имя и адрес почты в записи истории разработчик указывает сам и настраивает произвольно, дату записи тоже можно задать вручную, поэтому такие сведения сужают круг объяснений, но не отождествляют изменение с конкретным человеком. Обнаруженный дефект — технический факт, а не вывод о вине исполнителя; совпадение фрагментов кода — не вывод о нарушении авторских прав. Правовую оценку обстоятельствам дела, ответственность сторон и доказательственное значение заключения определяет суд или другой уполномоченный орган.

Как проверяют соответствие техническому заданию

Работа начинается с документов, а не с кода. Техническое задание, макеты и описания экранов, требования к браузерам и устройствам, спецификации обмена переводят в перечень проверяемых признаков: для каждого требования определяют, что считать его выполнением и как это наблюдать. Требования, описанные общими словами, отмечают отдельно — по ним критерия нет, и эксперт скажет об этом прямо, а не додумает его за стороны.

Дальше каждое требование проверяют на конкретной версии и в названных условиях, а результат раскладывают на четыре исхода:

• Не реализовано — ни в исходных текстах, ни в опубликованной сборке нет кода, который выполнял бы это требование. Такой вывод делают только после того, как доказана полнота исследованного объекта, а полнота браузерной копии её не обеспечивает. Сборщик делит приложение на части, подгружаемые по мере надобности, поэтому по стартовой странице судить обо всём нельзя; к тому же у каркасов вроде Next.js и Nuxt часть кода исполняется на сервере и в браузер не отдаётся никогда, а требование может быть реализовано в серверной части на Node.js, которой у вас нет. Пока эти области не проверены, вывод звучит иначе — четвёртым исходом.
• Реализовано иначе — механизм есть, но работает не так: другой сценарий, другой состав полей, другое поведение при ошибке.
• Реализовано, но не работает в описанных условиях — для браузерной части это самый частый исход: функция работает в одном браузере и отказывает в другом, на телефоне или при медленной сети, и тогда важно, оговаривались ли эти условия в задании.
• Проверить на представленных объектах невозможно — критерий есть, а объекта нет: не передана серверная часть, не сохранена сборка спорного периода, утрачены журналы за нужные даты. Это самостоятельный исход, а не разновидность первого: отсутствие материала не равно отсутствию кода, и эксперт называет, чего именно не хватило для ответа.

Отдельно восстанавливают, как менялся объём работ: дополнительные соглашения, переписка, задачи в системе учёта и правки макетов показывают, о чём стороны договаривались по ходу проекта. Эксперт фиксирует это как техническое обстоятельство, а вопрос о юридической силе таких изменений разрешает суд. Если спорят о сайте целиком, а не работы по его созданию, задачу решают на стороне экспертизы сайта на соответствие техническому заданию.

Если передан только собранный бандл

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

Порядок такой. Сначала проверяют, опубликованы ли карты исходного кода: их часто оставляют по недосмотру, и тогда — если карта несёт в себе копию исходников — восстанавливается почти полный текст. Если карт нет, бандл разбирают: определяют состав модулей, применённые каркасы и библиотеки с версиями, отдельные функции и обработчики, строковые константы и адреса, к которым обращается приложение. Этого достаточно, чтобы описать реализованные возможности, сравнить с другой кодовой базой и во многих случаях объяснить наблюдаемую ошибку.

Пределы такие же, как и в других языках: восстановленный из бандла текст — реконструкция, а не исходный код автора, и имена переменных после переименования без карты не возвращаются. С комментариями тоньше: обычные при сжатии удаляются, а сохраняются по умолчанию только помеченные как юридические — лицензионные блоки и уведомления со специальной пометкой, — в самом файле или в отдельном файле рядом. Обычный комментарий с указанием автора такой пометки не имеет и из сборки исчезает, поэтому его отсутствие в бандле ничего не говорит о том, был ли он в исходных текстах. Всё это указывают в заключении.

Отдельно проверяют полноту двух разных комплектов. Переданный комплект исходных текстов достаточен, когда по нему удаётся собрать и запустить приложение без обращения к подрядчику. Сохранённая сборка полна тогда, когда собраны и подгружаемые части: стартовая страница тянет лишь долю кода, остальное приходит при переходе в раздел или открытии формы. Поэтому браузерную часть сохраняют, пройдя спорные сценарии, а не открыв главную.

Если недостающие материалы у другой стороны, получить их можно через суд или орган, назначивший экспертизу; по ходатайству стороны суд решает и вопрос о принятии мер к обеспечению доказательств. До назначения экспертизы мы поможем описать, что именно просить: конкретный репозиторий, ветку, версию сборки, файл блокировки версий, выгрузку настроек и период журналов.

Какие объекты исследуются

Набор подбирают под вопрос. Для сравнения двух приложений хватит исходных текстов, для спора о поставке нужна ещё и опубликованная сборка, а для разбора ошибки — журналы и условия, в которых она возникла.

Код, сборка и опубликованное приложение

Эти материалы собирают вместе: по отдельности они отвечают на меньшее число вопросов, а сопоставление исходных текстов с тем, что отдаётся посетителю, и есть основная проверка.

В группу входят:

• полная зеркальная копия каждого репозитория со всеми ветками, метками и историей изменений;
• исходные тексты на JavaScript или TypeScript, файлы сборщика и настройки компиляции;
• описание зависимостей package.json и файл блокировки версий — package-lock.json, yarn.lock или pnpm-lock.yaml, — закрепляющий точный набор установленных пакетов;
• сохранённая браузерная сборка спорного периода вместе с картами исходного кода, если они публиковались;
• версия Node.js, образы контейнеров, установочные комплекты и их контрольные суммы.

Настройки, данные и следы работы

Вторая группа объясняет, почему одна и та же версия ведёт себя по-разному, и что происходило с данными.

В неё входят:

• файлы настроек и переменные окружения каждой площадки, описания развёртывания;
• настройка протоколирования: что система записывала в спорный период, а что не записывала вовсе;
• схема базы данных и сценарии её изменения, а также резервные копии на нужные даты;
• журналы сервера, записи об ошибках со стеком вызовов, сведения о фоновых задачах и очередях;
• данные службы сбора клиентских ошибок, если она подключена, и записи веб-аналитики;
• входные данные спорного расчёта, полученный результат и документ, задающий эталон;
• отчёты тестов и анализаторов, результаты проверок доступности и производительности.

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

Что сохранить прямо сейчас

Часть материалов исчезает сама: сайт обновляется, журналы ротируются, задачи в очередях вычищаются. Сроки везде свои — проверьте настройки, прежде чем рассчитывать на данные недельной давности. Но чаще всё упирается не в сроки хранения: мешает положение сторон: хостинг, домен, панель управления и репозиторий нередко оформлены на подрядчика, и после начала спора он может выложить исправленную версию, выключить сайт или переписать историю изменений. Поэтому порядок такой: сначала своими силами фиксируют то, до чего вы дотягиваетесь без чужого согласия, а об остальном просят суд, не откладывая.

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

Порядок такой:

• откройте спорные страницы и пройдите спорные сценарии — каталог, корзину, шаги оформления заказа до подтверждения, свой личный кабинет: подгружаемые части кода приходят именно по ходу этих переходов, и без них копия будет неполной. Настоящий заказ при этом не оформляйте: это запись в спорной системе;
• сохраните каждую страницу целиком средствами браузера, а файлы сборки и карты исходного кода — по их собственным адресам, отдельными файлами;
• для каждого файла запишите адрес, дату и время с часовым поясом и посчитайте контрольную сумму — короткую строку, которая пересчитывается из содержимого файла и меняется при любой его правке, поэтому подтверждает, что копия с того дня не изменилась. Считать её умеет сам компьютер: в Windows — команда Get-FileHash в приложении PowerShell, на macOS и Linux — shasum -a 256 в терминале; результат сохраните рядом с файлом в обычном текстовом документе;
• сложите всё в один архив и больше не открывайте его на редактирование.

Сразу о том, чего такая копия стоит. Снятая своими силами, она доказывает меньше, чем кажется: происхождение подтверждается только вашими словами, и вторая сторона заявит, что файлы могли быть изменены. Это не повод её не делать — копия, снятая сегодня, всё равно лучше отсутствующей, и она задаёт то состояние, с которым потом сверяются. Но если спорная сборка — ключевой довод, фиксировать лучше не самому: её выполняет эксперт с описанием порядка, времени и условий получения — это фиксация содержимого интернет-страниц. Нотариальное обеспечение доказательств тоже возможно, но у него есть жёсткое ограничение: по делу, уже находящемуся в производстве суда, нотариус доказательства не обеспечивает, и рассчитывать на этот путь после подачи иска не стоит. Браузерную часть мы можем зафиксировать за вас — до назначения судебной экспертизы и по вашему поручению; после назначения объекты идут только через назначивший орган.

Остальное требует доступа и полномочий, а часть действий сама меняет спорную систему:

• снимите образ или полную копию серверной площадки вместе со списком установленных пакетов — но только имея на это полномочия и согласованный план: копирование, остановка и перезапуск работающей системы сами меняют часть наблюдаемых данных;
• выгрузите журналы сервера, сведения о фоновых задачах и данные службы сбора ошибок за исследуемый период — с реплики или из готовой копии и в согласованное окно, а не с нагруженного контура в час пик;
• сохраните резервные копии базы на нужные даты: без состояния «до» объём утраты обычно установить нельзя;
• сохраните входные данные и полученный результат, о которых идёт спор, вместе с датой и версией приложения;
• сделайте полную зеркальную копию каждого репозитория, а не выгрузку рабочего каталога;
• запишите, кто, когда и от кого получал материалы и что с ними делали.

Копируйте и передавайте только то, что принадлежит вам или к чему у вас есть законное право доступа: чужие системы исследуют по решению суда или другого уполномоченного органа, и назначенный судом эксперт материалы самостоятельно не собирает. И чего делать не нужно: не выкладывайте исправленную версию на спорный адрес до того, как зафиксирована прежняя; не переписывайте историю — принудительная перезапись ветки, перебазирование и удаление веток или меток уничтожают следы; не переустанавливайте пакеты на спорной площадке, пока не снят снимок.

Как передать материалы и не раскрыть лишнего

Для первого обращения файлы не нужны совсем. Когда дойдёт до передачи, порядок согласуют заранее: зашифрованный архив, пароль отдельным каналом, ограниченный круг допущенных лиц, срок хранения и подтверждаемое удаление после работ. Если экспертиза назначена судом, объекты поступают и возвращаются через назначивший орган, и их дальнейшую судьбу определяет он.

К передаче подготовьте:

• цель исследования, проект вопросов, точный период и часовой пояс;
• исходные тексты или зеркальные копии репозиториев, а если их нет — сохранённую браузерную сборку и сведения о том, откуда и когда она получена;
• описание зависимостей и файл блокировки версий, версию Node.js;
• договор, техническое задание, макеты, требования к браузерам, акты и переписку о согласованных изменениях;
• настройки площадок, схему базы, сценарии её изменения и резервные копии;
• журналы сервера, сведения о задачах и данные службы сбора ошибок за период;
• входные данные и результаты спорного расчёта;
• процессуальный документ, если экспертиза уже назначена.

Почти в каждой группе есть то, что защищают отдельно. Ключи к платёжным и почтовым сервисам в проектах на JavaScript нередко лежат в файлах настроек рядом с кодом, а иногда по недосмотру попадают и в браузерную сборку, где их видит любой посетитель: замените значения перед передачей, а настоящие ключи перевыпустите — но в согласованное окно и в правильном порядке: сначала зафиксируйте спорную конфигурацию, затем выпустите новый ключ, переведите на него площадки и только потом отзовите старый. Отзыв сгоряча сам становится инцидентом: магазин перестаёт принимать оплату, а спорная конфигурация меняется до того, как её успели зафиксировать. Вычищать секреты из истории репозитория не нужно и вредно — перевыпуск решает задачу, а правка истории уничтожает следы. В журналах оказываются ключи в адресах запросов, заголовки авторизации и пароли в текстах ошибок: такие поля при выгрузке усекают или заменяют. Резервные копии базы, выгрузки заказов и данные веб-аналитики содержат персональные данные ваших покупателей. Ответственность оператора перед ними остаётся на вас и после передачи, поэтому у передачи должно быть основание, а обработка на нашей стороне оформляется поручением с определённой целью, сроком и порядком уничтожения. Состав и период ограничивают тем, что нужно для ответа; выгрузки обезличивают всегда, а не по выбору, и выполняют его на копии, согласовав с нами, чтобы не удалить признак, от которого зависит вывод. Учтите, что по адресу доставки, телефону и составу корзины человека узнают и после замены имени и после замены имени, а реквизиты платёжных карт не передают ни в каком виде и ни в каком объёме.

Действующие пароли, ключи и токены не передавайте вообще. Если для внесудебного исследования по договору нужен доступ к работающей системе, его открывают отдельной именной учётной записью только на чтение, с ограниченным сроком и с протоколированием, а по окончании работ отключают. При назначенной судом экспертизе так делать нельзя: доступ и любые дополнительные материалы идут через назначивший орган.

Как проводится исследование

Мы начинаем с фиксации: описываем полученные объекты, считаем контрольные суммы, проверяем целостность и полноту, отмечаем, чего не хватает. Всякий раз, когда текст получен не от стороны, а восстановлен из сборки, в заключении называют средство и его версию, которыми выполнено восстановление, — иначе результат невозможно перепроверить. Для браузерной части отдельно фиксируем, по каким адресам и когда снята сборка. Затем восстанавливаем окружение — разворачиваем стенд с той же версией Node.js и теми же версиями пакетов — и проверяем, воспроизводится ли спорное поведение.

Дальше метод зависит от задачи. Проверка требований задания описана выше. Для ошибок интерфейса воспроизводят сценарий в названных браузерах и на названных устройствах, фиксируя версии и условия, и отделяют дефект кода от особенностей среды посетителя. Для отказов серверной части восстанавливают временную шкалу по журналам и записям об ошибках, сверяя часовые пояса разных систем, и проверяют альтернативные объяснения: код, настройки, объём данных, смежная система, версия пакета. Если воспроизвести условия не удалось, это не опровергает версию: мы указываем, чего для проверки не хватило.

Сопоставление опубликованной сборки с исходными текстами — отдельная процедура. Проект собирают заново на зафиксированных версиях и сравнивают результат с тем, что отдаёт сайт. Современные сборщики в рабочем режиме дают повторимый результат: на тех же версиях инструментов и пакетов повторная сборка часто даёт побайтово тот же файл, и это сильный результат — его добиваются и фиксируют. Но гарантии нет: другая версия сборщика, иная настройка или служебная вставка меняют байты, не меняя поведения. Поэтому одно расхождение байтов ничего не доказывает — сравнивают ещё и состав модулей с логикой, а содержательное расхождение, которое не объясняется инструментами, становится сильным фактом; совпадение же подтверждает совместимость, но не доказывает, что сборка изготовлена именно из этих текстов.

Сравнение кодовых баз ведут в несколько проходов. Сначала исключают то, что само по себе о заимствовании не говорит: пакеты из открытых хранилищ, файлы, созданные инструментами каркаса, обязательные конструкции компонентов и маршрутов, а также результат автоформатирования. Затем сопоставляют программы по последовательностям лексем — элементарных единиц текста программы — и по структуре, устойчиво к переименованиям; при работе с бандлами сравнивают приведённые к единому виду модули. Каждое значимое совпадение проверяют вручную и объясняют, а чтобы показать фоновый уровень схожести, в сравнение включают независимые проекты того же назначения.

Примеры вопросов на экспертизу

При судебной экспертизе окончательный круг вопросов определяет суд, а в иных предусмотренных законом процедурах — орган или лицо, назначившие экспертизу. Эксперт отвечает на поставленные вопросы в пределах специальных знаний и представленных материалов и не изменяет их по своей инициативе; при неясности вопроса, выходе за пределы компетенции или недостаточности материалов он сообщает об этом назначившему органу в установленном порядке.

До назначения экспертизы вы вправе предложить свои формулировки. Назовите объект точно: репозиторий и ветку либо конкретную запись истории, версию приложения, адрес и дату снятия браузерной сборки, площадку, период и часовой пояс, а для ошибки интерфейса — браузер, устройство и сценарий. Разные задачи разводите по отдельным вопросам. Ниже — примеры технических формулировок:

1. Каковы состав и структура представленного приложения: модули, использованные каркасы и библиотеки с версиями, точки обмена с другими системами?
2. Реализовано ли в представленной версии приложения требование, описанное в указанном пункте технического задания, и в каком объёме?
3. Достаточен ли переданный комплект исходных текстов, настроек и документации для самостоятельной сборки и запуска приложения, и чего в нём не хватает?
4. Соответствует ли представленная браузерная сборка, снятая по указанному адресу и в указанную дату, представленным исходным текстам, и какие расхождения обнаруживаются?
5. Имеются ли в представленных материалах карты исходного кода, соответствуют ли они представленной сборке и в каком объёме позволяют восстановить её исходные тексты?
6. Каков результат обработки представленных исходных данных представленной версией приложения и соответствует ли он результату, зафиксированному в представленном документе?
7. Воспроизводится ли описанная ошибка в представленной версии приложения при указанном сценарии, в указанном браузере и на указанном устройстве?
8. Какие технические причины отказа серверной части в указанный период подтверждаются представленными журналами и записями об ошибках?
9. Отражено ли в представленных источниках прохождение указанных заказов между системами и на каком этапе их обработка прекратилась?
10. Имеются ли в исходных текстах двух представленных приложений совпадающие фрагменты, каковы их объём и характер после исключения сторонних пакетов и сгенерированного кода?

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

Граница компетенции проходит по нескольким линиям. Эксперт устанавливает техническую причину ошибки, но не решает, кто отвечает за убытки и надлежаще ли исполнен договор. Эксперт описывает, какие фрагменты кода совпадают, а вывод о нарушении исключительных прав делает суд. Эксперт может показать, что операция выполнена от определённой учётной записи и с определённой отметкой времени, однако учётная запись и настраиваемые вручную отметки не устанавливают, кто именно действовал. Если готовое заключение оказалось неясным, суд может допросить эксперта; недостаточная полнота и новые вопросы могут стать основанием для дополнительной экспертизы, а противоречия и сомнения в обоснованности — для повторной. Основания и порядок различаются по видам судопроизводства.

Форматы работы и результат

Заключение по коду на JavaScript отличается от прочих описанием объекта: одного названия репозитория мало. Указывают адрес, дату и время снятия каждой браузерной сборки, её контрольную сумму, наличие и вид карт исходного кода, версии сборщика и Node.js, а для ошибки интерфейса — браузер, устройство и сценарий, в которых велась проверка. Дальше как обычно: методы, выполненные действия, полученные данные, проверенные альтернативные объяснения, ограничения и ответы на вопросы, а таблицы сравнения и снимки экранов приводятся так, чтобы проверку можно было повторить. Заранее установленной силы у документа нет — суд оценивает заключение наравне с другими доказательствами.

Формат выбирают по стадии спора:

• Консультация или справка — письменный ответ эксперта по существу вашего вопроса, и это уже платная работа, в отличие от предварительного разбора: что по имеющимся материалам установить можно, а что нет; каких источников не хватает и где их искать; какой определённости вывода стоит ждать.
• Внесудебное исследование проводится по договору со стороной по согласованным техническим вопросам.
• Судебная экспертиза выполняется по определению суда либо постановлению следователя, дознавателя или иного уполномоченного законом лица.
• Рецензия проверяет уже готовое заключение — объекты, методы, ограничения и связь результатов с выводами; подробнее на странице рецензирования экспертизы разработки ПО.

Если судебная экспертиза уже назначена, порядок общения меняется. Назначенный эксперт не принимает от одной стороны дополнительные выгрузки и журналы и не даёт ей частную оценку по существу поручения: вопросы, доступ и новые материалы передаются через суд или орган расследования. Помощь с формулировками вопросов возможна только до назначения. Если специалист раньше работал для одной из сторон, это раскрывают при рассмотрении его кандидатуры, а решение о назначении и об отводе принимает суд или другой назначивший орган.

От чего зависят стоимость и срок

Решают три вещи, и все три специфичны для JavaScript. Первая — сколько сред исполнения входит в спор: одна браузерная часть считается иначе, чем связка «браузер плюс Node.js», где к каждому выводу нужно сопоставление двух сторон. Вторая — в каком виде дошёл код: исходные тексты с картами исходного кода разбираются быстро, голый бандл без карт превращает чтение кода в отдельную работу, а запутанная сборка увеличивает её на порядок. Третья — сколько условий придётся воспроизводить: каждый названный в задании браузер, каждое устройство и каждый сценарий проверяются отдельно, и десять браузеров стоят дороже одного. Дальше обычное: зафиксированы ли версии пакетов, уцелели ли журналы за спорный период, сколько вопросов поставлено и нужны ли смежные специалисты. Ориентир для судебной экспертизы — от 100 000 ₽, ориентировочный срок — 10 рабочих дней; точные условия определяются после просмотра материалов.

При первом обращении файлы присылать не нужно. Опишите спор, наметьте вопросы и перечислите, что у вас есть. Позвоните по номеру 8 (800) 333-24-09 или оставьте заявку — мы проверим, относится ли задача к нашей компетенции, предложим безопасный порядок передачи материалов и скажем, каких данных не хватает для расчёта.