Средства и методы разработки

VMDL: Практическая методика работы с программными модулями. Версия 0.0.0.0 Берем программный модуль. Дир, внутри куча файлов и диров. Разбираемся с конфигурацией. Нас интересуют те параметры, которые меняют состав файлов для компиляции модуля. Выбираем нужную конфигурацию для выбранных хостов и таргетов. Генерим список файлов, участвующих в компиляции. Вопрос: какой тузлой это можно сделать??? Берем этот список и натравливам на него Ctags. http://mb9x.ginps.com/tools/ctags.html http://ctags.sourceforge.net Выход засовываем в SQL базу сриптом и начинаем работать. Обрабатываем все вхождения сущностей в наши файлы сриптом: * что это за хрень - функция, макрос, переменная, typedef и пр. * где она -- определена -- прототипирована -- используется ==== на запись ==== на чтение Перво-наперво, отпределяем все внешние сущности: * функции, которые используют, но для них нет определений * переменные, от которых есть прототипы, но нет места их создания * typedef, которых нет среди файлов проекта Запускаем некую тулзу. Она представляет интерефейс в виде иерархического list box для всех наших сущностей. Выбираем внешнюю функцию, ходим тулзой по месту ее вклюения в файлы проекта, убеждаемся, что это она. Ставим в тулзе метку. Отдельно анализируем вызовы ОСи, чтобы понять, с какими параметрами рождаются всякие системные сущности - threads, mail boxes, mutex, светофоры и пр. Ставим метки в тулзе. Если у нас есть описание модуля, и там казано, какие у него точки входа - ищем все это хозяйство в тулзе, идем к коду, и ставим метки. Если описания нет - включем мозги и пытаемся понять, что к чему. Все, первичный анализ закончен. У нас есть список тегов с атрибатуми в БД с идентификаторами вхождения в виде файл:line. Если начать редактировать исходники, то все ссылки отъедут. Чтобы этого не произошло, тулза по команде ставит в коде метки типа /** AFDECA23-78, AFD3CA23-F8 **/ Метки ставятся на той же строке, к какой относятся! AFDECA23 - ID сущности -78 - метод ее использования в данном месте. через запятую - другая сущность и т.д. По /** и **/ такие коменты будет легко расцветить в редакторе удобным образом. После правок индексные файлы строятся уже с учетом таких тегов. Понятно, что отражаем в (CVS|SVN|bazaar-vcs.org) любые правки исходников, равно как и прочих файлов проекта. На этом этапе у нас все готово, чтобы автоматически нарисовать граф внешних сущностей проекта. Это проще всего сделать при помощи graphviz.org используюя интерфейс к питону yapgvb.sourceforge.net. Один раз разобраться, наплодить классов, а затем быстро рисовать графы нужной красоты. Все, строго говоря, если автор модуля таким образом обрабатывает его исходники, то приложив к модулю * файл разметки * рисунок графа * _короткое_ текстовое описание он даст стороним разработчикам мощнейший инструмент для работы со своим модулем. Писать в качестве документации нужно будет очень мало! При необходимости можно продолжить копание во внутренностях модуля по описанному вышы алгоритму и построение внутренних графов. Есть еще и обратная задача. Стоя в редакторе, выделяем сущность и жмем батон Классифицировать! В открывшемся меню быстренько хоткеями описываем, что это за хрень. Макрос редактора ставит тег и заносит инфу в БД модуля. Не изобратаю ли я doxygen? Нет! doxygen не дает интеграцию с редакторами. У него нет категории "внешние сущности". Да, вероятно, его данные можно использовать, но, IMHO, описанный выше алгоритм довольно примитивен, можно и самому написть тулзу для него. Таким образом, ключевыми вещами становятся: * файл описания проекта * тулза для работы с этим файлом Для работы над проектом по описанной технологии надо: * SQL какой-нибудь (чтобы быстрее работало). Хотя бы sqlite.org В идеале найти полностью питоновскую БД. * Python * гуй, например wxwidgets.org. Говорят, оно портабильно, как Tc, но красивше и удобнее. * graphviz * тулза для генерации зависимостей файлов * вменяемый редктор с хорошей командной строкой и мощной системой макросов. Главное, чтобы из макроса я мог подключиться к внешней БД. На мой вгляд, альтернативы scite.ruteam.ru просто нет по причине возможности написания макросов на нормальном языке LUA. Но могут быть и другие варианты. Чем предлагаемое мной отличается от просто продвинутого редактора? Здесь описана надстройка, которая работает напрямую с пространством имен модуля врамках всегопроекта. Она * не завязана на редактор напрямую * можно использовать одновременно с кучей редакторов, например: -- кодить в своем любимом -- отлаживать в VC -- компилировать в кросс вариенте под Eclipce - авось не глюкнет * позволит делать очень удобную иерархическую систему поиска сущностей * очень легко расширяется, ибо проста и понятна, будет содержать небольшое число питоновских скриптом, и использующий тулзу сможет легко подстроить ее под себя. Например, можно ввести поля - написан ли тест юнит, результаты прогона и пр. По сути, в базе будет отражаться история _каждого_ тега проекта! !!! Вообще в базе можно приписать любую информацию к тегу - заметку, например. Если делать это по технологии doxygen, то это загромождение кода. А так оно будет жить в отдельном месте и не мешать. Система не зависима от языка программирования. Стиль изложения отражает С-центричное мышление автора, но язык может быть любым. Технологию можно использовать для написания ТЗ, а затем для автоматического контроля кода на формальное соответствие ТЗ. Она также сильно поможет написанию тестов. ВСЕ!!! Парни, я наконец-то сформулировал то, что мучало меня года три. УРА!!! Теперь осталось найти единомышленников, чтобы они помогли мне создать такое. Чукча неплохой аналитик и архитектор, но хреновый кодер - надо честно признаться... ЧТО ЭТО ДАСТ? 1. Эффективный способ быстро разбираться с чужими исходниками. Можно брать довольно сложные куски из GPL | BSD проектов и втаскивать их себе. 2. Сильное упрощение коммуникаций между участниками при распределенной разработке. Формализация отношений при аутсорсинге. 3. Уменьшение затрат времени на превращение кода в товарный продукт. Написал человек модуль. Писать доку ему лень, а при помощи такой технологии он быстро превратит код в юзабельный продукт. Код надо писать так, чтобы он был очевиден для другого человека. Комментариев должно быть мало. Курим первоисточник http://www.llnl.go …slurm/coding_style.pdf Нужно описать конфигурирование и _неочевидные_ тонкости вызова точек входа модуля. 4. Развитие рынка ПО. Можно будет сделать сервак, и всякий желающий мождет поместить код на продажу. Выкладывает дескрипторные файлы, бинарники либ на пробу. Дескрпитор по описанной технологии достаточен для глубокого понимания кода пректа. Для того, чтобы все это было, нужно стандартизовать формат описания. Вероятнее всего, это стоит сделать через XML + DTD, чтобы не изобретать велосипед. Уж если совсем развивать идею, то можно еще сделать систему трансформации кода под хосты и тагргеты. Это развитие идей, заложенных в eCos. Т.е. есть некий протокод, он прогоняется через срипт, который делает из него с, модифицируя протокод под особенности хоста и таргета - атрибуты всякие там, прологи и эпилоги прерываний, __FLASH__, __EEPROM__ и пр. Это близко к идее DOM - Document Object Model. Пишем в некоей идеализированное модели С, с кучей атрибутов, а звтем все это компилим в целевой С, который и отлаживаем. Ладно, это темя для большой статьи, когда-нибудь я ее напишу. P.S. VMDL - Visual Module Description Language. vmdl.org я уже зарегистрировал :))))