╨б╨╛╨╖╨┤╨░╨╜╨╕╨╡ ╤Б╤А╨╡╨┤╤Л ╨┐╤А╨╛╨│╤А╨░╨╝╨╝╨╕╤А╨╛╨▓╨░╨╜╨╕╤П

1. Создание среды программирования

2. 1. Среда программирования

1.1 Программное окружение (software environment) – набор программных
средств, необходимых и достаточных для выполнения установленным ПО своих
функций.
Чаще всего сюда относятся
- runtimes
- frameworks
- libraries and services from dependencies
- database software
- event brokers
- update services

3.

1.2 Среда разработки программного обеспечения (SDE, software
development environment) – это набор аппаратных и программных ресурсов и
инструментов, которые разработчик использует для создания программных
средств.
1.3 Среда разработки (development environment) – это программное
окружение на локальном или удалённом (Desktop as a Service) рабочем месте
разработчика.
1.4 Среда тестирования (test environments) – программное окружение,
используемое
для manual и / или automated testing.
1.5 Интегрированная среда разработки (IDE) – программное окружение,
используемое разработчиками для интеграции своего кода в общий проект, в
том числе для обеспечения code review.

4.

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

5.

Dartmouth BASIC был первым языком, который был создан с ИСР, и был
также первым, который был разработан для использования в консоли или
терминале. Эта ИСР (часть Dartmouth Time Sharing System) управлялась при
помощи команд, поэтому существенно отличалась от более поздних,
управляемых с помощью меню и горячих клавиш, и тем более графических ИСР,
распространённых в XXI веке. Однако она позволяла править исходный код,
управлять файлами, компилировать, отлаживать и выполнять программы
способом, принципиально подобным современным ИСР. Одной из первых ИСР с
возможностью подключения плагинов была Softbench.

6.

Интегрированная среда включает все необходимое для написания:
• редактор синтаксиса – (а часто и подсветкой ошибок синтаксиса и
большим количеством подсказок, главное уметь читать) конкретного языка
программирования. Здесь и создается программный код;
• компилятор – отвечает за трансляцию программы, переводит написанную
на приближенном к человеческом языку код в символы, понятные
компьютеру, машинный код. Язык С++ относится языкам компиляции,
поэтому для того, чтобы обработать текст программы необходим
компилятор, зачастую вместо компилятора используется интерпретатор;
• отладчик – является инструментом для отладки написанной программы.
Известно, что ошибки в программах допускают все поголовно: от
синтаксических (как правило, еще на стадии компиляции они должны быть
выявлены) и, что гораздо важнее, логическими. Выявить и устранить
последний тип ошибок помогает отладчик программ.

7.

Как правило, для того, чтобы успешно выполнить написанную программу на
С++, надо пройти благополучно преодолеть шесть этапов:
– редактирование;
– предварительная (препроцессорная) обработка;
– компоновка;
– компиляция;
– загрузка;
И в итоге, выполнение.
Редактирование выполняется посредством редактора программ, который, по
сути, является самым обычным редактором текстовых файлов, такой как
блокнот, word, но встроенный в ту или иную среду программирования.
Программист создает в этом редакторе свою программу на С++ и, по мере
необходимости, вносит в нее различные поправки, корректировки.
Имена файлов программ на С++ имеют расширения *.с или *.срр. Код для
просмотра можно открыть обычным текстовым редактором.
Остальные этапы выполняются без непосредственного участия человека.

8.

2 Проектирование и оздание интегрированной среды
разработки IDE
2.1 Необходимость спроектирования проекта
Зачем необходимо спроектировать проект?
– чтобы заранее продумать проект, его структуру и не допустить
критических ошибок еще на ранних стадиях;
– чтобы видеть весь объем работы и не делать в будущем больше чем
задумано (так умирают интересные проекты)
– чтобы проект был согласованным.
Проектирование не обязательно имеет письменную форму.
Все программисты проектируют код в мыслях по мере его написания. Таким
образом, они проектируют на низком уровне. Чтобы упростить и улучшить
низкоуровневое
проектирование
надо
подготовить
почву
—
высокоуровневую часть.

9.

Этапы проектирования:
– определение цели;
– выработка требований;
– определение архитектуры;
– написание высокоуровневого проекта.
Каждый следующий этап опирается на результаты предыдущего и уточняет
их.
Цель проектирования:
– научиться проектировать и разрабатывать сложные проекты;
– спроектировать и разработать IDE для вэб-разработки.

10.

2.2 Проектирование IDE
Требования:
2.2.1. Общие:
– кроссплатформенность (+ использование нативного интерфейса в
каждой из выбранных операционных систем);
– мультиязычность;
– расширяемость.
2.2.2. Редактор
– подсветка синтаксиса (+ указание ошибок синтаксиса);
– всплывающие подсказки при наведении на сущности в коде;
– автоматическое дополнение кода (Code Completion);
– сниппеты;
– работа с несколькими документами одновременно.

11.

2.2.3. Поддерживаемые языки программирования/разметки
2.2.4. Архитектура
Очень интересная часть проектирования. По ее оформлению нет
четких требований. Очень часто она содержит различные диаграммы.
2.2.4.1 Язык программирования: Например C#
Среда исполнения: Например .net (Windows), mono (Mac OS X, *nix)
2.2.4.2 Целевые платформы:
Mac OS X (начиная с версии 10.5.0)
*nix (следует уточнить список дистрибьютивов в будущем)
Windows (начиная с версии 2000)
2.2.4.3 Распространение:
Mac OS X — dmg
*nix — в пакетах, специфичных для каждого дистрибьютива
Windows — в виде инсталлятора

12.

2.2.5 Структура проекта:
2.2.5.1 Редактор
– подсветчик синтаксиса (с легко расширяемым списком языков);
– анализаторы структуры документа: HTML, CSS, JavaScript;
– менеджер сниппетов.
2.2.5.2 Среда
– менеджер настроек;
– менеджер горячих клавиш;
– менеджер интерфейса;
– панели инструментов;
–области данных (файловая структура, объектная модель
документа, ...).

13.

2.2.5.3 Расширяемость
расширения в виде полноценных библиотек;
расширения в виде скриптов на JavaScript.
2.2.5.3 Интерфейс
Реализации
WinForms (Windows);
Gtk# (*nix);
Cocoa# (Mac OS X).
Вот такой вот получился первый шаг в проектировании. Дальше будет
намного более сложный этап — составление высокоуровневого проекта.

14.

2.2 Создание IDE
Первым этапом создания IDE является определение, каков минимальный
набор функций, необходимых для IDE.
Основные функции IDE:
– редактирование файлы исходного кода;
– компиляция/интерпретация;
– результаты компиляции.
После этого дополнительные функции являются бонусом:
− Подсветка синтаксиса цветом;
− Помощь и документация;
− Файловый менеджер проекта;
− Многофайловая сборка;
− Отладчик (очень сложно);
− Поддержка плагинов.

15.

3 Пример создания простой IDE на языке Python
Первым этапом создания IDE является создание текстого редактора с
модулем Tkinter, который поставляется с Python Он будет иметь
следующие особенности:
− Открытые текстовые файлы.
− Редактировать текстовые файлы.
− Сохраняйте текстовые файлы.
− Открыть с помощью (наш редактор)
Для подключения библиотеки Tkinter:

16.

Для того чтобы добавить возможность открывать и сохранять файлы,
нам нужно диалоговое окно. Для этого в Tkinter есть свои функции.
Импортируем их:
Резултат создания тестого редактора:

17.

Для действия с файлами (открыть, сохранить, сохранить как, выйти):

18.

Для запуска и компиляции кода:

19.

4 Создание IDE со встроенным дизайнером интерфейсов на
PHP и ExtJS
В данном разделе рассматриваются концепты создания IDE и дизайнера
интерфейсов с использованием ExtJS и PHP. С одной стороны, создание
подобных редакторов довольно редкая задача, с другой — концепты и
приемы можно использовать для создания различных визуальных
конфигураторов.

20.

Из чего будет состоять IDE:
1 обертка для ExtJS, которая “умеет” генерировать код компонент;
2 файл проекта с простым API добавления элементов обертки ExtJS;
3 сборщик кода, который располагает элементы и кэширует результат;
4 дизайнер интерфейсов для упрощения настройки проекта, редактор кода;
5 “плюшки” в виде готовых компонент для автоматизации рутинных задач:
5.1 неочевидные особенности наследования в ExtJs для начинающих;
5.2 доопределение редакторов;
5.3 формирование url для Ajax-запросов за два клика;
5.4 импорт структуры из базы данных, автоматическое создание форм;
5.5 подключение внешних файлов и проектов;
5.6 локализация интерфейсов;
5.7 редакторы событий и методов;
6 бекенд дизайнера, который транслирует запросы фронтенда в команды
API работы с проектом;
8 генератор проектов.

21.

4.1 Обертка
Под эту задачу придется писать собственную обертку для ExtJS,
адаптированную под нужды задумки. Поскольку объем библиотеки
достаточной большой, сэкономим время отделив наборы свойств компонент
библиотеки от описания их поведения. Не все объекты ExtJs будут зеркально
отражены в коде PHP. Опишем классы ограниченного количества объектов
таких, как Grid, Store, Window и т.п. Все остальные объекты могут физически
не существовать в коде, а создаваться на основе набора свойств описанных в
иерархии.
Таким образом была воссоздана иерархия свойств компонент ExtJS. Далее
можно было по мере необходимости описывать поведение нужных
компонент, основные генерировали на уровне json-конфига.

22.

Получаем иерархию следующего вида

23.

Ext_Object и его наследники отвечают за поведение компонента;
Ext_Config отвечает за хранение, валидацию и сериализацию свойств;
Ext_Property и его наследники отвечают за описание характеристик конкретного
компонента ExtJS (классы с публичными свойствами, в какой-то мере
повторяющие иерархию библиотеки ExtJs).
Ext_Virtual — класс. Объекты этого класса создаются фабрикой в том случае,
если нет прямого наследника Ext_Object, описывающего поведение компонента.
Создается на основе описания свойств Ext_Property_xxx. Отличается тем, что
принимает имя класса для эмуляции, используя имя представляется
компонентам библиотеки.
Ext_Object реализует метод __toString, возвращающий ExtJS код компонента.
При необходимости этот метод можно переопределить в наследниках. Если
объекты вложены друг в друга, в момент приведения к строке корневого
объекта вся цепочка с легкостью самораспакуется (превратится в строку Js-кода).

24.

4.2 Файл проекта
Интерфейс на ExtJS состоит из компонент, выстроенных в цепочку и
расположенных в Layout.
Необходимо как-то хранить настройки связей компонент проекта. В качестве
конфигурационного файла можно использовать XML или какой-то другой
похожий формат.
В таком случае каждый раз при загрузке проекта придется анализировать
конфигурацию и инициализировать объекты, что может занять
продолжительное время. Нужен простой, быстрый и легкий формат.
Что если объявить класс Designer_Project, который бы представлял сам
проект и имел простенький API по добавлению элементов, а сами элементы
хранил в древовидной структуре (внутри лежал бы объект работающий с
древовидной структурой).

25.

На тот момент был уже написан класс Tree, который достаточно шустро
работал с древовидными структурами, без труда справлялся с иерархией до
25 000 — 30 000 вложенных элементов менее чем за секунду.
Объект такого проекта можно сериализовать и сохранить на диск. Более
того, от сериализованной строки можно взять хэш и пересобрать код
интерфейса только при наличии изменений. Повторная инициализация
интерфейса могла бы использовать файловый кэш, не прогружая проект для
валидации.
Основная проблема Ext Designer на то время представлялась в том,
что при каждом изменении кода нужно пересобрать приложение и
публиковать скрипты.

26.

