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

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

UnixForum
Беспроводные выключатели nooLite купить дешевый 
компьютер родом из Dhgate.com

Lines Club

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

Библиотека сайта или "Мой Linux Documentation Project"

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 и обладал исключительными знаниями в области вопросов интернационализации и характеристик японских программ для чтения сообщений электронной почты. Нам будет очень не хватать его.


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


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

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