Что такое REP-цикл (РЕП-цикл, РЭП-цикл)
REP-цикл означает «Read, Eval, Print» и описывает то, чем зарабатывает себе на жизнь интерпретатор Lisp: он читает входные данные, производит на их основе вычисления и выводит результат. На этом скриншоте приведен пример REP-цикла: я что-то печатаю, интерпретатор Lisp это читает, вычисляет и печатает результат.
Если рассмотреть процесс в более крупном масштабе, то можно сказать, что когда вы пишете код, то находитесь в макро-версии REP-цикла, называемой «циклом редактирования-компиляции-тестирования». Вы редактируете код, компилируете его и тестируете, проверяя, хорошо ли он работает.
Важно отметить, что при написании программы этот цикл надо пройти многократно, поэтому чем быстрее выполняется цикл редактирова-ния-компиляции-тестирования, тем выше ваша производительность, и ограничивает ее природная невозможность мгновенной компиляции. Это формальная теоретическая причина, по которой программистам нужны как можно более быстрые компьютеры, а разработчики компиляторов прилагают всяческие усилия для достижения сверхкороткого цикла редактирования-компиляции-тестирования. В Visual Basic этому способствует выполнение грамматического и синтаксического анализа каждой строки по мере ее ввода, благодаря чему окончательная компиляция оказывается сверхбыстрой. В Visual C++ для этого есть инкрементная компиляция, прекомпилированные заголовки и инкрементная сборка.
Но как только вы начинаете работать в большой команде, где много разработчиков и тестеров, вы снова сталкиваетесь с тем же самым циклом, только гораздо более крупным (вот они где - фракталы!). Тестер находит в коде ошибку и регистрирует ее. Программист исправляет ошибку. Через какое время тестер получит исправленный вариант кода? В некоторых организациях этот цикл «тест-регистрация ошибки-исправление-по-вторное тестирование» может занять пару недель, что свидетельствует о непродуктивности работы организации в целом. Для того чтобы весь процесс разработки протекал без сбоев, необходимо сократить цикл между регистрацией ошибки и повторным тестированием.
Если рассмотреть процесс в более крупном масштабе, то можно сказать, что когда вы пишете код, то находитесь в макро-версии REP-цикла, называемой «циклом редактирования-компиляции-тестирования». Вы редактируете код, компилируете его и тестируете, проверяя, хорошо ли он работает.
Важно отметить, что при написании программы этот цикл надо пройти многократно, поэтому чем быстрее выполняется цикл редактирова-ния-компиляции-тестирования, тем выше ваша производительность, и ограничивает ее природная невозможность мгновенной компиляции. Это формальная теоретическая причина, по которой программистам нужны как можно более быстрые компьютеры, а разработчики компиляторов прилагают всяческие усилия для достижения сверхкороткого цикла редактирования-компиляции-тестирования. В Visual Basic этому способствует выполнение грамматического и синтаксического анализа каждой строки по мере ее ввода, благодаря чему окончательная компиляция оказывается сверхбыстрой. В Visual C++ для этого есть инкрементная компиляция, прекомпилированные заголовки и инкрементная сборка.
Но как только вы начинаете работать в большой команде, где много разработчиков и тестеров, вы снова сталкиваетесь с тем же самым циклом, только гораздо более крупным (вот они где - фракталы!). Тестер находит в коде ошибку и регистрирует ее. Программист исправляет ошибку. Через какое время тестер получит исправленный вариант кода? В некоторых организациях этот цикл «тест-регистрация ошибки-исправление-по-вторное тестирование» может занять пару недель, что свидетельствует о непродуктивности работы организации в целом. Для того чтобы весь процесс разработки протекал без сбоев, необходимо сократить цикл между регистрацией ошибки и повторным тестированием.
Источник: ДЖОЭЛ О ПРОГРАММИРОВАНИИ
Оставить свой ответ:
