Я ищу легко поддерживаемую и расширяемую модель проектирования для сценария, позволяющего анализировать книгу Excel в две отдельные книги после извлечения данных из других мест, таких как командная строка и база данных. Детали высокого уровня следующие:
Мне нужно проанализировать книгу Excel, содержащую лист, в котором перечислены уникальные имена вопросов. Единственная надежная информация, которую можно проанализировать из названия вопроса, - это код книги, который определяет название и издание учебника, с которым связан вопрос, остальная часть имени вопроса не достаточно хорошо стандартизирована для надежного анализа компьютером. Общая форма названия вопроса лучше всего описывается следующим регулярным выражением.
'^(\w+)\s(\w{1,2})\.(\w{1,2})\.(\w{1,3})\.(\w{1,3}\.)*$'
Первый подшаблон - это код книги, второй подшаблон - это 90% времени главы, а остальные подшаблоны могут быть разделом, типом проблемы, номером проблемы или информацией о типе вопроса. Там нет простой логики, по крайней мере, я не могу найти.
В этой таблице будет минимум три других столбца; один столбец будет главой, с которой связан вопрос, второй будет разделом внутри главы, с которой связан вопрос, а третьим будет некоторый вид ресурса, обозначенный единым указателем ресурса.
- 1 | 1 | qname1 | URL | описание | URL | описание ...
- 1 | 1 | qname2 | URL | описание
- 1 | 1 | qname3 | URL | описание | URL | описание | url |
Актив может быть указан полным или частичным унифицированным указателем ресурса, частичный URL должен быть завершен, прежде чем он может быть введен в приложение. Теоретически не может быть никаких ограничений на количество столбцов активов, активы будут сгруппированы в столбцы по типу. Иногда дополнительные данные должны быть извлечены из базы данных или объединены с кодом книги, прежде чем URL ресурса будет завершен, и это может быть понято приложением, которое будет использовать актив.
Тип - это абстракция, сейчас существует восемь типов, каждый из которых имеет свою логику в том, как обрабатывается и / или завершается унифицированный указатель ресурса, и мне приходится добавлять новый тип и его логику каждые три или четыре месяца.
Для каждого URL ресурса есть возможность столбца описания, строки символов для отображения в приложении, но не всегда. (Я уже разработал проверку текста описания и сжатие неясной кодовой страницы MS для чего-то, что может обработать 7-битная ascii.)
Теперь, когда все детали заполнены, я могу перейти к реальной проблеме синтаксического анализа файла. Мне нужно разделить информацию в этой книге Excel на две отдельные книги. Первая рабочая тетрадь сгруппирует все вопросы по разделам в строки. Поскольку первая ячейка является дублетом раздела, а остальные ячейки в строке являются именами вопросов.
- 1.1 | qname1 | qname2 | qname3 | qname4 |
- 1,2 | qname1 | qname2 | qname3 |
- 1,3 | qname1 | qname2 | qname3 | qname4 | qname5
Нет заданного количества вопросов для каждого раздела, как видно из приведенного выше примера.
Вторая рабочая книга более сложная, для каждого актива имеется одна строка, и имена вопросов, содержащие более одного актива, будут продублированы. На этом листе будет четыре или пять столбцов. Первый - это имя вопроса для актива, второй - тип носителя, используемый для выбора правильного значка для актива в приложении, третий - строка, представляющая тип актива, четыре - полный и полный унифицированный указатель ресурса для ресурса. актив, а пятые столбцы - необязательное текстовое описание для актива.
- q1 | mtype1 | atype1 | URL | описание
- q1 | mtype2 | atype2 | URL | описание
- q1 | mtype2 | atype3 | URL | описание
- q2 | mtype1 | atype1 | URL | описание
- q2 | mtype2 | atype3 | URL | описание
Для исходных шести типов у меня был скрипт, который анализировал исходную книгу Excel в двух других книгах Excel, и я мог добавить еще два типа, пока не сел на мель на реализации девятого и десятого типов.
Что сломало мой сценарий, так это тот факт, что девятый тип на самом деле является подтипом одного из исходных шести, но с совершенно другой логикой, и мой в основном процедурный сценарий не мог вместиться без дублирования большого количества кода. У меня также было много ошибок в скрипте, и в этот раз я сначала напишу тест.
Я застрял с форматом для получающихся двух рабочих книг, этот скрипт - клейкий код, разработка продолжалась, не удосужившись получить полную спецификацию от спонсора. Я работаю в той же компании, что и разработчики, но в редакционном отделе, редакция является соавтором проекта, и я собираюсь исправить неприятные детали, подобные этой (я набиваюсь изо рта, когда набираю это).
Я пробовал фабрики, я пробовал разные объектные модели, но каждая полученная книга настолько отличается, когда я нахожу проект, который работает для генерации одной книги, и код не пригоден для генерации другой. Что мне действительно нужно, так это идеи о поддерживаемом и расширяемом дизайне для разбора исходной книги на обе книги с максимальным повторным использованием кода или сочувствием.