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

Вопрос 1 из 30

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

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

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

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

Вопрос 6 из 30

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

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

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

Вопрос 7 из 30

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

no warnings 'uninitialized';

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

Вопрос 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;

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

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

Вопрос 20 из 30

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

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

Вопрос 21 из 30

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

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

Вопрос 22 из 30

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

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

Вопрос 23 из 30

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

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

Вопрос 24 из 30

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

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

Вопрос 25 из 30

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

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

Вопрос 26 из 30

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

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

Вопрос 27 из 30

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

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

Вопрос 28 из 30

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

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

Вопрос 29 из 30

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

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

Вопрос 30 из 30

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

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