Структура Designer_Project (файл проекта):
— системное описание контейнеров (какие классы можно перемещать,
какие могут содержать вложенные элементы и т.д);
— настройки текущего проекта (название, неймспейсы, подключенные
файлы и прочее);
— API (набор методов для работы с проектом);
— Tree (дерево элементов, структура проекта).
Примечательно, что классы компонент могут расширяться, а список свойств
— увеличиваться. Все это в большинстве случаев не вызывает проблем
совместимости со старым форматом.

27.

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

28.

4.3 Сборщик кода
Поскольку класс Designer_Project представляет собой контейнер с
простым API и совершенно не знает, что делать со своим содержимым,
потребуется вспомогательный механизм, который умеет правильно
располагать код элементов в нужной последовательности — это класс
Designer_Project_Code. Пожалуй самый сложный компонент по количеству
различных условий и ветвлений. Получая на вход объект проекта должен
вернуть JS-код для интерфейса. Рекурсивно проходя дерево проекта
получает код компонент и располагает элементы в нужной
последовательности. Важно отметить, что непосредственно код
компонента выдает обертка для ExtJS, сам сборщик занимается
расположением этого кода в нужной последовательности. Он должен
определить, какие компоненты должны быть объявлены первыми,
получить их код и вставить ссылки в зависимые компоненты.

29.

Код получился достаточно сложный и запутанный, много раз рефакторился,
с появлением новых возможностей становился еще более запутанным.
Со временем он приобрел терпимый вид и структуру.
Designer/Project/Code.php
Для объектов JS, являющихся расширениями базовых компонент ExtJS,
был использован трюк для упрощения расположения вложенных элементов.
Было создано свойство childObjects, представляющее собой список всех
вложенных элементов, таким образом к ним очень легко обращаться и
линковать в items.
Принцип работы Designer_Project_Code в рекурсивном обходе структуры
проекта, поиске связанных компонент и правильном расположении кода
конечных элементов относительно друг друга.
Пол дела сделано. Создан упрощенный аналог обертки PHP-EXT,
умеющий складываться в проект и работающий намного шустрее.
Функционал ограничен, но никто не мешает его развивать.

30.

4.4 Дизайнер
Пришло время для самого интересного — создания дизайнера интерфейсов.
Концептуально он должен представлять собой:
— панель с тулбаром, в котором бы располагался список компонент, которые
можно разместить в проекте (кнопки, формы, окна, панели);
— основную форму, которая бы отображала результаты рендеринга проекта;
— иерархию компонент (использован TreePanel);
— редактор свойств (Property Grid).
На текущий момент дизайнер имеет следующий вид (сильно отличается от
первого):

31.

32.

1. панель настроек проекта (загрузка, сохранение, переключение режима
дизайнер/редактор кода и прочее);
2. тулбар со списком компонент, которые можно добавить в проект;
3. панель, отображающая структуру проекта, поддерживает Drag & Drop
перемещение элементов, при выборе элемента для него подгружается
индивидуальная панель настройки свойств;
4. панель настройки свойств компонента (содержит дополнительные
панели редактирования событий и методов).
5. центральная панель (отображает результат рендеринга проекта, на этом
скриншоте — редактор локализаций). При загрузке проекта сервер
сохраняет копию его объекта в сессию, все манипуляции производит с ней.
Таким образом, если упал интерфейс можно перезагрузить окно,
изменения не будут потеряны. Кнопка “Сохранить” сбрасывает проект на
диск.

33.

После внесения изменений интерфейс отправляет запрос на сервер,
нужный контроллер принимает запрос, вносит изменения в объект
Designer_Project. После успешного применения изменений дизайнер
запрашивает перестроение JS.
Основная панель дизайнера, которая отвечает за расположение
элементов в проекте представляет собой дерево с поддержкой drag &
drop:

34.

