В начале была подпрограмма
В 1951 году была опубликована, возможно, первая книга о программировании. Он назывался «Подготовка программ для электронного цифрового компьютера» [1]. Его написали Морис Уилкс (разработчик EDSAC), Дэвид Уиллер (известный как «Преобразование Барроуза-Уиллера») и Стэнли Гил (пионер EDSAC).
Вторая глава этой книги познакомила мир с концепцией подпрограмм. Это был способ разложить программу на более мелкие части, чтобы сделать компьютеры более общими инструментами, способными выполнять несколько видов операций помимо арифметических:
Цифровая вычислительная машина может выполнять только основные арифметические операции, такие как сложение, вычитание, умножение и деление.
Другим более интересным применением подпрограмм было разложение программы на более мелкие части. Хотя мы все еще были далеки от чудес структурированного программирования [2], мы видим, что авторы понимают необходимость иметь способ облегчить создание программного обеспечения.
Они видят, что подпрограммы также помогут с тестированием и, если необходимо, исправлением ошибок. Также наличие библиотеки готовых подпрограмм ускорит процесс создания программного обеспечения [3]. Кто бы мог подумать, что повторное использование кода станет настолько важным в будущем?
Затем в следующем году Дэвид Уиллер написал статью о подпрограммах, в которой он расширил свои идеи по этой теме. Он назывался «Использование подпрограмм в программах» [4].
Там он описывает подпрограмму как:
автономная часть программы, которую можно использовать в различных программах
Он отмечает, что нет необходимости писать программы таким образом, разделяя их на более мелкие части, но тем самым мы не только получаем возможность повторного использования программного обеспечения, но и упрощаем его понимание и тестирование. Программисты могут сосредоточиться на каждой части проблемы отдельно, а затем составить их, чтобы сформировать решение исходной проблемы. Интересно видеть, что с самого начала нашей дисциплины люди понимали, что нет необходимости в элегантном программном обеспечении, поскольку машина в любом случае сможет запускать его без проблем [5], но поскольку программирование - это человеческая деятельность, мы должны создавать методы, которые позволяют людям лучше работать с программным обеспечением, независимо от того, создаем ли мы его или тестируем.
Таким образом, подпрограммы легче кодировать и тестировать изолированно от остальной программы.
Они понимали, что возможность тестировать подпрограммы по отдельности повысит надежность всей программы, поскольку легче доказать правильность программы, если мы знаем, что отдельные части, составляющие ее, работают без ошибок. Затем они использовали основные подпрограммы, которые работали бы как то, что мы сегодня называем интеграционным тестированием, чтобы убедиться, что вся программа работает должным образом.
Еще один интересный момент, обсуждаемый Уилером, заключается в том, что, когда мы создаем библиотеку подпрограмм, приобретая универсальность, мы можем потерять производительность, поскольку нам необходимо адаптировать подпрограмму к стандарту библиотеки. Тем не менее он думал, что самая сложная часть создания библиотеки - это ее документирование, чтобы другие люди могли ее использовать. Прошло 65 лет, а мы все еще сталкиваемся с той же проблемой наличия полезной документации по программному обеспечению.
Однако даже после того, как оно было закодировано и протестировано, остается значительная задача - написать описание, чтобы люди, не знакомые с внутренним кодированием, тем не менее могли легко его использовать. Эта последняя задача может быть самой сложной.
В документе завершается изложение цели написания подпрограмм. Опять же, обратите внимание, что они не нужны.
Вышеупомянутые замечания можно резюмировать, сказав, что подпрограммы очень полезны - хотя и не являются абсолютно необходимыми - и что основные цели, которые следует иметь в виду при их построении, - это простота использования, правильность кодов и точность описания.
Написание чистого кода не является обязательным требованием для работы программы, но становится необходимостью, когда мы хотим иметь код, который было бы проще использовать, подтверждать правильность и, самое главное, убедиться, что он решает проблему, которую мы хотели решить в первую очередь.
Все сложности следует - по возможности - скрыть от глаз.
Примечания:
- Подготовка программ для ЭЦП. Https://archive.org/details/programsforelect00wilk
2. Структурированное программирование. Http://dl.acm.org/citation.cfm?id=1243380
3. Имейте в виду, что, как видно на картинке вверху, подпрограммы на самом деле хранились в библиотеке!
4. Использование подпрограмм в программах. Http://www.laputan.org/pub/papers/wheeler.pdf
5. См. Http://alvaro-videla.com/2014/09/a-programmers-role.html.
