Йа волосат и бородат!
Многа буков под катом
Программный продукт «Spider» разрабатывался как система автоматизированной синхронизации удаленных БД. В дальнейшем он развился до автоматизированной системы выполнения запланированных задач. Система реализована в виде двух сервисов, один из которых проверяет расписание поставленных перед системой задач и при наступлении времени помещает задачи в очередь; второй сервис с некоторой периодичностью получает задачу из списка и выполняет. Функционал задачи реализуется в виде динамически подключаемых библиотек. Управление сервисами и задачами реализуется через отдельное интерфейсное приложение.
Прежде всего, при просмотре кода системы оформление кода вызывает шок. Никакого ООП, а только одна Великая и Ужасная, Единственная и Неповторимая Функция с опциональным набором вспомогательных. Вся эта каша приправлена очень скудными комментариями, зачастую вызывающими лишь недоумение своей непонятностью и запутанностью. Прям незабвенное «Что курили, чем кололись?» (с)
Архитектура системы представлена ядром, исполняющим задачи сервисным приложением и подключаемыми модулями, однако, с первого же взгляда возникает недоумение от распределения функционала между ядром и модулями. В системе выделены 4 задачи, часть функционала которых почему-то вынесена в ядро, что вызывает достаточно большие затруднения при доработке или расширении системы. В целом для архитектуры взята правильная идея, но ее реализация оставляет желать лучшего.
На текущий момент рассмотрен только код сервиса исполнения и ядра системы. С первых же строк удивило, что был написан свой логгер, хотя можно было восопользоваться системным. И хотя логгер самописный, он не является классом и не рассчитан на какую-либо гибкость использования. Кроме мелких недочетов и индуизмов удивило аж 3 способа проверки состояния сервиса — глобальной переменной, записью в реестре и проверкой сервиса через API. Местами часть из проверок, естесственно, забывалась. ) И, конечно же, проверки не вынесены в отдельные функции, что порождает назойливое дублирование мелких блоков кода. Параметры работы сервиса хранятся в виде кучи глобальных (в пределах модуля) переменных и определяются каждый раз при запуске любой задачи, хотя, по-хорошему, должна быть обьявлена одна структура, которая должна просто передаваться в модуль. В работе с реестром нет единообразия — то используется стандартный класс TRegistry, то — отдельный модуль с набором функций. Часть модулей вообще хочется объединить в несколько классов и выгрузить в какую-нибудь ДЛЛ. Или, хотя бы, выгрузить в отдельный модуль, так как они составляют ядро. Другую часть модулей хочется просто выкинуть и воспользоваться стандартными методами.
Отдельного упоминания стоит обработка исключений — читая код возникает ощущение, что у автора мания преследования или параноя. Никогда не забуду конструкцию try {...}except{...} третьей вложенности. Исключительные ситуации обрабатываются методом записи в лог, при этом зачастую не делается прерывания в работе функции или удаления временных объектов.
Еще одним отдельным и крайне важным недостатком системы является практически полное отсутствие технической документации. Несмотря на ее отсутствие во всех проектах как в принципе, здесь это является настоящей проблемой, ввиду зачастую встающей необходимости разгадывать ребус о предназначении функции/параметра/переменной/блока кода.
Прежде всего, самое главное и срочное — переделать реализацию архитектуры. Функционал должен знать свое место и не расползаться куда его не просят. Так же требуется документация в более нормальном виде, чем невнятный xls-ник.
Что касается кода, то тут работы — непочатый край: от разработки иерархии классов, до выделения полноценного ядра и стандартизации методов. Основное, конечно же — выделение ядра и разработка диаграммы классов.
Система спроектирована вполне прилично. Но вот реализация — просто отвратительна!
«Spider»
Preambula
Программный продукт «Spider» разрабатывался как система автоматизированной синхронизации удаленных БД. В дальнейшем он развился до автоматизированной системы выполнения запланированных задач. Система реализована в виде двух сервисов, один из которых проверяет расписание поставленных перед системой задач и при наступлении времени помещает задачи в очередь; второй сервис с некоторой периодичностью получает задачу из списка и выполняет. Функционал задачи реализуется в виде динамически подключаемых библиотек. Управление сервисами и задачами реализуется через отдельное интерфейсное приложение.
Status praesents и патогенез
Прежде всего, при просмотре кода системы оформление кода вызывает шок. Никакого ООП, а только одна Великая и Ужасная, Единственная и Неповторимая Функция с опциональным набором вспомогательных. Вся эта каша приправлена очень скудными комментариями, зачастую вызывающими лишь недоумение своей непонятностью и запутанностью. Прям незабвенное «Что курили, чем кололись?» (с)
Архитектура системы представлена ядром, исполняющим задачи сервисным приложением и подключаемыми модулями, однако, с первого же взгляда возникает недоумение от распределения функционала между ядром и модулями. В системе выделены 4 задачи, часть функционала которых почему-то вынесена в ядро, что вызывает достаточно большие затруднения при доработке или расширении системы. В целом для архитектуры взята правильная идея, но ее реализация оставляет желать лучшего.
На текущий момент рассмотрен только код сервиса исполнения и ядра системы. С первых же строк удивило, что был написан свой логгер, хотя можно было восопользоваться системным. И хотя логгер самописный, он не является классом и не рассчитан на какую-либо гибкость использования. Кроме мелких недочетов и индуизмов удивило аж 3 способа проверки состояния сервиса — глобальной переменной, записью в реестре и проверкой сервиса через API. Местами часть из проверок, естесственно, забывалась. ) И, конечно же, проверки не вынесены в отдельные функции, что порождает назойливое дублирование мелких блоков кода. Параметры работы сервиса хранятся в виде кучи глобальных (в пределах модуля) переменных и определяются каждый раз при запуске любой задачи, хотя, по-хорошему, должна быть обьявлена одна структура, которая должна просто передаваться в модуль. В работе с реестром нет единообразия — то используется стандартный класс TRegistry, то — отдельный модуль с набором функций. Часть модулей вообще хочется объединить в несколько классов и выгрузить в какую-нибудь ДЛЛ. Или, хотя бы, выгрузить в отдельный модуль, так как они составляют ядро. Другую часть модулей хочется просто выкинуть и воспользоваться стандартными методами.
Отдельного упоминания стоит обработка исключений — читая код возникает ощущение, что у автора мания преследования или параноя. Никогда не забуду конструкцию try {...}except{...} третьей вложенности. Исключительные ситуации обрабатываются методом записи в лог, при этом зачастую не делается прерывания в работе функции или удаления временных объектов.
Еще одним отдельным и крайне важным недостатком системы является практически полное отсутствие технической документации. Несмотря на ее отсутствие во всех проектах как в принципе, здесь это является настоящей проблемой, ввиду зачастую встающей необходимости разгадывать ребус о предназначении функции/параметра/переменной/блока кода.
Терапия
Прежде всего, самое главное и срочное — переделать реализацию архитектуры. Функционал должен знать свое место и не расползаться куда его не просят. Так же требуется документация в более нормальном виде, чем невнятный xls-ник.
Что касается кода, то тут работы — непочатый край: от разработки иерархии классов, до выделения полноценного ядра и стандартизации методов. Основное, конечно же — выделение ядра и разработка диаграммы классов.
Epilogue
Система спроектирована вполне прилично. Но вот реализация — просто отвратительна!