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

Высокие технологии в конечном итоге создаются для людей и в помощь людям. Это значит, что вычислительное мышление главным образом связано с решением проблем людей, а не технологий. Поэтому алгоритмическое мышлениедолжно включать понимание людейи особенно их сильных и слабых сторон. Мы видели это на многочисленных примерах — от помощи пациентам с синдромом «запертого человека» до заботы о том, чтобы медсестры не делали ошибок. Вот еще один пример, подтверждающий эту мысль. Представьте, что вы пишете алгоритм, обеспечивающий безопасность банковских операций в интернете. Можно придумать алгоритм, который потребует пароля из 1000 произвольных символов, куда нельзя вставлять существующие слова. Это, безусловно, обеспечит высокую степень безопасности! А еще это будет очень глупо. Ни один человек, за исключением пары случайных гениев, не запомнит такой пароль. Алгоритм окажется бесполезным. Решение задач с помощью вычислительного мышления должно быть связано с пониманием возможностей людей.

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

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

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

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

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

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

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

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