Понятие технологии программирования, жизненный цикл программы и постановка задачи

Мы решили, что из-за таких простых программ, как ассемблер, не стоит "городить огород", и за короткое время реализовали новые кросс-ассемблер и интерпретатор, которые вместе с текстовым документатором и некоторыми сервисными программами составили основу первой внедренной нами в производство (1984 год) технологической системы, интенсивно использовавшейся сотнями разработчиков ФПО. Разумеется, мы отчетливо понимали ограниченность возможностей такой технологии, но ее популярность имела свои причины:

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

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

Разумеется, мы понимали, что работа без четких сроков и ответственности перед соисполнителями возможна только исследовательская и экспериментальная, да и то в ограниченных объемах, но работа по конкретным заказам в промышленности дала массу новых впечатлений и импульсов для изучения. Например, уход исполнителя в самом разгаре работ. Оказалось, что в промышленности это довольно частое явление (отсюда необходимость архивации и других средств отчуждения результатов работы от исполнителя); в коллективе из нескольких сот человек всегда есть люди, попросту не желающие работать, и хотя мы понимаем, что оценка работы программиста в байтах весьма сомнительна, это не отменяет необходимости учета индивидуально выполненной работы (измерение). Даже такое "приземленное" соображение, как разделение ответственности за принятые решения и ошибки, также нельзя сбрасывать со счетов (отсюда строгое документирование).

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

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

Только после двух-трех лет работы в промышленности мы осознали, что нельзя все сводить к программному инструментарию. Поначалу мы с гневом отказывались от требований начальства детально документировать, кто, что и за какой период написал, но оказалось, что в большом коллективе всегда находятся милые в общении, всеми любимые организаторы всевозможных мероприятий, которые вообще ничего не делают по работе. Первую сдачу проекта для Управления правительственной связи КГБ я завалил, так как буквально перед самой сдачей кто-то стащил одну (!) перфокарту, а эти товарищи всегда начинали с чистой машины и полной перетрансляции. Вредителя так и не нашли, зато я получил хороший урок. Мы быстро реализовали контрольно-учетные программы, архивы с контролируемым доступом, многоуровневые системы сбора версий ПО и тому подобные "шпионские штучки". Так я впервые осознал разницу между "программированием для себя" и "программированием для хозяина", о которой так красочно рассказывал академик А. П.Ершов.

В более поздних публикациях эту разницу стали выражать более канцелярским стилем – просто программа и программный продукт.