Беседы о программировании
Вы привыкли думать, что если сделать что-то становится проще, то люди станут делать это “что-то” лучше. Но часто происходит противоположное. Так, на смену длинным, содержательным письмам пришли пустые телефонные разговоры; камерная музыка уступила место 40 лучшим радиохитам. Мне очень не хочется думать о том, что недорогие, широкополосные линии связи могут сделать с качеством коммерческого ПО.
В течение нескольких последних месяцев я наблюдал серьезное снижение важности новых главных версий ПО. Разработчики говорят удивительные вещи о своих собственных продуктах, например: “Ну, это не столь закончено, как нам бы того хотелось, но через месяц вы найдете первую модернизацию на нашей Web-странице”. Как будто бы первоначальная продажа делается лишь с целью увеличения капиталовложений: “Дайте нам деньги сейчас, и мы закончим работу”.
Создается впечатление, что люди прорабатывали свои продукты более серьезно, когда выход версии ПО - “.0” или модернизации - был дорогостоящим событием. Конечно же, мы цинично предупреждаем против покупки версии “.0” чего бы то ни было от Microsoft, но в целом, я думаю, мы ожидаем, что главная версия будет не просто пригодна к эксплуатации, но и неотразима.
В своем докладе на конференции Dynamic Objects в Бостоне Ховард Шроуб из лаборатории искусственного интеллекта Массачусетского технологического института убеждал, что теперь нужно по-новому посмотреть на вещи. Шроуб, в настоящее время “одолженный” из MIT в Information Technology Office фирмы ARPA, приехал на эту конференцию для обсуждения эволюционной модели разработки приложений.
По наблюдению Шроуба, наш подход в прошлом основывался на старой модели выпуска ПО как редкого и дорогостоящего события. Мы двигались от требований к приложению - к архитектуре, реализации, доставке. Требования были стабильны - точнее, рассматривались как стабильные - в течение достаточно длительных периодов времени, что придавало смысл обширной оптимизации нашего кода на нижнем уровне.
Новая теория эволюции
Будущие усилия, по наблюдению Шроуба, следует направить на выработку семейств развивающихся приложений, а не индивидуальных проектов с изредка появляющимися чрезвычайно важными модернизациями. Требования должны быть описательными и приспособляемыми, а не жестко заданными и закодированными в приложении. Не должно быть разницы между процессами разработки и поддержки. Напротив, само понятие “поддержка” сольется с нескончаемым процессом “эволюционной разработки”.
Это имеет важное значение для наших инструментов разработки. Сегодня, по мере продвижения к исполняемому продукту, наши инструменты отбрасывают информацию о разработке. Комментарии в исходном коде - типичный пример.
Инструменты следующего поколения следует строить на основе предположения, что работа над приложением никогда не прекращается. Информация о разработке должна быть всегда доступна как руководство по проблемам, которые могут возникнуть при расширении возможностей приложения, и как средство избежать повторения одних и тех же экспериментов.
Такие системы вовсе не есть нечто неизведанное. LISP-системы предоставляют непосредственный доступ к исходным текстам, документации и прочей информации по разработке. Java и Smalltalk предоставляют подобные возможности.
Давайте вернем эту разновидность поддержки в общее русло разработки приложений. Надо использовать такие инструменты, чтобы выпускать качественные продукты каждый раз вместо низкопробных версий “.0”, которые работают лишь “в целом”.
Питер Коффи
