[user[instance[project]]] с синхронизацией user - уровня
- user: настройки пользователя, самый базовый уровень, может синхронизироваться в облаке. Хранит параметры которые не будут меняться ни в зависимости от проекта ни от машины. Например, тема оформления, привязки клавиш.
- instance: настройки для конкретной рабочей машины. Например, количество ядер для сборки проекта, пути в файловой системе.
- project: настройки конкретного проекта. Например, toolchain для сборки.
Компилировать проект в фоне вместо индексирования, попутно используя возникающие ошибки для Intellisense, а при запуске просто достраивать код.
Новая ступень развития после многоядерной компиляции, только вместо нескольких логических процессоров, этот функционал распределяет нагрузку между несколькими компьютерами. При работе в команде над большим проектом, компиляцию можно очень сильно ускорить распределяя её по разным компьютерам в сети и работая коллективно. Таким образом чем больше команда, тем обычно больше и проект, но с таким функционалом это будет компенсироваться общими усилиями участников сети и чем больше компьюетров в сети, тем быстрее будет собираться проект. Вкупе с фоновой компиляцией после нажатия кнопки "Собрать", придется ждать только пока закончится линковка, каким бы сложным ни был проект (при корелляции с количеством машин). Также для некоторых случаев эта фича может полностью заменить системы CI (continious integration), если расширить её функционал, позволяя практически мгновенный deployment. Она будет локально кэшировать машинный код, при этом учитывая системы контроля версий, в частности, гит, привязывая скомпилированный код к коммитам (напр. последний коммит, затронувший этот файл). Сложности:
- Как указано выше: VCS
- Разные флаги компиляции. В случае если разработчик хочет локально собирать проект с кастомныим флагами, этот машинный код нельзя использовать как кэш для других. Стоит помимо коммита также ассоциировать машинный код с флагами, которыми он был собран.
- Разные компиляторы. Также решается ассоциированием. При этом разработчики должны быть в курсе что система не работает оптимально из-за того что не все пользуются одинаковым окружением
- Разное окружениею. У разработчика могут локально стоять другие версии библиотек и много чего другого. Это не решается ассоциативностью, но можно решить с помощью интеграции с docker-ом, (см. ниже). При использовании docker контейнера для создания окружения разработки, можно спокойно гарантировать идентичность окружений просто сопоставив id образов Таким образом пока что видение такое что эта фича может работать только при использовании docker контейнеров. В остальных ситуциях гарантировать идентичность и совместимость машинного кода, сгенерированного разными машинами довольно затруднительно.
Автоматически настраивать стиль кода на основе уже имеющегося. Можно выделить кусок кода указав его эталонным, либо работать в пластичном режиме, в котором автонастройка будет происходить на лету во время написания кода.
В специальном режиме отображения с помощью цвета отображать количество машинного кода, которое будет порождено данной строчкой, с учетом всех вложенностей и без.
Во время выполнения программы показывать граф вызовов ее функций и частоту вызова фунций в виде "температуры ребер". Возможность ставить точки останова на этом графе, которые сработают только при прохождении данного пути и с заданным состоянием стека (значения переменных), что можно использовать также в тестировании (см. дальше).
Подмена системных вызовов на свои собственные с предзаготовленным поведением для выявления того как программа поведет себя на различных edge-case-ах и ошибках. Подмена пользовательских вызовов для возможности изоляции модулей программы друг от друга.
Можно будет записывать различные аспекты внутренней активности программы из диаграммы активности кода. Например, результаты обращения к системным вызовам. Таким образом можно будет запоминать то какие данные пришли по сокету, какая кнопка была нажата в GUI, какие данные из файла считало приложение и т.д. А также можно будет фиксировать состояние самой программы в виде ключевых значений ключевых переменных, чтобы при воспроизведении ввода, воздействие было оказано на программу только по достижении ею нужного состояния. (Например, чтобы можно было послать нажатие кнопки только в том случае если приложение разрешает ее нажимать).
За счет фоновой компиляции система будет располагать актульным машинным кодом во время написания исходного кода. Система будет запускать этот код в виртуальной среде исполнения и анализировать это поведение на предмет корректности работы с памятью, исключениями, таким образом предвидя часть возможных сценариев аварийного завершения программы. Дамп внешних воздействий позволит более полно анализировать корректность программы, выполняя ее с записанными внешними воздействиями. Виртуальная среда исполнения даст возможность во время спекулятивного выполнения программы производить часть runtime анализа без запуска программ как такового прямо во время написания кода. Однако количество возможных комбинаций ошибок и edge-case-ов системных вызовов может быть очень велико для спекулятивного выполнения, поэтому полное покрытие всех случаев пока не представляется возможным.
Призвано радикально упростить тестирование ПО. За счет диаграммы активности кода можно знать когда, в какой последовательности и с какими значениями были вызваны функции, а за счет виртуальной среды исполнения можно запускать программу для тестирования анализируя то как она взаимодействует с ОС. Этот подход упразднит написание тестов как таковых и избавит от необходимости проектирования ПО под хорошую тестируемость. Вместо этого нужно будет предоставить дамп внешних воздействий (ввод) и ожидаемое поведение программы в виде последовательности системных вызовов, значений переменных на разных этапах выполнения (вывод).
Синергия спекулятивного выполнения программы, инъекционного тестирования, фоновой компиляции кода и виртуальной среды исполнения даст возможность производить тесты в фоне во время редактирования программы (если позволяет процессор).
За счет различнх правил и эвристик среда будет распознавать структуры данных (такие как различные деревья, списки) и представлять их пользователю в графическом виде во время отладки. Это позволит разгрузить мозг от интерпретирования неудобного представления подобных данных в современных IDE и сфокусироваться на самой структуре данных, ее содержимом и поведении.
Среда будет отображать как различные модули ПО свзяны между собой.
Возможность chroot-а в окружение docker контейнера. Интегрированный компилятор будет осуществлять поиск файлов и т.п. внутри указанного docker контейнера.
Помимо стандартного функционала, реализованного в некоторых IDE, возможности комментирования пулл реквестов при нахождении в соответствующей ветке. (Неизвестно, можно ли это вообще реализовать в рамках API github-а).
При отладке программы можно будет не останавливая ее производить поиск созданных объектов по различным критериям (в зависимости от языка) Например, для C++, можно будет осуществлять поиск по имени типа, адресу и фильтровать по состоянию объекта. Также можно будет добавить любое поле выбранного объекта для отслеживания во время выполнения программы. По сути данный функционал заменяет собой отладку редактированием кода, где для отслеживания нужных данных в программу добавляется временный код выводящий данные пользователю. Это должно работать как при исполнении программы локально так и удаленно, что должен обеспечить InteropFramework.
В процессе фоновой компиляции можно отслеживать где какие оптимизации применились к коду. Отображать это нужно в отдельном режиме.
Отображение мест вызова, объявления, определения, переопределения, перегрузки функций и методов. Отображение мест объявления, инициализации, использования, чтения и записи переменных. Каждый тип обращения обозначается своим, интуитивно понятным символом на скролл баре при установке курсора на символ. Показывать количество найденных обращений.
Возможность сортировать файлы по метаданным в отдельном настраиваемом виде (view).
Возможность отображать исходный код в стиле отличном от того что в файле без модификации стиля самого файла. Когда пишем в файл, определять его стиль кода и записывать в нем, когда читаем, наоборот, приводим к стилю пользователя. Если применить стиль невозможно (некорректный/не поддающийся по какой-либо причине анализу код) то отображать как есть.
Сопряженные трудности:
- Переход к строке по номеру: номер строки в виртуальном представлении и реальном файле с очень высокой вероятностью будут отличаться. Можно обрабатывать номер как реальный при переходе по ссылке из внутреннего терминала (т.к. утилиты будут ссылаться на реальный файл), а если пользователь вводит номер вручную, то давать ему выбор (по умолчаню в виртуальном пространстве).
- Если код не поддается анализу, мы не в состоянии ни определить его стиль ни применить его к нему. Либо отключать фичу полностью для файла либо пытаться отобразить части что не поддались анализу как есть.
Т.к. UI может быть отдельным node (см. ниже), открывается возможность коллективного редактирования путем одновременного подключения более одного UI к node среды.
Не стоит делать один большой индекс кода, он должен быть сгруппирован таким образом, чтобы для каждого файла была своя область видимости индекса (как узел в дереве). Назначение этого в том чтобы не делать поиск по всему индексу когда ясно что до некоторых файлов мы просто не доберемся из текущего никак. Если этого не сделать, то решение будет не масштабируемым и будет CLion, который тормозит на больших пусть даже хорошо внутренне изолированных кодовых базах.
Если среда завершит свою работу аварийно, сессия во встроенном терминале не должна умирать вместе с ней если у нее есть дочерний процесс. Для того чтобы это было возможно нужно чтобы терминал был выполнен в виде interop модуля что позволит запускать его как отдельный процесс и когда среда крашится делать detach и оставлять как standalone терминал с сессией.
Это даст возможность исполнять среду на удаленной машине, в то время как интерфейс будет работать локально как обычный процесс. Можно будет отказаться от редактирования файлов в консоли по SSH. При этом интерфейс должен быть stateless, это позволит среде работать как сервис.