Модернизация старого Perl-кода — бесплатный тест онлайн

Вопрос 1 из 30

Какой прогноз для кода с `$count` выдержит пошаговую проверку?

use strict; use warnings;
my $count=0;

Strict требует объявлять имена и символические ссылки, warnings подсвечивает подозрительные преобразования и undef. Единственное существенное правило этого запуска — следующая оговорка: use warnings FATAL=>'all' полезен в тестах, но в старом производственном коде может превратить ранее терпимые случаи в аварии без плана миграции. Дополнительное изменение не требуется, поскольку код уже обеспечивает следующее: Причина обрабатывается в месте, где отсутствие поля имеет прикладной смысл. Непосредственным итогом выполнения будет: Глобальное отключение предупреждения скрывает реальные ошибки данных во всём блоке. Strict требует объявлять имена и символические ссылки, warnings подсвечивает подозрительные преобразования и defined.

Вопрос 2 из 30

Какое утверждение точно описывает поведение фрагмента «Характеризующие тесты» с `$before`, `$fixture` и `$expected`?

my $before=run_legacy($fixture);
is_deeply normalize($before),$expected,'invoice behavior';

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

Вопрос 3 из 30

Как ведёт себя участок «Декомпозиция» при выполнении?

sub process { parse(); validate(); enrich(); save(); notify(); }

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

Вопрос 4 из 30

Что непосредственно следует из показанного кода с `%CONFIG`, `$DBH` и `$CURRENT_USER`?

our %CONFIG; our $DBH; our $CURRENT_USER;

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

Вопрос 5 из 30

Какую скрытую зависимость создают позиции `$row->[7]` и `$row->[12]`?

my $amount=$row->[7]; my $date=$row->[12];

Позиции привязаны к типам значений, поэтому перестановка колонок не меняет смысл данных. При сдвиге колонок Perl автоматически обновляет индексы по первой строке файла. Магические позиции не проверяют схему и могут незаметно присвоить полям значения из других колонок. Проблема проявится только как предупреждение, а значения `$amount` и `$date` останутся верными. Индексы проверяют заголовки колонок при каждом обращении и завершают разбор при несовпадении.

Вопрос 6 из 30

Как завершится этот код по правилам Perl 5.40?

my $json=JSON::MaybeXS->new(canonical=>1);
print $json->encode($result);

Текущее поведение совпадает с результатом предлагаемой правки: Порядок, локаль, часовой пояс, версии и случайность фиксируются как часть воспроизводимого запуска. В показанном коде «Воспроизводимость результата» проявляется другой эффект: порядок хеша не гарантирован, поэтому одинаковый расчёт даёт разный текстовый результат. Канонический порядок ключей делает сериализованный результат стабильнее для сравнения. Итог этого фрагмента полностью задаёт следующая оговорка: Точный байтовый повтор не всегда нужен, но семантические различия должны быть отделены от шума представления. Этот код приведёт к иному эффекту: Порядок хеша не гарантирован, поэтому одинаковый расчёт даёт разный текстовый результат.

Вопрос 7 из 30

Какой диагноз точнее всего относится к участку с ключевыми операциями?

no warnings 'uninitialized';

Глобальное отключение предупреждения скрывает реальные ошибки данных во всём блоке. Нежелательное поведение вводит предлагаемое решение: Причина обрабатывается в месте, где отсутствие поля имеет прикладной смысл. Показанный код уже соблюдает правило «strict и warnings вводят поэтапно вместе с тестами; предупреждения исправляют по причине, а не подавляют ковром», поэтому отдельного дефекта нет. Главный риск этого участка задаёт другое ограничение механизма: use warnings FATAL=>'all' полезен в тестах, но в старом производственном коде может превратить ранее терпимые случаи в аварии без плана миграции. Причина сбоя совпадает с обычным результатом примера: strict требует объявлять имена и символические ссылки, warnings подсвечивает подозрительные преобразования и undef.

Вопрос 8 из 30

Какой риск связан именно с операциями `rewrite_all` и `then_add_tests`?

rewrite_all(); then_add_tests();

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

Вопрос 9 из 30

Почему участок с ключевыми операциями ненадёжен на пограничном входе?

sub process { goto &legacy_process }

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

Вопрос 10 из 30

Какой отказ объясняется показанным кодом, а не внешней системой?

local %CONFIG=%test;

Источником дефекта становится само изменение: Зависимости становятся состоянием конкретного объекта и передаются при создании. Local временно меняет пакетную переменную, но не устраняет скрытую зависимость и усложняет параллельные тесты. Риск возникает уже в обычном результате: Пакетные глобальные значения связывают запросы и тесты, а в долгоживущем процессе могут протекать между операциями. Показанный код уже соблюдает правило «Глобальное состояние заменяют объектом контекста, параметрами или явным сервисом, начиная с границы, которую можно покрыть тестом», поэтому отдельного дефекта нет. Дефект следует искать в другой оговорке: Неизменяемую конфигурацию можно разделять, но текущий пользователь, транзакция и временные результаты должны быть локальны операции.

Вопрос 11 из 30

Что в этом коде нарушает ожидаемое поведение?

