Как создавался НАВИГАТОР.CD

У Заказчика по проекту было только желание, и, конечно, деньги. Все остальное ожидалось от подрядчика. Учитывая достаточно сжатые сроки, необходимо было очень четко распланировать работу и продумать все возможные риски.

Сутью проекта была разработка информационного компакт-диска с материалами юридической тематики, разбитыми на категории. На диске должны были быть размещены тексты законодательства, а по ним и по материалам должен был быть реализован полнотекстовый поиск.

После недолгих раздумий я согласился на проект. Его важнейшей особенностью являлось то, что ответственность по договору нес я лично, т.е. договор заключался между мною и "ЗАО Навигатор".

Сразу после начала работы оперативно была подобрана команда аутсорсных юристов, которых я тщательно искал и отбирал через основные сайты по подбору персонала. С каждым юристом я встречался лично и обговаривал условия работы. После того, как была собрана команда из 10 юристов, между ними были распределены полномочия и ответственность. Фактически, я работал с тремя юристами, остальные были под руководством этих трех.

По проекту был разработан детальный план. Программирование запущено было еще раньше, чем начался проект - я пачками генерил прототипы основных функциональных модулей для ответа на вопрос - сможем мы ли мы реализовать отдельные требования в принципе или придется в случае затруднений убеждать Заказчика в технической нереализуемости ожидаемого. Учитывая, что проект разрабатывался на Delphi, такое вполне могло произойти.

Тем не менее, основные моменты были проверены: взаимодействие с компонентом Microsoft Internet Explorer, изменение поведения стандартных компонент интерфейса, функционал поиска.

Первым прототипом была программа-браузер документов. Отличием ее от обычного браузера было то, что она выполняла прямое взаимодействие с файловой системой. То есть, у стандартного ActiveX-компонента отнимали функцию работы с файловой системой и добавляли собственную логику ее реализации. Это позволяло на этапе открытия документа, сначала провести его через логику программы (например, поставить его в рамки какого-нибудь шаблона), а уже потом - отдать на "съедение" ActiveX-компоненту, чтобы тот разумно прорендерил текст HTML в привычный нам вид.

Тестовая программа выявила основные недостатки такого подхода - невозможность загружать картинки. Дело в том, что интерфейс загрузки HTML-текста един, и инициируется он внешней по отношению к компоненту программой. То есть если браузеру потребуется картинка, он ее полезет искать привычными ему методами. Было бы много удобнее, если бы можно было переписать процедуру доставки файлов компоненту. Тогда бы через нее шли бы и картинки, и текст. А нет, не сделали так в Майкрософте. Ну или мы не нашли - вот что не знаю, то не знаю. Одно скажу - мало информации по этому поводу в интернете и в печатной литературе. Приятно хоть, Delphi тут особо не при чем - технология activeX более-менее универсальна.

Еще было вскрыто ряд проблем. Например, сложно убрать абсолютно все проявления Internet Explorer в компоненте для пользователя, или проблему с возвратом на шаг назад - Back. Поскольку подгрузка шла <извне>для компоненты, история документов была весьма далека от реальной. Да и много еще мелких других <проблемок>. Но, после того, как это было обсуждено с клиентом, было решено двигаться именно выбранной дорогой, потому как при всех ее недостатках, она была лучшей. Проблему с Back мы решили кардинально - написали собственный стек страниц и функционал движения по нему вперед-назад. Точнее, только назад - вперед просто не требовалось.

Несмотря на эти страния, что-то мы сразу не углядели - например, компонент Microsoft Internet Explorer по странным для нас причинам не хотел нормально (правильными шрифтами) печатать выделенный фрагмент страницы при выборе "Печать" из стандартного всплывающего меню, открывающегося по клику третьей кнопкой мыши на странице. Поданная из самой программы команда "печатать" компоненту отрабатывает нормально.

Также был представлен типовой текст, подготовленный первым же взятым в команду юристом - чтобы убедиться, правильно ли мы понимаем ожидания заказчика по качеству и полноте материала. Параллельно был подготовлен тематический структурированный рубрикатор на 13 страницах. Из него впоследствии день за днем пункты помечались как завершенные.

