Наши партнеры

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

GNU Mailman

Глава 10 из книги "Архитектура приложений с открытым исходным кодом", том 2.

Оригинал: GNU Mailman
Автор: Barry Warsaw
Перевод: А.Панин

10.10. Выученные уроки

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

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

Используйте технику разработки через тестирование (test driven development - TDD). Другого пути в действительности не существует! В версии 2 системы Mailman очень не хватало набора автоматизированных тестов и, хотя и справедливо утверждение о том, что не вся кодовая база версии 3 системы Mailman затрагивается существующим набором тестов, большая часть все же тестируется и весь новый код должен быть подвергнут тестированию либо с помощью unittests, либо с помощью doctests. Использование техники разработки через тестирование является единственным способом проверки того, что все сделанные вами сегодня изменения не приводят к регрессиям в существующем коде. Да, техника разработки через тестирование иногда замедляет процесс разработки, но стоит рассматривать это замедление как инвестицию в будущее качество вашего кода. Таким образом, отсутствие качественного набора тестов означает то, что вы просто теряете свое время. Запомните мантру: не протестированный код является неработоспособным.
Следите за манипуляциями с байтами/строками с самого начала. В Python 3 проведено жесткое разделение между текстовыми строками в кодировке Unicode и байтовыми массивами, которое, хотя изначально и воспринимается болезненно, но впоследствии оказывается значительным преимуществом, используемым для разработки корректного кода. В Python 2 эта граница была размытой, так как строки могли быть как в кодировке Unicode, так и 8-битными ASCII-строками, при этом для их преобразований использовались некоторые автоматизированные механизмы. Несмотря на то, что такое представление строк выглядело достаточно удобным, проблема этой размытой границы была первостепенной причиной ошибок в версии 2 системы Mailman. Также этот способ представления строк не являлся полезным ввиду того факта, что сообщение электронной почты, очевидно, сложно систематизировать как набор строк и байт. Технически представление входящего сообщения электронной почты является байтовой последовательностью, но эти байты практически всегда являются символами из таблицы ASCII и существует большое желание производить манипуляции с сообщением в текстовой форме. Стандарты, относящиеся к сообщениям электронной почты, описывают то, как читаемый человеком текст в отличной от ASCII кодировке может быть безопасно закодирован, поэтому даже такие задачи, как поиск префикса Re: в заголовке Subject: будет реализован с помощью операций для работы с текстом, а не операций для работы с байтами. Принципом функционирования системы Mailman является преобразование всех входящих данных из байтового представления в строки Unicode так быстро, как это возможно, внутренняя обработка строк с использованием кодировки Unicode и преобразование назад в байтовый поток только при формировании исходящих сообщений. Важно, чтобы были абсолютно ясны с самого начала периоды осуществления обработки байт и периоды осуществления обработки текста, так как это модель будет очень сложно модифицировать впоследствии.
С самого начала производите интернационализацию вашего приложения. Вам действительно хочется, чтобы ваше приложение использовала только малая часть англоязычных пользователей со всего мира? Подумайте о том, какое количество замечательных пользователей игнорируется! Не так сложно начать процесс интернационализации, причем существует множество хороших инструментов для упрощения этого процесса, многие из которых были впервые применены в системе Mailman. Не беспокойтесь о том, с каких переводов начать; если ваше приложение будет доступно для носителей множества языков со всего мира, в вашу дверь обязательно постучат переводчики с предложениями помощи.

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

Заключительные слова

Во время написания этой главы мы с глубокой скорбью узнали о кончине Tokio Kikuchi (http://wiki.list.org/display/COM/TokioKikuchi), профессора из Японии, который внес большой вклад в разработку Mailman и обладал исключительными знаниями в области вопросов интернационализации и характеристик японских программ для чтения сообщений электронной почты. Нам будет очень не хватать его.

Далее: К началу статьи