my %r; @r{@headers}=@fields;

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

Вопрос 12 из 30

Что нужно заметить при ревью фрагмента «Воспроизводимость результата»?

my %seen = map { $_ => 1 } qw(alpha beta gamma);
print join ',', keys %seen;

Показанный код уже соблюдает правило «Воспроизводимость требует одинакового входа, кода, зависимостей, конфигурации, времени/часового пояса и детерминированного порядка», поэтому отдельного дефекта нет. Проблема возникает в исправленном варианте: Порядок, локаль, часовой пояс, версии и случайность фиксируются как часть воспроизводимого запуска. Причину отказа точнее описывает соседняя граница темы: Точный байтовый повтор не всегда нужен, но семантические различия должны быть отделены от шума представления. Риск возникает уже в обычном результате: Канонический порядок ключей делает сериализованный результат стабильнее для сравнения. Порядок хеша не гарантирован, поэтому одинаковый расчёт даёт разный текстовый результат.

Вопрос 13 из 30

Почему новая версия с `$value` и `$row` устраняет исходный дефект?

my $value=$row->{x};
die 'missing x' unless defined $value;

Гарантию исправления даёт исчезновение ограничения: use warnings FATAL=>'all' полезен в тестах, но в старом производственном коде может превратить ранее терпимые случаи в аварии без плана миграции. Причина обрабатывается в месте, где отсутствие поля имеет прикладной смысл. Правка лишь воспроизводит исходное поведение: strict требует объявлять имена и символические ссылки, warnings подсвечивает подозрительные преобразования и undef. Изменение формы записи само по себе обеспечивает правило «strict и warnings вводят поэтапно вместе с тестами; предупреждения исправляют по причине, а не подавляют ковром». После изменения сохраняется прежний дефект: Глобальное отключение предупреждения скрывает реальные ошибки данных во всём блоке.

Вопрос 14 из 30

Какую гарантию добавляет правка «Характеризующие тесты» с `capture_inputs_outputs_side_effects`, `change_one_seam` и `compare_results`?

capture_inputs_outputs_side_effects();
change_one_seam();
compare_results();

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

Вопрос 15 из 30

Какой вывод точнее всего объясняет пользу правки «Декомпозиция»?

sub process { my($deps,$input)=@_; my $v=parse($input); validate($v); return save($deps->{db},$v) }

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

Вопрос 16 из 30

Что именно стало надёжнее после изменения в блоке «Замена глобального состояния»?

sub new { bless {config=>$cfg,db=>$dbh},shift }

Зависимости становятся состоянием конкретного объекта и передаются при создании. Изменение формы записи само по себе обеспечивает правило «Глобальное состояние заменяют объектом контекста, параметрами или явным сервисом, начиная с границы, которую можно покрыть тестом». Правка лишь воспроизводит исходное поведение: Пакетные глобальные значения связывают запросы и тесты, а в долгоживущем процессе могут протекать между операциями. Правка решает задачу тем, что устраняет следующую границу: Неизменяемую конфигурацию можно разделять, но текущий пользователь, транзакция и временные результаты должны быть локальны операции. После изменения сохраняется прежний дефект: local временно меняет пакетную переменную, но не устраняет скрытую зависимость и усложняет параллельные тесты.

Вопрос 17 из 30

Как правка с `$record`, `$line` и `parse_row` меняет поведение на неудобном входе?

my $record=parse_row($line); validate_record($record);

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

Вопрос 18 из 30

Что отличает это исправление от маскировки симптома?

sort_records(); set_locale('C'); freeze_versions();

После правки перестаёт проявляться предел механизма: Точный байтовый повтор не всегда нужен, но семантические различия должны быть отделены от шума представления. Изменение формы записи само по себе обеспечивает правило «Воспроизводимость требует одинакового входа, кода, зависимостей, конфигурации, времени/часового пояса и детерминированного порядка». После изменения сохраняется прежний дефект: Порядок хеша не гарантирован, поэтому одинаковый расчёт даёт разный текстовый результат. Правка лишь воспроизводит исходное поведение: Канонический порядок ключей делает сериализованный результат стабильнее для сравнения. Порядок, локаль, часовой пояс, версии и случайность фиксируются как часть воспроизводимого запуска.

Вопрос 19 из 30

На что следует опираться при ревью кода по теме «Режимы strict и warnings»?

Strict и warnings вводят поэтапно вместе с тестами; предупреждения исправляют по причине, а не подавляют ковром. Общее правило темы «Режимы strict и warnings» сводится к частному результату: strict требует объявлять имена и символические ссылки, warnings подсвечивает подозрительные преобразования и undef. Для ревью достаточно исключить частный дефект: Глобальное отключение предупреждения скрывает реальные ошибки данных во всём блоке. Правило «strict и warnings вводят поэтапно вместе с тестами; предупреждения исправляют по причине, а не подавляют ковром» гарантирует, что ограничение «use warnings FATAL=>'all' полезен в тестах, но в старом производственном коде может превратить ранее терпимые случаи в аварии без плана миграции» больше не проявится. Один приём полностью закрывает тему: Причина обрабатывается в месте, где отсутствие поля имеет прикладной смысл.