Дерево запрашивает список элементов у сервера, тот, в свою очередь,
извлекает структуру из проекта при помощи API. Во время перетаскивания
элемента отправляется запрос на сервер с инструкцией, какой компонент
перемещаем. API Designer_Project содержит метод перемещения элементов по
дереву. При клике по узлу дерева (выборе нужного объекта) инициируется
событие itemSelected, отображается панель свойств этого компонента.
Взаимодействие компонент редактора происходит на уровне событий,
отдельные части и компоненты за частую не имеют представления о том, что
находится снаружи. У каждого элемента определен набор генерируемых
событий, на которые обычно подписывается родительский компонент.
В качестве редактора свойств использован расширенный компонент
Property Grid, дополненный методами общения с сервером (запрашивает
список полей, отправляет изменение свойств, инициирует события).

35.

В нашем случае этот компонент назывался designer.properties.Panel

36.

Одной панелью свойств не обойтись, в некоторых случаях требуется
возможность дополнительной настройки свойств, представляющих собой
редакторы и окна. При необходимости расширения списка настроек для
этого
типа
объектов
назначается
индивидуальный
редактор,
отнаследованный от designer.properties.Panel.
Первоначальными возможностями дизайнера не получилось решить все
задачи, поэтому к проекту был привязан файл “actionJs” (файл с кодом
JavaScript, используется для того, что нельзя сделать стандартными
средствами, подключается после JS-проекта).
В качестве редактора кода используется codemirror.net.

37.

Как отобразить результат? Можно рендерить проекты прямо в DOM
открытой страницы, это очень быстро, лаги перестроения практически
незаметны, после перекидывания элемента по дереву проходят доли
секунды, прежде чем интерфейс перестроится. У этого решения есть одна
серьезная проблема, если что-то идет не так в разрабатываемом проекте
(неверно задано свойство или еще что), ошибки JS вызовут обрушение
всего дизайнера. Разрабатываемый интерфейс лучше перенести в iframe
это хоть и замедлит отклик, но обрушение кода проекта не приведет к
глобальному краху. Сам iframe можно положить в центральную панель,
при необходимости запрашивать обновление содержания.

38.

4.5 Плюшки в виде готовых компонент, автоматизации рутинных
задач
4.5.1 Неочевидные особенности наследования в ExtJs для начинающих
Прежде чем коснуться темы доработки компонент, хотелось бы обратить
внимание на неочевидные для новичка особенности наследования.

39.

40.

4.5.2 Редакторы
Переопределим редакторы базовых свойств, например, редактор store
заменяем с текстового поля на выпадающий список всех созданных в
проекте хранилищ (запрашиваются у сервера, отдаются Designer_Project
API), так же и с другими подобными свойствами (layout, align и многими
др.).

41.

4.5.3 Формирование url для Ajax-запросов за два клика
Url в системе динамические, например, адрес панели может измениться,
контроллер переключиться. Для этого были придуманы токены, заменяющие
реальный путь, обрабатываемые на этапе сборки кода.
Для упрощения назначения url-адресов (ajax-запросы, proxy url) написан
компонент, который анализирует файловую и кодовую структуру. Reflection
позволяет получать и анализировать список доступных действий для
контроллеров, теперь их не нужно писать руками, просто ткнуть мышкой.
Принцип работы: сканируется файловая система, выбирается нужный
класс, запрашивается список методов, комментарий к методу используется в
качестве описания для интерфейса. Нужный url автоматически прописывается
в свойстве в виде шаблона.

42.

43.

Подобный подход можно использовать и для назначения иконок.

44.

4.5.4 Импорт структуры из базы данных, автоматическое создание форм
Как еще облегчить жизнь программисту? Конечно же импортом полей в
формы, хранилища, таблицы исходя из структуры БД или ORM.
Выбираем таблицу / объект, из которого мы хотим импортировать поля.
Исходя из его структуры и типов данных система автоматически подставляет
нам нужные значения в ячейки и заполняет иерархию форм.
Например, для int подставляется Ext.form.field.Number, для varchar —
Ext.form.field.Text и т.д.
Попутно добавляется fieldLabel, если это поле формы или формат даты, если
это поле хранилища и др. свойства.
Теперь нудная процедура описания элементов занимает пару кликов.

45.

46.

