Анатолий Шалыто    

  Глубоко ошибается тот,

кто думает, что изделиями программиста

являются программы, которые он пишет.

 

     Программист обязан создавать заслуживающие

доверия решения и представлять их в форме

 убедительных доводов, а текст написанной программы

 является лишь сопроводительным материалом,

к которому эти доказательства применимы.

     Э. Дейкстра

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

Почему исходные тексты не решают проблему понимания программ?

Данный факт в очередной раз подтвердил мое мнение, что "Движение за открытые исходные тексты" (Open Source Software) не обеспечивает даже в этом достаточно простом (относительно реальных проектов) случае решения проблемы понимания программ. К счастью, так думаю не только я один. В частности, в работе [1] отмечается, что "центральный вопрос в практике программирования - вопрос о понимании программных текстов. Всегда хорошо иметь исходники, но проблема состоит в том, что зачастую их недостаточно. Чтобы понять некоторую нетривиальную программу, обычно требуется дополнительная документация. Эта потребность растет экспоненциально с ростом объема кода. В качестве примера попробуйте понять структуру нетривиального компилятора при условии, что вы не располагаете определением того языка, который им компилируется.

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

И еще: "Существуют ли какие-нибудь достойные свободные программы, вид которых не вызывает отвращения? До сих пор, несмотря на обилие свободного кода, нормальных программ среди него ужасно мало" [2].

О том, к чему это приводит, хорошо сказал великий русский математик, академик Л. С. Понтрягин: "Только хорошо выполненная работа дает радость! Выполненная небрежно, она вызывает отвращение и постепенно вырабатывает в человеке аморальное отношение к труду" [3].

Почему программы не проектируются?

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

Мне на ум приходят только три вещи, создаваемые без разработки проектной документации: дети, картины и программы. Видели бы вы удивленное выражение лица моего знакомого художника-экспрессиониста, когда я ему сказал, что программы, в том числе и для ответственных объектов, пишутся обычно в той же манере, что используется и им при написании картин!

Отметим, что применение документации не зависит от серийности - платье и в домашних условиях обычно шьется не кое-как, а по выкройке.

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

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

Во-вторых, аппаратура - "жесткая", а программа - "мягкая". Это упрощает внесение изменений в последнюю, но не служит основанием для того, чтобы вовсе не выпускать проектную документацию. Известно, что большинство программистов патологически не желают читать и уж тем более писать ее [4].

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

Это происходит, видимо, потому, что при программировании компилятор указывает на несоответствия, в то время как при подготовке проектной документации подсказывать некому.

Вопрос о качестве документации на программное обеспечение приобретает все большее социальное значение. Так, в статье [5] отмечается, что первое, "о чем мы должны подумать задолго до того, как кончится нефть" - это качество документации. "Наиболее запомнившееся и поразившее меня при выполнении совместного проекта с фирмой IBM отличие состояло в том, - пишет автор этой статьи, - как они относятся к документации. У них было принято - и это соответствовало практике, - что написано в документации, то так и есть, так и работает. У нас - никогда! У них из этого проистекала корпоративная уверенность в себе - на все вопросы они находили ответ в документации, утвержденной начальством. У нас не только документация плоха, но и мысли изложить толком никто не умеет. Я много раз сравнивал их доклады и наши "доклады". Однажды мы пригласили одного из лучших переводчиков. Он потом извинялся, что не смог толком перевести на английский, но я его успокоил, что и на русском-то ничего не понял... Этому нужно научиться. Эту часть работы следует любить и уважать". Несомненно, что и у них с документацией не все так хорошо, как говорит автор, но тенденция просматривается...

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

Все это приводит к тому, что даже "пользователи не считают ошибочное программное обеспечение чем-то из ряда вон выходящим" [6].

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

Что дает проектная документация?

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

Можно ли учиться проектированию и реализации программ по книгам? Да, но по разным: проектированию - по одним [7], реализации - по другим [8]. Книг с описанием обоих этапов почему-то нет. Их отсутствие могут восполнить открытые проекты.

Наконец-то появилось третье издание книги [9], содержащей более 1150 страниц. В ней проектирование и реализация рассматриваются совместно на примере моделирования работы лифта для двухэтажного здания, на каждом этаже которого может находиться не более одного человека :). Однако, во-первых, такая книга одна, во-вторых, пример там тоже один. Это напоминает музей с единственной картиной.

ПО с подробной открытой проектной документацией, содержащей исходные коды лишь как составную часть, может рассматриваться в качестве новой разновидности паттернов проектирования [10], позволяющих достаточно просто оценить как достоинства, так и недостатки выполненных проектов.

Проектная документация должна включать, в частности, формальную спецификацию по крайней мере на логику разрабатываемой программы, так как "то, что не специфицировано формально, не может быть проверено, а то, что не может быть проверено, не может быть безошибочным" [11], а также в связи с тем, что "если нет спецификации, то нет и ошибок" :) [12].

Отметим также, что без качественной проектной документации одно из основных достоинств объектно-ориентированного программирования - повторное использование кода - может приводить к большим неприятностям [13].

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

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

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

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