Вопрос 20 из 30

Какой принцип объясняет три кодовых примера блока «Характеризующие тесты»?

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

Вопрос 21 из 30

Какую закономерность проверяют задания темы «Декомпозиция»?

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

Вопрос 22 из 30

Какой принцип объясняет три кодовых примера блока «Замена глобального состояния»?

Глобальное состояние заменяют объектом контекста, параметрами или явным сервисом, начиная с границы, которую можно покрыть тестом. Достаточно применить следующее исправление: Зависимости становятся состоянием конкретного объекта и передаются при создании. Общее правило темы можно свести к предотвращению одного сбоя: local временно меняет пакетную переменную, но не устраняет скрытую зависимость и усложняет параллельные тесты. Правило «Глобальное состояние заменяют объектом контекста, параметрами или явным сервисом, начиная с границы, которую можно покрыть тестом» гарантирует, что ограничение «Неизменяемую конфигурацию можно разделять, но текущий пользователь, транзакция и временные результаты должны быть локальны операции» больше не проявится. Общее правило темы «Замена глобального состояния» сводится к частному результату: Пакетные глобальные значения связывают запросы и тесты, а в долгоживущем процессе могут протекать между операциями.

Вопрос 23 из 30

Какой общий принцип темы «Качество данных» переносится на другие программы?

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

Вопрос 24 из 30

Какую закономерность проверяют задания темы «Воспроизводимость результата»?

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

Вопрос 25 из 30

Какое ограничение механизма «Режимы strict и warnings» нужно учитывать даже при корректной работе обычного примера?

Use warnings FATAL=>'all' полезен в тестах, но в старом производственном коде может превратить ранее терпимые случаи в аварии без плана миграции. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код. Ограничение «use warnings FATAL=>'all' полезен в тестах, но в старом производственном коде может превратить ранее терпимые случаи в аварии без плана миграции» исчезает, если обычный пример один раз завершился успешно. Use warnings FATAL=>'all' полезен в тестах, но в старом производственном коде не может превратить ранее терпимые случаи в аварии без плана миграции. Базовое правило «strict и warnings вводят поэтапно вместе с тестами; предупреждения исправляют по причине, а не подавляют ковром» автоматически снимает указанную границу.

Вопрос 26 из 30

Какое предостережение по теме «Характеризующие тесты» нельзя заменить включением strict и warnings?

Золотые файлы удобны для большого вывода, но нуждаются в осмысленном сравнении, иначе любое изменение превращается в слепое обновление эталона. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Базовое правило «Характеризующие тесты покрывают реальные примеры, ошибки и побочные эффекты, особенно странности, от которых зависят пользователи» автоматически снимает указанную границу. Ограничение «Золотые файлы удобны для большого вывода, но нуждаются в осмысленном сравнении, иначе любое изменение превращается в слепое обновление эталона» исчезает, если обычный пример один раз завершился успешно. При strict и warnings отдельная проверка этой оговорки не требуется.

Вопрос 27 из 30

Что остаётся верным о теме «Декомпозиция», если учитывать контекст, отказ и побочный эффект?

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

Вопрос 28 из 30

Какое ограничение блока «Замена глобального состояния» следует проверять отдельным примером?

Ограничение «Неизменяемую конфигурацию можно разделять, но текущий пользователь, транзакция и временные результаты должны быть локальны операции» исчезает, если обычный пример один раз завершился успешно. Режимы strict и warnings полностью снимают это ограничение. Базовое правило «Глобальное состояние заменяют объектом контекста, параметрами или явным сервисом, начиная с границы, которую можно покрыть тестом» автоматически снимает указанную границу. Неизменяемую конфигурацию можно разделять, но текущий пользователь, транзакция и временные результаты должны быть локальны операции. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке.

Вопрос 29 из 30

Что остаётся верным о теме «Качество данных», если учитывать контекст, отказ и побочный эффект?

Базовое правило «Модернизация данных начинается с явной схемы, типов, обязательных полей и политики плохих записей» автоматически снимает указанную границу. Ограничение «Молчаливое исправление повреждённых данных облегчает импорт сегодня, но уничтожает след причины и затрудняет повторную обработку» исчезает, если обычный пример один раз завершился успешно. Достаточно включить strict и warnings, чтобы пограничный случай стал невозможен. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код. Молчаливое исправление повреждённых данных облегчает импорт сегодня, но уничтожает след причины и затрудняет повторную обработку.

Вопрос 30 из 30

Как точнее всего обозначить границу безопасного использования приёма «Воспроизводимость результата»?

Режимы strict и warnings делают вывод детерминированным и устраняют влияние окружения. Точный байтовый повтор нужен не всегда, но семантические различия следует отделять от шума представления. Если два запуска дают одинаковые суммы, различия дат и порядка строк можно всегда считать несущественными. Одинаковые входные данные гарантируют одинаковый отчёт независимо от часового пояса, версий библиотек и порядка обхода хеша. Воспроизводимость требует полного побайтового совпадения даже там, где порядок полей и формат пробелов не входят в контракт.