Evgeny_CD (29.06.2007 19:11, просмотров: 1) ответил Evgeny_CD на VMDL: Практическая методика работы с программными модулями. Версия 0.0.0.0
Использование VMDL при "прямой разработке" (от идеи к коду). Пишем мы коммуникационную прогу. Пусть она у нас состоит из нескольких функций. Создаем два файла и пишем:
pkt.h - пока пустой
pkt.c
<c>
#include pkt.h
void pkt_receive {
}
void pkt_send {
}
void pkt_split {
}
void pkt_compose {
}
</c>
Редактируем файлы, давим Ctl-S.
Запускаем описанную ранее супермегагипертулзу. Говорим ей, что в проекте два файла - pkt.h и pkt.c.
В нашем любимом редакторе подводим курсор к первой букве определения функции в pkt.c и жмем батон "зарегистрировать функцию". Редактор запускает внешний скрипт, которому передает в качестве параметров командной строки:
* имя файла
* номер строки
* слово до первого разделителя, следующее за курсором.
Эта скрипт запускает супермегагипер тулзу, которая всасывает переданное слово (и проверяет, что оно на месте в файле), и предлагает нам отклассифицировать его - что это функция, определение функции. Даллее хоткей - найти прототип. Тулза шарит по доступным хидерам и говорит, что нашла. Если ничего на нашла - выбирает подходящий хидер, и говорит - сделать заготовку прототипа? Делаем заготовку. Выходим из тулзы. Она правит нам файлы, и мы получаем следующее:
pkt.h
<c>
// pkt_receive (); /** EDFEAE55-02 **/
</c>
pkt.c
<c>
#include pkt.h
void pkt_receive { /** EDFEAE55-01 **/
}
void pkt_send {
}
void pkt_split {
}
void pkt_compose {
}
</c>
Если ваш любимый редактор не осилит написание такого сложного скрипта, или не отследит изменение файлов на лиске - выкиньте его и возьмите другой.
Идем в файл хидеров, и доводим его до ума
pkt.h
<c>
void pkt_receive (void); /** EDFEAE55-02 **/
</c>
Повторяем аналогично для всех функций. Если наделать хоткеев, то все будет пороисходить очень быстро.
Можно и сразу наделать прототипов самому, тогда тулза только припишет идентификаторы.
Теперпь добавим функцию, которая делат нечто осмысленное с нашим пакетом
pkt.c
<c>
#include pkt.h
void pkt_receive { /** EDFEAE55-01 **/
}
void pkt_send { /** 1DFEAE55-01 **/
}
void pkt_split { /** 2DFEAE55-01 **/
}
void pkt_compose { /** 3DFEAE55-01 **/
}
void pkt_process { /** 4DFEAE55-01 **/
}
</c>
Обработаем ее. Настало время придать программе чуток смысла
pkt.c
<c>
#include pkt.h
void pkt_receive { /** EDFEAE55-01 **/
}
void pkt_send { /** 1DFEAE55-01 **/
}
void pkt_split { /** 2DFEAE55-01 **/
}
void pkt_compose { /** 3DFEAE55-01 **/
}
void pkt_process { /** 4DFEAE55-01 **/
pkt_receive(); /** EDFEAE55-03 **/
pkt_split(); /** 2DFEAE55-03 **/
// тут будет жить некий осмысленный код
pkt_compose(); /** 3DFEAE55-03 **/
pkt_send(); /** 1DFEAE55-03 **/
}
</c>
Как читатель догадался, никто через copy/paste названия функций не вставляет. И не печатает их. Жмем батон - вставить имя. Тулза, она смотрит хидер, и предлагает список, чего вставить можно. Выбор. Батон. Редактор прочитал stdout и ввел принятый string туда, где был курсор.
Идентификаторы серии -03 были добавлены тулзой, когда из редактора мы запустили макрос "пометить использование функции".
Зашибись! У нас в БД информация о всех функциях проекта и их прототипах! Самое время нарисовать граф вызовов нашего мегапроекта. Информация для него тоже есть в БД!!! Даем команду, и питоновский скрипт рожает dot файл, который компилится Graphviz в картинку, которая открывается на втором мониторе. Внимательно изучаем картинку :)
Теперь переходим к созданию данных, которые наша програ обрабатывает.
Далее, думаю, понятно.
В перерывах мы начинаем писать краткие заметки к функциям. К данным. Ко всему, что хотим пометить!!!!!! Они живут в БД.
!Ключевой идеей является то, что вся "левая" информация хранится отдельно от кода, и не загромождает его. Площадь поверхности экрана используется экономно, ибо даже "засеренные" каменты доксижена съедали бы ее, что приводило бы к допонительному беганию глазами и скроллингу. Всякие автофолдинги тоже до добра могут и не довести.
В процессе работы удобнее всего будет работать с SQL серваком. Потом, по завершению проекта, из базы рожается .vmdl файл (суть XML), где все это описывается.
При подключении модуля к проекту файл всасывется. Поддерживается иерархия - тулза обходит дерево и всасывает все найденные файлы.
В процессе работы в паузах запускаем проверочную тулзу, которая проверяет, что в БД нет противоречий с кодом.
Резюме:
* предоженная технология совместима с любым редактором, который может запустить приложение командной строки и обменяться с ним данными через стандартные потоки (которые это не умеют - они еще живы?)
* в силу того, что мы не ограниченны убогими возможностями макроязыка редактора, мы можем писать обработку на хорошем языке, например, питоне
* все "сущности" мы обрабатываем через SQL базу, их все можно закешировать в память, так что на машине с гигом памяти все описанное будет просто летать.
Вот. Теперь осталось только написать эту тулзу.
Я ХОЧУ ТАКУЮ ТУЛЗУ!!! А Вы?
Пиплы, кто работал с питоном, SQL, и wxwidgets.org? Дал бы мне кто заготовок на тему, я бы хоть начал предметно разбираться со всей этой байдой...
)
)