В период развития вычислительной техники в СССР (1960–1985 гг.) отсутствовали массовые интерактивные средства разработки программного обеспечения: персональные ЭВМ с дисплеями, интегрированные среды разработки (IDE), системы контроля версий и оперативный доступ к компиляторам. Основным носителем данных и программного кода являлись перфокарты — носители информации на плотном картоне с фиксированным форматом.
Настоящая статья описывает технологический процесс программирования на базе перфокарт, роль инженеров-программистов и операторов вычислительных центров, а также анализирует наследие указанного периода с точки зрения современной практики разработки ПО. Материал подготовлен компанией «Карельский разработчик» (IT-сектор, г. Петрозаводск) в рамках цикла публикаций об истории отечественной инженерии.
Перфокарта как основной носитель программного кода
Технические характеристики перфокарты
Перфокарта, используемая в советских вычислительных центрах (ВЦ), представляла собой лист картона размером 187 × 83 мм, содержащий 80 колонок. Каждая колонка включала 12 позиций для пробивки отверстий. Кодирование символов (цифр, букв латинского и русского алфавитов, специальных знаков) осуществлялось комбинацией отверстий в одной колонке.
В зависимости от типа оборудования применялись два основных формата:
- ГОСТ 9220-76 (совместимый с международным стандартом ISO 1681);
- ОС (операционная система) ЕС ЭВМ — 64 символа, включая русские буквы.
Одна перфокарта соответствовала одной строке исходного кода, команде или записи данных. Физический объём информации на одной карте — 120 байт (при максимальной плотности кодирования).
Преимущества и ограничения
Преимущества перфокарт в условиях эксплуатации ВЦ:
- низкая стоимость производства (тиражное изготовление в типографиях);
- устойчивость к электромагнитным помехам;
- возможность визуального контроля (отверстия видны невооружённым глазом);
- длительный срок хранения при соблюдении температурного режима (до 50 лет).
Ограничения:
- невозможность изменения записи без замены носителя;
- низкая плотность хранения данных;
- необходимость соблюдения порядка следования карт (физическая сортировка);
- чувствительность к механическим повреждениям (заломы, влажность).
Жизненный цикл программы на перфокартах
Этап 1. Разработка алгоритма
Программист разрабатывал алгоритм в виде блок-схемы на бумажном носителе (миллиметровая бумага, ГОСТ 19.002-80 и ГОСТ 19.003-80). Допускалось использование алгоритмических языков высокого уровня (АЛГОЛ-60, ФОРТРАН-IV, КОБОЛ, а затем РАЯ и АЛГЕК). Однако фактическая запись кода выполнялась с учётом ограничений формата перфокарты:
- длина строки — не более 80 символов;
- отсутствие контекстной подсветки и автодополнения;
- ручное управление нумерацией строк (для возможности вставки карт впоследствии).
Перед началом кодирования программист заполнял бланк программирования — лист бумаги, разграфлённый на 80 колонок, куда карандашом вписывались символы. Бланк служил промежуточным звеном между алгоритмом и перфорацией.
Этап 2. Перфорация
Перфорация выполнялась на оборудовании двух типов:
| Тип устройства | Назначение | Производительность |
|---|---|---|
| Ручной перфоратор (например, П-80) | Индивидуальная работа программиста | 10–20 карт/час |
| Электрический перфоратор с клавиатурой (например, ПЭ-80) | Работа оператора ВЦ | 60–80 карт/час |
При наборе использовался контроль повторным набором: одна и та же информация вводилась дважды на разных устройствах, после чего карты сравнивались автоматическим контроллером. Расхождение означало брак и требовало перезаписи.
Этап 3. Верификация и сортировка
Полученный набор перфокарт (колода) подвергался следующим контрольным процедурам:
- Визуальный контроль — проверка отсутствия физических дефектов.
- Технический контроль — прогон через считыватель для проверки синтаксиса (без выполнения команд).
- Сортировка — восстановление порядка карт при случайном перемешивании с помощью сортировальной машины.
Ошибки на этом этапе классифицировались как:
- пропуск колонки (непробитая позиция);
- лишнее отверстие (приводило к неверной интерпретации символа);
- нарушение порядка следования (требовало физической перестановки карт).
Этап 4. Компиляция и отладка
Колода перфокарт загружалась в считывающее устройство ЭВМ (например, ЕС-6020 для ЕС ЭВМ, или УСВ-1 для БЭСМ-6). Компиляция выполнялась в пакетном режиме: программа вместе с управляющими картами (JCL — Job Control Language) передавалась на выполнение.
В случае ошибки компиляции ЭВМ распечатывала на АЦПУ (алфавитно-цифровое печатающее устройство) листинг ошибок с указанием номера перфокарты и типа ошибки. Программист вручную находил соответствующую карту, браковал её, изготавливал новую и заново собирал колоду.
Среднее время одного цикла «правка → компиляция → результат» составляло от 4 до 24 часов в зависимости от загрузки ВЦ и удалённости рабочего места программиста от вычислительного зала.
Этап 5. Сдача в эксплуатацию
После завершения отладки программный продукт передавался в архив ВЦ в виде:
- основной колоды перфокарт;
- резервной копии (дубликат колоды);
- технической документации (блок-схемы, описание входных/выходных данных).
Для долгосрочного хранения перфокарты помещались в закрытые коробки с указанием содержимого и даты создания. Замена или модификация программы требовали изъятия и замены конкретных карт во всей колоде.
Организация труда программистов в СССР
Разделение ролей
В отличие от современной модели «full-stack разработчик», в советских ВЦ существовало жёсткое разделение функций:
| Роль | Обязанности | Требования |
|---|---|---|
| Инженер-программист | Разработка алгоритмов, заполнение бланков, анализ листингов | Высшее техническое образование |
| Оператор перфораторного бюро | Перфорация карт, контроль качества, тиражирование | Среднее специальное образование, скорость набора от 60 карт/час |
| Системный программист | Настройка ОС, разработка компиляторов, ведение библиотек стандартных программ | Высшее образование, знание машинных кодов |
| Оператор ЭВМ | Загрузка колод, запуск задач, снятие распечаток | Среднее техническое образование |
Документооборот
Программист не имел прямого доступа к ЭВМ. Передача данных осуществлялась через диспетчера ВЦ по следующим документам:
- Задание на счёт — указывалась программа, входные данные, требуемые ресурсы.
- Журнал учёта машинного времени — фиксировалось фактическое время компиляции и счёта.
- Акт приёмки программы — подписывался заказчиком после успешного тестирования.
Один цикл «постановка задачи → получение результата» занимал в среднем 2–5 рабочих дней.
Типовые ошибки и их стоимость
Наиболее частыми ошибками при программировании на перфокартах являлись:
- Смещение колонок — начало кода не с 7-й колонки (стандарт FORTRAN). Последствие — синтаксическая ошибка, перезапуск компиляции.
- Пропуск управляющей карты (например, /* END). Последствие — ЭВМ ожидала продолжения ввода до истечения таймаута, потеря машинного времени.
- Ошибка в нумерации строк (при использовании метода фиксированного формата). Последствие — программа выполнялась в неверном порядке.
Стоимость одной ошибки измерялась не в минутах разработчика, а в часах простоя вычислительного центра и расходе расходных материалов (перфокарт, ленты для АЦПУ). По оценкам отраслевых журналов того периода, до 30% машинного времени тратилось на повторные компиляции из-за ошибок перфорации.
Сравнение с современным процессом разработки ПО
| Параметр | СССР (эпоха перфокарт) | Современная практика |
|---|---|---|
| Среда разработки | Бланк + дырокол | IDE (Visual Studio, VS Code, IntelliJ IDEA) |
| Контроль версий | Физическая сортировка карт | Git, Mercurial, Subversion |
| Обнаружение ошибок | После компиляции (через часы) | В реальном времени (линтеры, компиляция on-the-fly) |
| Время цикла правка-компиляция | 4–24 часа | 2–10 секунд |
| Коллаборация | Передача карт через диспетчера | Pull request, code review в GitLab/GitHub |
| Документирование | Блок-схемы по ГОСТ | Javadoc, Doxygen, MkDocs, Confluence |
| Резервное копирование | Дубликат колоды в другой коробке | Cloud backup (AWS S3, Azure Blob) |
Принципиальное отличие: в современной разработке программист оперирует абстракциями (классы, функции, API), в то время как в эпоху перфокарт программист был вынужден постоянно помнить о физическом носителе (номер карты, колонка, позиция отверстия).
Наследие: что современный IT перенял у инженеров СССР
Опыт программирования на перфокартах сформировал ряд профессиональных качеств, которые остаются актуальными в настоящее время:
- Дисциплина документирования. Отсутствие возможности быстро исправить ошибку приучало к тщательному проектированию перед реализацией. Современный аналог — практика написания технического задания и архитектурного решения до стадии кодирования.
- Экономия ресурсов. Ограниченность машинного времени и дороговизна вычислительных циклов выработала навык написания эффективного кода. В эпоху облачных вычислений этот навык трансформировался в оптимизацию стоимости вычислительных операций (FinOps).
- Работа со стеком ошибок. Анализ распечатки АЦПУ с номерами перфокарт и кодами ошибок — прямой предшественник современной работы с логами и трассировкой стека исключений.
- Резервное копирование как норма. Обязательное создание дубликата колоды перфокарт заложило культуру бэкапов, которая в современных условиях реализуется через автоматическое резервное копирование репозиториев и баз данных.
- Технологическая дисциплина. Жесткое соблюдение формата строки (80 колонок), правил именования и последовательности карт — прообраз современных код-стайлов (Google Java Style Guide, PEP 8) и pre-commit хуков.
Отношение к современной практике в компании «Карельский разработчик»
Коллектив компании «Карельский разработчик» рассматривает исторический опыт программирования на перфокартах как иллюстрацию фундаментального принципа:
Качество программного продукта обратно пропорционально допустимой частоте ошибок на этапе ввода.
Современные IDE и системы автоматизации не снижают требований к квалификации разработчика, а переносят фокус внимания с синтаксических аспектов на логические и архитектурные.
Практические выводы, интегрированные в рабочий процесс «Карельского разработчика»:
- обязательное прохождение код-ревью (аналог контроля перфокарт оператором);
- ведение технической документации в актуальном состоянии (принцип «бланк программирования» для архитектурных решений).
Заключение
Программирование на перфокартах в СССР было не архаизмом, а вынужденной и внутренне логичной технологической практикой, соответствующей уровню развития вычислительной техники того периода. Инженеры-программисты успешно решали задачи государственной важности (расчёты в аэрокосмической отрасли, гидродинамике, экономическом планировании) при отсутствии современных средств отладки и контроля версий.
Достижения того периода — не только конкретные программные продукты, но и методологическое наследие: культура тщательного проектирования, технологическая дисциплина и уважение к машинному времени. Указанные качества сохраняют актуальность и в настоящее время, составляя основу профессиональной этики в сфере IT.
Компания «Карельский разработчик» продолжает традицию ответственного подхода к разработке программного обеспечения, применяя современные инструменты в рамках методологии, проверенной десятилетиями инженерной практики.