3.5.5 Подключение внешних файлов и проектов
Почему бы не дать возможность подключать в проект внешние JS-файлы и
другие проекты. Мы можем создать проект, в котором опишем специфический
компонент — редактор, позже подключим его там, где он нужен. Главное —
разделить пространства имен проектов так, чтобы генератор кода располагал
каждый проект в своем namespace, это не представляет особой сложности.

47.

Все что потребовалось — добавить в Designer_Project api поддержку
добавления списка файлов и проектов, назначение неймспейсов.
Designer_Project_Code за пару часов был обучен раскладывать код внутрь
неймспейсов и рекурсивно рендерить проекты.
Постепенно дизайнер начал пополняться готовыми компонентами такими,
как окна редактирования, фильтры, поля для ссылок на объекты, списков
объектов и многое другое.

48.

4.5.6 Локализация интерфейсов
Весь проект строился на простых решениях, не хотелось городить огород,
да и времени на это особо не было. В один момент оно нашлось.
Сама платформа использовала файлы локализации, которые
перегенерировались
при
изменении
в
интерфейсе
управления
локализациями. В итоге на странице существовал некий JS-объект вида:

49.

Идея проста — разрешить разработчику вводить в качестве значений
строковых свойств Js-код, для этого был выдуман токен “[js:]” (во время
генерации кода свойства с таким токеном оформлялись как js-код).
Было:
Стало возможным:
С учетом того, что интерфейс управления локализациями был уже готов,
работать с ним было одно удовольствие. Реализация решения заняла от силы
20 минут. Теперь можно локализовать проект не изменяя содержимое файла.

50.

4.6 Бэкенд
C точки зрения бэкенда все достаточно просто, можно использовать
любой фреймворк. Нужен набор контроллеров и действий для манипуляций с
проектом. Запускаем приложение, загружаем проект дизайнера, описываем
список методов, которые обращаются к API Designer_Project и выполняют
различные манипуляции с проектом. Из особенностей — понадобится
контроллер, который может вывести собранный проект в интерфейс и
подключить нужные JS-файлы.
В нашем случае в дополнение был создан action для сборки и
минификации исходного кода самого дизайнера, это позволило ускорить
загрузку редактора.

51.

4.7 Генератор проектов
Генератор представляет собой шаблон с набором действий над файлом
проекта.
В упрощенном виде:

52.

Имея подобную структуру проекта написать генератор проектов на основе
ORM не составило труда. За день было создано несколько шаблонов генерации
стандартных интерфейсов, теперь на создание типового интерфейса уходило
пара кликов, остальное время тратилось на нестандартное оформление и
доработку.
На реализацию первой версии дизайнера ушло 3 недели отпуска —
довольно короткий срок для такой глобальной цели.

53.

Полученный профит:
— стандартные интерфейсы генерировались одним кликом, далее дорабатывались в
дизайнере;
— значительно уменьшилось число ошибок в JS-коде;
— молодые разработчики легче вникали в ExtJS и разработку сложного проекта;
— дорабатывать интерфейс стало намного проще и интереснее, элементы
передвигались одним движением мыши, без боязни забыть захватить кусок кода и
упустить связанность с другим элементом;
— возросла скорость разработки продукта и прототипов;
— такие вещи, как поменять название кнопки или колонки, перестали вызывать
батхерт во время поиска куска кода с инициализацией нужного элемента;
— получен интересный опыт в разработке собственной среды разработки “на
коленке”.
— разработка на PHP приобрела совершенно новую удобную форму;
— удалось узнать много тонкостей ExtJS, c которыми не приходилось сталкиваться до
этого момента.

54.

Источники
1. https://habr.com/ru/post/39537/
2. https://habr.com/ru/post/224709/#7
3. https://www.sencha.com/products/extjs/#
4. https://ru.wikipedia.org/wiki/%D0%98%D0........
5. https://walmyrlimaesilv.medium.com/development-test-performance-stagingcanary-production-environments-a26c03509fa8
6. https://healthcareitskills.com/it-systems-architecture-software-environments/
7. https://habr.com/ru/post/490566/
8. https://tekeye.uk/programming/how-to-create-an-ide