Чтобы убедиться, что ожидания по проекту у заказчика совпадают с нашими, первым этапом стало создание прототипа, в котором обозначались основные интерфейсы системы. Прототип оказался этаким "костяком", на который "навешивались" разработанные функциональные модули. Еженедельные встречи с заказчиками начинались с озвучивания планов с прошлой недели, демонстрации результатов и озвучивания планов на предстояющую неделю.

В проекте можно было выделить два наиболее сложных этапа - создание материалов и реализация полнотекстового поиска. Первый был сложен организационно, второй - технически. Разработка шла на тему, которую я не назвал бы близкой для себя и, соответственно, лично я не мог контроллировать качество разработки материалов. При этом все замечания по ним я получал от заказчиков, чтобы потом отчитаться о выполнении части работ. Мы должны были покрыть большую часть гражданского и уголовного права, так что знания, полученные при разработке предыдущих материалов никак не помогали для разработки последующих.

Процесс разработки программы разделился на четыре крупных этапа, идущих более или менее параллельно:

• работы по созданию оболочки,
• работы по написанию виртуальной файловой системы,
• работы по написанию поискового механизма,
• работы по написанию сервисного ПО.

Виртуальная файловая система по сути есть весьма сложный механизм, сделать который можно было лишь через месяц после начала работ. А многие другие этапы требовали наличия хотя бы какого-нибудь поставщика данных. Для того, чтобы их дважды не переписывать, пошли по этапу написания <заглушки>, снабженной тем же интерфейсом, который впоследствии будет у виртуальной ФС. Заглушка все запросы направляла в реальную файловую систему. В режиме отладки эта заглушка работала до самого конца, да и сейчас она выполняет второстепенную роль - если в виртуальной ФС данные не найдены, они ищутся через <заглушку>в классической ъ файловой системе.

Поисковый механизм было сложно написать в те сроки, которые поставлены клиентом. Потому даже в техническом задании поиск описывался в простом варианте, и было помечено, что работы по его созданию запланированы, но могут быть не закончены к концу проекта. В целом, один только поиск стоит писать 4 месяца - это достаточно сложный механизм, а тут он один из этапов. Вообщем, пришли к соглашению, что если поиск будет закончен ко времени сдачи проекта, и он будет устраивать в том виде, в каком мы сможем его сделать, то поиск будет интегрирован в проект, в противном случае мы его разрабатываем для интеграции в систему на более позднем этапе, возможно на стадии поддержки продукта, в следующую его версию.

Забегая вперед, скажу, что поиск мы все же сделали и в требуемом варианте, при этом управились в сроки. Поик имеет индексатор и систему поиска по индексам. Что не смогли сделать в рамках проекта - так это сделать универсальный модуль поиска. То есть модуль, который можно было в считанные минуты подключить к любому другому подобному продукту. Как сделать такой модуль - было четко описано в техническом задании, но вот времени на это не хватило. Но, правда, и системе это было особо не нужно - разве только нам самим.

Сама оболочка должна быть удобным средством просмотра информации. Создавая продукт на базе ActiveX, мы, по сути, сделали сервер и браузер в одном флаконе. То есть страница запрашивается по адресу, который наша программа разбирает, из него решает, что брать и где, берет оттуда текст (используется виртуальная ФС), затем этот текст видоизменяет (применяется тот или иной шаблон представления), и видоизменный HTML загружает в компоненту браузера.

Для справочного раздела за основу брались тексты документов законодательства. Некоторые из них могли быть размером в несколько мегабайт чистого текста. Для обработки этих текстов были написаны несколько десятков скриптов, обрабатывающих их и приводящих в требуемый вид. В частности, такие скрипты обнаруживали списочные структуры (начинающиеся с числа и точки, и заканчивающихся знаком препинания - запятой, точкой с запятой или точкой) и оформляли их в полном соответствии со стандартами оформления списков HTML. Также большой документ делился на множество мелких, выполнялся анализ оглавления, и по нему строилась внутренняя структура, по которой восстанавливалась оригинальная структура, но уже в требуемом виде и оформлении.

В завершение, программа была доработана массой мелких, но важных вещей. Защита от повторного запуска, правильная реакция на отсутствие необходимых файлов, работа на разных разрешениях и под разными настройками шрифтов и цветов, работа с клавиатуры, шорткаты для основных функций, общее поведение для всех элементов, написание пользовательской документации.