Движение за открытую проектную документацию

Исходя из изложенного и не найдя в Интернете исчерпывающей документации практически ни на один программный проект, мы (автор и профессор В. Г. Парфенов, декан факультета информационных технологий и программирования Санкт-Петербургского государственного университета информационных технологий, механики и оптики) в ноябре 2002 г. на открытии в городе на Неве полуфинальных соревнований Северо-Восточного европейского региона командного чемпионата мира по программированию объявили об образовании "Движения за открытую проектную документацию" (Foundation of Open Project Documentation), в поддержку которого был создан сайт http://is.ifmo.ru.

Для придания импульса этому движению я начал педагогический эксперимент со студентами кафедры "Компьютерные технологии", известной успехами на чемпионатах мира по программированию. Суть эксперимента состояла в следующем: студенты, разбившись на 40 групп (от одного до трех человек), должны были выполнить заинтересовавший их проект на основе автоматного программирования (программирования с явным выделением состояний) [14], причем так, чтобы по завершении работы проект можно было разместить на указанном сайте. В настоящий момент на сайте выложено более 30 проектов, и это число постоянно увеличивается за счет работ новых студентов.

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

Отметим, что среди сотен танков для игры "Robocode" только на разработанные нами [15, 16] есть подробная проектная документация. Такая же ситуация имеет место и для другой, еще более известной программистской игры - "Terrarium" [17].

Заключение

Из-за высокой трудоемкости создание качественной проектной документации в "программистском шоу-бизнесе" вряд ли привьется. Эта технология является "тяжелой", в то время как сейчас все шире пропагандируются "легкие" и "шустрые" (agile) технологии [18], например экстремальное программирование.

Однако есть и другие области программирования, в которых без "тяжелых" технологий не обойтись, и приходят новые люди, которым нравятся программы с хорошей проектной документацией. Один из студентов, впервые увидев проектную документацию, разработанную на основе автоматного программирования [14-17], воскликнул: "Она лучше, чем на телевизор! Видимо, она такая же, как для подводной лодки".

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

Автор полагает, что даже если движение и не получит значительной поддержки, то создание аналога Третьяковской галереи на сайте http://is.ifmo.ru , несомненно, полезно: "Для меня, истинно и пламенно любящего живопись, не может быть лучшего желания, как положить начало общественного, всем доступного хранилища изящных искусств, принесущего многим пользу, всем удовольствие" (П. М. Третьяков).

Работа выполняется при поддержке Российского фонда фундаментальных исследований по гранту N 02-07-90114 "Разработка технологии автоматного программирования".

Полная версия настоящей работы опубликована в виртуальном компьютерном музее (www.computer-museum.ru) в разделе "Программная инженерия".

Литература

1. Безруков Н. Повторный взгляд на "собор" и "базар". BYTE/Россия, 2000, N 8, с. 37-47.

2. Протасов П. Снизу. Компьютерра, 2003, N 19, с. 25-30.

3. Исследователь "руля". Информатика, 2003, N 11, с. 32.

4. Демин В. Проблемы выхода российских разработчиков на Запад. PC Week/RE, N 32/2001, с. 25.

5. Скрипников А. Когда кончится нефть. Известия, 09.09.2003.

6. Буч Г. Создание будущего. Открытые системы, 2001, N 12, с 38-40.

7. Буч Г., Рамбо Д., Джекобсон А. UML. Руководство пользователя. М., ДМК, 2000. 390 с.

8. Страуструп Б. Язык программирования C++. М., Бином, СПб., Невский диалект, 2001. 1038 с.

9. Дейтел Х. М., Дейтел П. Дж. Как программировать на C++. М., Бином, 2003. 1150 с.

10. Гамма Э., Хелм Р., Джонсон Р., Влиссидис Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб., Питер, 2001. 383 с.

11. Зайцев С. С. Описание и реализация протоколов сетей ЭВМ. М., Наука, 1989. 110 с.

12. Аллен Э. Типичные ошибки проектирования. СПб., Питер, 2003. 310 с.

13. Тэллес М., Хсих Ю. Наука отладки. М., КУДИЦ-ОБРАЗ, 2003. 550 с.

14. Шалыто А. А., Туккель Н. И. Программирование с явным выделением состояний. Мир ПК, 2001, N 8, с. 116-121; N 9, с. 132-138. http://is.ifmo.ru , раздел "Статьи".

15. Туккель Н. И., Шалыто А. А. Система управления танком для игры "Robocode". Вариант 1. Там же, раздел "Проекты".

16. Кузнецов Д. В., Шалыто А. А. Система управления танком для игры "Robocode". Вариант 2. Там же.

17. Марков С. М., Шалыто А. А. Система управления травоядным существом для игры "Terrarium". Там же.

18. Cockburn A. Agile Software Development. N. J., Addison-Wesley, 2001. 388 р. 4 Об авторе: Шалыто Анатолий Абрамович, д-р техн. наук, профессор Санкт-Петербургского государственного университета информационных технологий, механики и оптики, победитель конкурса исследовательских проектов в области автоматизации проектирования интегральных схем, который проводился компанией Intel в СНГ в 2003 г.