Не программа, а проект

Вообразите, что вы не программу на Visual Basic пишете, а собираете на столе игрушечную железную дорогу. В вашем распоряжении находятся объекты: стол, рельсы, паровозы, вагоны, светофоры, машинисты, стрелочники и т.д. Чтобы игрушка заработала, вам нужно выполнить 3 этапа:

1. Собрать ее вручную, то есть поместить на свои места и правильно соединить рельсы, вагоны и т.д.

2. Для лучшего понимания 2 этапа вообразим себе, что наша игрушка очень интеллектуальная, то есть поведение многих объектов (таких как машинисты, стрелочники, светофоры и другие) может быть сложным и осуществляться по программе. Тогда вторым этапом вашей работы будет - написать для каждого из таких объектов программу поведения. Так, в программе для машиниста одна из команд может быть такой: "Если впереди на светофоре красный свет - тормози", а в программе для светофора - такой - "Если два поезда опасно сблизились - зажигай красный свет".

3. Запустить игрушку и посмотреть, как она работает. Если произошло крушение или что-нибудь еще пошло не так, как надо, то значит одно из двух: или вы неправильно собрали игрушку или написали неправильные программы. Вы исправляете ошибки и снова запускаете игрушку. Снова смотрите, снова исправляете. И так до тех пор, пока все не заработает нормально. Этот процесс называется отладкой.

Современный программист, работающий в средах визуальной разработки программ, выполняет те же три этапа. На 1 этапе он вручную расставляет на экране компьютера объекты, которые будут выполнять его программу, на 2 этапе пишет программу, на 3 этапе запускает ее. Что конкретно я имею в виду под расстановкой объектов, вы узнаете в следующем разделе, а сейчас остается сказать, что из-за 1 этапа работа программиста теперь напоминает работу конструктора-проектировщика и частично из-за этого же продукт работы программиста называют теперь не программой, а проектом. Хотя термин этот еще не привился и чаще пользуются прежним. Я тоже, наверное, буду их путать. Правда, обещаю, что не в ущерб смыслу.