Структурное программирование

Первой парадигмой, получившей всеобщее признание, была парадигма структурного программирования. Она была предложена Эдсгером Вибе Дейкстрой в 1968 году.

Дейкстра предложил заменить <i>goto </i>переходы конструкциями <i>if/then/else</i> и <i>do/while/until</i>
Дейкстра предложил заменить goto переходы конструкциями if/then/else и do/while/until

Эдсгер Вибе Дейкстра

Эдсгер Вибе Дейкстра родился в Роттердаме в 1930 году. В марте 1952 года в возрасте 21 года Дейкстра устроился на работу в Математический центр Амстердама и стал самым первым программистом в Нидерландах. В 1955 году, имея за плечами трехлетний опыт программирования и все еще будучи студентом, Дейкстра решил для себя, что интеллектуальные вызовы в программировании намного более обширные, чем в теоретической физике. В итоге, он принял окончательное решение связать свою жизнь с программированием.

Открытие структурного программирования

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

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

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

Однако в других случаях, инструкция goto не вызывала таких проблем. Дейкстра заметил, что что эти случаи соответствуют простым структурам выбора и управления итерациями, таким как if/then/else и do/while. Модули, использующие только такие управляющие структуры, можно было рекурсивно разложить на доказуемые единицы.

Данные структуры, в сочетании с последовательным выполнением, занимают особое положение. Они были идентифицированы за два года до этого Бёмом и Якопини, доказавшими, что любую программу можно написать, используя всаего три структуры: последовательность, выбор и итерации.

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

Функциональная декомпозиция

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

Тестирование

Тестирование показывает присутствие ошибок, а не их отсутствие.

Эдсгер Вибе Дейкстра

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

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

Такие доказательства можно применить только к доказуемым программам. Недоказуемую программу — например, из-за неумеренного использования goto — нельзя считать правильной, сколько бы тестов к ней не применялось.

Парадигма структурного программирования заставляет нас рекурсивно разбивать программы на множество мелких и доказуемых функций. В результате мы получаем возможность использовать тесты, чтобы попытаться доказать их неправильность. Если тесты успешно проходят, мы считаем функции достаточно правильными.

Заключение

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

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

Для написания данной статьи я использовал материал из книги "Чистая архитектура" Роберта Мартина. Если вы хотите быть хорошим архитектором, я горячо рекомендую ее к прочтению. Если вы хотите порекомендовать другим читателям хорошие книги по архитектуре - пишите в комментариях.

О том, как выглядит добротная, чистая архитектура, позволяющая разработчикам создавать системы, способные приносить прибыль компаниям долгое время, я рассказываю в своем телеграм-канале solonkov.team. Там же вы сможете найти аудио-версии статей, задать интересующие вас вопросы и обратиться за консультацией.

99
1 комментарий

Все кроме последних трех абзацев взято из книги чистая архитектура. Это какой-то новый уровень графоманства. P.s. «Войти в АйТи», сори, не заметил

Ответить