ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Пятница
19 июля
314357 Топик полностью
Evgeny_CD, Архитектор (13.03.2012 10:02, просмотров: 103) ответил =AlexD= на Я так понял, что Евгений как-раз и пытается оградить специалистов от изучения лишних сущностей. Одни рисуют картинки со стрелочками, другие пишут спецификации, третьи прорабатывают программный скелет по спецификациям и алгоритмам, четвёртые
Именно так. Единствно данных проекта и способов работы с ними при разделени труда и оптимизированном для каждой задачи инструментарием, сохраняющем это единство идеологии с общими данными. Да, така штука будет создаваться долго, и что, самое важное, модифицироваться постоянно. Девелопер системы девелопмента - самый первый член команды :) Идеология должна быть заточена на постоянное допиливание. Значит, в основе методологии проекта должны лежать очень простые сущности. Таблица ключ-значение может решить почти все задачи (возможно, не так эффективно, как "спецзаточки") - и тут важно что "все", а не "сколько памяти сожрет". Я ламер во взрослом программизме, но это и есть мой шанс. У меня мало стереотипов :) Мне кажется, что если продумать базовую основу в рамках како-то мощного ООП средства разработки, то достижение первых практических результатов не такая уж и неподъемная задача. Это я о Tcl :) На первом этапе все можно упростить и свести к записи на каждый символ каждого файла. 1м строк еще нагавноколить надо, а там и методологию выправить можно. Пока пусть будет "файл с исходником", но хитрый. Парсим его на слова, каменты - как одно большое слово без разбора. И делаем в БД записи такого вида * слово из файла * ссылка на запись с описанием смысла этого слова. * другие нужные ссылки * ссылка на предшествующее и последующее слова "Запись со смыслом" может принять такой вид: * ссылка на запись с именем тега * описание того, как этот тег используется. Записи с именами тегов уникальны. Ну и глобальная таблица по всем символами всех файлов - в какой записи относится та или иная буква. Тупо, в лоб, без всякого бинарного дерева и поисков внутри диапазона. Редактор придется писать свой, но если взять готовые заготовки, думаю, это не так и страшно. Редактор выдал запрос в БД "дай мне все записи от строки 20 до строки 50 файла fjf.c". Получил кучу записей, склеил слова, отрисовал текст. Подвел программер курсор к символу - через БД мы знаем, какие объекты на это завязаны. Поскольку иерархия в БД уже заведена, то тут же можно выдавать подсказки. Например, мы знанем глобальные теги и их классификацию (переменные, функци и пр). Мы знаем, что от сих до сих - это функция такая-то. И если "стоим в теле" - то нам доступны такие-то переменные. Выводим в отдельном окне сгруппироанные списки всего доступного - можно лишнее в голове не хранить. Отредактировал программер строку - комитим все в БД, какие записи там изменять мы знаем. В процессе поисходит парсинг строки на слова, теги и пр. Можно и вопрос программеру задать - что в качестве чего используется? Если его задать в виде удобного окна с горячими клавишами для ответов и списками выбора - ответ будет мгновенным. Склееные строки разбирать тоже не так и сложно - трактуем их как одну большую строку. Синтез файла из такой БД сведется к запросу в БД "объект по ссылке" и склейке строк, что, несмотря на все мое ламерство, кажется мне несложным упражнением на любом языке программирования. Описанная методолгия весьма неэффектина по памяти, 128Г на 10м строк не хватит. Но из еще написать нужно, а в процессе перманентного развития "БД" многое допилится. Зато для проектов до 1м строк ее можно сделать довольно быстро.