Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
купить дешевый 
компьютер родом из Dhgate.com




Lines Club

Ищем достойных соперников.

Библиотека сайта rus-linux.net

Проект GPSD

Глава 7 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: GPSD, глава из книги "The Architecture of Open Source Applications" том 2
Автор: Eric Raymond
Перевод: Н.Ромоданов

7.8. JSON и архитектонавты

Одно из самых значительных преобразований в истории проекта произошло, когда мы перешли от первоначально используемого протокола сообщений к использованию JSON в качестве метапротокола и передачи клиентам объектов JSON. В исходном протоколе использовались однобуквенные символы в качестве команд и ответов, и т. к. возможности демона постепенно увеличивались, мы буквально задыхались в пространстве односимвольных имен.

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

Отобразив типы сообщений в объекты JSON, мы обеспечили, что любое сообщение может содержать объединение строковых, числовых и логические данных и структур (возможность, которой не было в старом протоколе). Благодаря тому, что типы сообщений идентифицируются с помощью атрибута class, мы обеспечили, что у нас всегда будет возможность добавлять новые типы сообщений, которые не будут мешать использовать старые.

Это решение не обошлось без затрат. Парсеру JSON требуется несколько больше вычислительных ресурсов, чем очень простому и ограниченному парсеру, который он заменил, и, конечно, в новом парсере больше строк кода (что предполагает больше мест для возникновения дефектов). Кроме того, обычные анализаторы JSON для того, чтобы справиться с массивами переменной длины и со словарями, которые описываются в JSON, требуют динамического распределения памяти, а динамическое распределение памяти является пресловутой причиной появления дефектов.

Мы справились с этими проблемами несколькими способами. Первым шагом было написание парсера на C для (достаточно) большого подмножества JSON, в котором используется исключительно статическое распределение памяти. Это потребовало принять некоторые незначительные ограничения, например, объекты в нашем диалекте JSON не могут содержать значение null, а массивы всегда имеют фиксированную максимальную длину. Приняв эти ограничения, мы смогли втиснуть парсер в 600 строк кода на языке C.

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

JSON уже не используется только для веб-приложений. Мы считаем, что любой, кто проектирует протокол для приложения, должен рассматривать подход, похожий на используемый в проекте GPSD. Конечно, идея создания протокола поверх стандартного метапротокола не нова; поклонники XML пользуются ей в течение многих лет, и это имеет смысл для протоколов со сложной структурой документов. JSON обладает преимуществом за счет более низких накладных расходов, чем в случае с XML, и он лучше подходит при обходе массивов и структур записей.

7.9. Проектирование с минимизацией количества дефектов

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

Мы считаем, что подобные отказы бесполезны и опасны: бесполезны, поскольку системные интеграторы, весьма вероятно, относятся к ним формально и их игнорируют, и опасны, поскольку они способствуют тому, что разработчики опрометчиво считают, что дефекты в кода не будут иметь серьезных последствий, и что допустимо сглаживать острые углы в сфере обеспечения качества программ.

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

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

Один из важных принципов состоит в следующем: демон gpsd никогда не использует динамическое распределение памяти - нет ни malloc, ни calloc, и нет никаких обращений к функциям или библиотекам, в которых они требуются. Благодаря этому одним махом исчезает самая пресловутая причина дефектов, имеющая место при кодировании на языке C. У нас нет никаких утечек памяти и нет никаких ошибок двойных malloc или двойных free и никогда их не будет.

Нам это сходит с рук, поскольку все датчики, с которыми мы работаем, передают пакеты с относительно небольшой фиксированной максимальной длиной, а работа демона состоит в их обработке и отправке их клиентам почти без буферизации. Тем не менее, отказ от использования malloc требует дисциплины при кодировании и некоторых конструктивных компромиссов, некоторые из которых мы уже отметили при рассмотрении парсера JSON. Мы добровольно идем на эти затраты с тем, чтобы уменьшить количество дефектов.

Полезным побочным эффектом этой политики является то, что повышается эффективность чеккеров (checker) статического кода, например, splint, cppcheck и Coverity. Это ведет нас к другому крупному политическому выбору; мы интенсивно используем оба этих инструмента аудита кода, а также специально настроенный фреймворк регрессионного тестирования. Мы не знаем ни о каких других проектах, кроме GPSD, которые полностью аннотированы для использования splint, и сильно подозреваем, что ничего подобного еще не существует.

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

Следует признать, что нам было несколько легче быть тщательными, чем многим другим приложениям, поскольку в демоне нет пользовательского интерфейса; окружающая его среда является простым набором последовательных потоков данных и ее относительно легко моделировать. Но, как и с отказом от использования malloc, фактическое использование этого преимущества требует правильного к нему отношения, что в частности означает, что нужно быть готовым тратить на проектирование и кодирование тестовых инструментальных средств и страховочных средств столько же времени, сколько мы тратим на создание кода. Это политика, которой, как мы думаем, могут и должны подражать другие проекты с открытым исходным кодом.

Когда я пишу эту статью (июль 2011 года), трекер ошибок проекта GPSD пуст. Он бывает пустым в течение недель, и на опыте появления сообщений об ошибках в прошлом, мы можем предполагать, что он будет оставаться таким же и далее. У нас в течение шести лет в коде не было критических ошибок. Когда у нас возникают ошибки, они, как правило, связаны к некоторым несущественными отсутствующими функциями или несоответствием спецификациеям, что легко исправляется в течение нескольких минут.

Это не означает, что проект был непрерывной идиллией. Далее мы рассмотрим некоторые из наших ошибок ...


7.10. Усвоенные уроки


Эта статья еще не оценивалась
Вы сможете оценить статью и оставить комментарий, если войдете или зарегистрируетесь.
Только зарегистрированные пользователи могут оценивать и комментировать статьи.

Комментарии отсутствуют