Программируйте, как будто нет оператора if

Оператор if — это один из тех фундаментальных инструментов, которые любой инженер-программист использует для решения повседневных задач. Это часть разработки программного обеспечения с первого дня, сразу после того, как студент напишет первый Hello, world. Он вездесущ, как и его разрушительная сила.

Хотя инженеры систематически не видят этой реальности, давайте посмотрим, как мы можем изменить свое мышление, чтобы преодолеть проблему и выиграть битву с печально известным оператором if.

В 2013 году я занимался реверс-инжинирингом программы 20-летней давности, для которой его первоначальный создатель не оставил документации. Через несколько недель я понял, как работает алгоритм — красоту, стоящая за ним, — и, следовательно, его пограничные случаи. Они обрабатывались операторами if (или их злыми воплощениями), в результате чего в коде появился целый лес из них.

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

Был в тот момент, я бросил себе вызов следующим:

Если бы было конечное количество операторов if, которые я мог бы использовать для каждого алгоритма, как бы я написал решение?

После некоторых размышлений я понял, что операторы if позволяют инженерам быть ленивыми при написании кода и, кроме того, предоставляют им простой способ не думать о том, как выразительно решить проблему — это создает образ мышления “Ага, вот пограничный случай, давайте напишем оператор if”.

Имея это в виду, теперь мы можем поговорить о мышлении, которым я обещал поделиться в начале:

Подумайте о задаче так, чтобы крайние случаи стали частью нормы, а не исключением.

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

Хотя это широко используемый фрагмент кода, который преподается в университетах по всему миру, этот код настолько плох, насколько это возможно — и если вы до сих пор не обращали внимание, то теперь вы можете видеть, почему… Да, оператор if в конце. Нам не нужно глубоко анализировать код, но в двух словах — он обрабатывает конкретный сценарий, когда запись должна быть удалена, но способ ее удаления зависит от того, является ли это первой записью или нет (пограничный случай).

Если мы воспользуемся новым мышлением и подумаем о проблеме таким образом, чтобы пограничные случаи стали частью нормы, а не исключением, то мы можем переписать этот древний фрагмент кода по-новому:

Посмотрите, как исчезает оператор if, но что более важно, пограничный случай теперь является частью нормы, а не исключением, и — как существенный побочный эффект — код становится более простым и выразительным.

Хотя это элементарный пример для понимания основной идеи, концепция гораздо сложнее. Речь идет о том, чтобы видеть крайние случаи и знать — инстинктивно — как превратить их в норму. Сначала это сложно, но с практикой становится легче.

Теперь откройте тот код, над которым вы работали вчера, и попытайтесь удалить свой первый оператор if, используя этот новый образ мышления!

Источник