Питер Макоуэн: Вычислительное мышление: Метод решения сложных задач

Еще можно оценить производительностьв плане скорости. Насколько быстро работает ваш алгоритм? Есть ли другие, которые справятся с задачей быстрее? Есть ли конкретные ситуации, когда алгоритм будет работать медленно? Насколько важны эти ситуации? Например, алгоритм быстрой сортировки quicksortобычно работает очень быстро. Однако, если одной из его версий заказать сортировку уже отсортированных позиций, работа будет идти до абсурдного медленно. То есть процесс сортировки уже расположенных по порядку позиций займет больше времени, чем сортировка бессистемно собранных позиций. Это отличный алгоритм, но было бы глупо использовать его, если вы знаете, что у вас почти все расположено по порядку. Ситуация, когда подходит один-единственный алгоритм, встречается редко. И нужно обязательно проверить, насколько он подходит для конкретного случая.

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

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

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

Существует еще и комплементарный подход к тестированию, который сводится к строгому аргументу.Вместо того чтобы запустить программу и смотреть, работает ли она, можно использовать право на аргумент. Для этого нужно с помощью логических рассужденийдоказать, почему определенные тесты гарантируют, что система работает правильно. Крайнее проявление этого метода — использование только логических доказательств, являющихся разновидностью математических доказательств. Когда вы создаете алгоритм или программу, вы представляете себе причины, в соответствии с которыми, с вашей точки зрения, они должны работать. На стадии оценки вы проверяете эти причины и смотрите, не пропустили ли вы какие-то детали. Часто такие доказательства делаются при абстракциисистемы. Это означает, что неважные детали игнорируются, что облегчает поиски доказательства. Однако необходимо различать, когда результаты тестирования применимы к модели системы, а когда — к самой системе. Если модель правильная, это не всегда значит, что правильна и система.

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