Файл: Интегрированные среды разработки..pdf

ВВЕДЕНИЕ

В настоящее время мы можем наблюдать тенденцию развития инструментов разработки программного обеспечения. Они призваны полностью или частично автоматизировать, ускорить и сократить процесс жизненного цикла программы: от создания архитектуры ПО до внедрения его в продуктовую среду, более того, современные интегрированные средства разработки позволяют настроить окружение под конкретные задачи программиста и использовать всевозможные “расширения” для индивидуализации этих процессов. Краткое рассмотрение, анализ и дальнейшие перспективы развитие интегрированных средств разработки мы проведем в данной работе.

1. История возникновения интегрированных средств разработки

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

1. Подготовка текста исходной кода программы на языке компилятора;
2. Подача входных данных в виде текста программы на вход компилятора;
3. Получить от компилятора результаты его работы в виде набора объектных файлов;
4. Подача набора полученных объектных файлов вместе с необходимыми библиотеками подпрограмм на вход компоновщику;
5. Получение от компоновщика единого, исполняемого файла программы и дальнейшая подготовка его к выполнению с помощью загрузчика;
6. Постановка программы на выполнение и при необходимости использование отладчика для проверки правильности выполнения программы.

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

---

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

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

Появление Makefile можно считать первым шагом по созданию систем программирования. Данные язык стал стандартным средством, единым для компиляторов всех разработчиков. Это было удобное, но достаточно сложное техническое средство, требующее от разработчика высокой степени подготовки и профессиональных знаний, поскольку сам командный язык Makefile был по сложности сравним с простым языком программирования.

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

2. Современные интегрированные среды разработки

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

---

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

Создание интегрированных сред разработки стало возможным благодаря бурному развитию персональных компьютеров и появлению развитых средств интерфейса пользователя (сначала текстовых, а потом и графических). Их появление на рынке определило дальнейшие развитие такого рода технических средств. Пожалуй, первой удачной средой такого рода можно признать интегрированную среду программирования Turbo Pascal на основе языка Pascal производства фирмы Borland [1]. Ее широкая популярность определила тот факт, что со временем все разработчики компиляторов обратились к созданию интегрированных средств разработки для своих продуктов.

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

Дальнейшее развитие средств разработки также тесно связано с повсеместным распространением развитых средств графического интерфейса пользователя. Такой интерфейс стал неотъемлемой составной частью многих современных ОС и так называемых графических оболочек. Со временем он стал стандартом де-факто практически во всех современных прикладных программах. Это не могло не сказаться на требованиях, предъявляемых к средствам разработки программного обеспечения. В их состав были сначала включены соответствующие библиотеки, обеспечивающие поддержку развитого графического интерфейса пользователя и взаимодействие с функциями API (Application Program Interface, прикладной программный интерфейс) операционных систем [2]. А затем для работы с ними потребовались дополнительные средства, обеспечивающие разработку внешнего вида интерфейсных модулей. Такая работа была уже более характерна для дизайнера, чем для программиста.

---

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

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

Простая среда разработки включает в себя редактор текста, компилятор и/или интерпретатор, средства автоматизации сборки и отладчик. Когда эти компоненты собраны в единый программный комплекс, говорят об интегрированной среде разработки (Integrated development environment – IDE). Такая среда представлена одной программой, не выходя из которой можно производить весь цикл разработки. В состав комплекса, кроме перечисленных выше компонент, могут входить: средства управления проектами, система управления версиями, разнообразные инструменты для упрощения разработки интерфейса пользователя, стандартные заготовки ("мастера"), упрощающие разработку стандартных задач, и др.

Обычно среда разработки включает в себя: текстовый редактор, компилятор и/или интерпретатор, средства автоматизации сборки и отладчик. Иногда она также содержит средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают в себя: браузер классов, инспектор объектов и диаграмму иерархии классов для использования при объектно-ориентированной разработке ПО. Хотя и существуют среды разработки, предназначенные для нескольких языков программирования, такие как Eclipse, NetBeans, Embarcadero RAD Studio или Microsoft Visual Studio, обычно среды разработки предназначается для одного определенного языка программирования – как, например, Visual Basic, Delphi, Dev-C++.

---

Иногда достаточно использовать только одну интегрированную среду разработки, но для больших проектов в среду разработки включаются разнородные продукты разных фирм, разных версий. Пример такого набора: файловый менеджер, набор вспомогательных утилит и пакетных файлов, С++Builder – как IDE, PLSQL Developer – для работы с СУБД Oracle, Cristal Reports – для создания отчетов, StarTeam – для ведения версий и поддержки коллективной работы.

2.1 Разновидности интегрированных сред разработки

Условно мы можем допустить разделение IDE на “облачные” (онлайн), взаимодействие с которыми происходит посредством веб-браузера и классические, инсталлируемые, поставляемые в программных пакетах (Desktop) или компилируемые, гибридные: поддерживающие работу с несколькими языками программирования и позволяющими вести разработку нетривиальных систем и сервисов.

Примерами существующих онлайн (веб) интегрированных сред разработки являются сервис Kodenvy.

Новое поколение IDE разительно отличается от себя же 2-3-летней давности. Ниже перечислим основные преимущества Kodenvy:

1. Архитектура предполагает расположение различных сервисов на выделенных серверах, то есть сборка проектов (если это Java) проистекает на отдельном сервере с предустановленными Maven и Ant. Билд артефакты копируются на runtime сервер, сердцем которого стал Docker. Благодаря Docker-у, приложение запускается в изолированном контейнере. Пользователю предоставляется возможность собирать образы из своих Dockerfile-ов. Таким образом, Codenvy не ограничиваются предоставлением виртуалки с определенной ОС. Предустановленные машины собраны на базе Debian Jessie. Поддержка Java.
2. Codenvy уделяет больше внимания тому языку, на котором, собственно, и написан сам сервис. Package view и список использованных библиотек для дерева проекта, подсветка синтаксиса, полноценный code-assistant, показывающий ошибки и предлагающий варианты их исправления, навигация по коду. Maven и Ant на борту. Автоматическое обновление зависимостей при сохранении build файлов.
3. Открытый исходный код. Codenvy шагает в объятия Eclipse, а собственный SDK потихоньку перекочевал в проект Eclipse Che.
4. поддержка Git, удобный Datasource плагин, CodeMirror с его плюшками, Google App Engine плагин, возможность сделать pull request в GitHub репозиторий прямо из воркспейса (новый “бранч”, “форк” и “пулл-реквеcт” делаются автоматически).
5. Codenvy также уделяют внимание вопросу клонирования окружений, когда в 1 клик можно поделиться проектом вместе с его окружением и настройками. По сути, чтобы попробовать Codenvy вовсе не нужно регистрироваться. Проектом можно поделиться с помощью вот такой кнопки, которую Codenvy называет Factory.

---