Прим ред.: В первой части обзора, опубликованной в «Open Source» 031, были рассмотрены инструменты для проекта ПО (UML-редакторы, текстовые и графические редакторы) и IDE.
Тестирование
Тестирование — важный и неотъемлемый этап разработки программного обеспечения, который позволяет проверить программу на соответствие начальным требованиям заказчика или техническому заданию. Тесты разрабатываются одновременно с реализацией программы в виде кода. Специалист по тестированию выявляет несоответствия и ошибки в работе программы и записывает их в специальную систему учета ошибок. В этой системе хранится описание ошибки и действия, приводящие к ее возникновению. Существует множество видов тестирования. Для интересующихся этой тематикой можно порекомендовать почитать об этом в Википедии (http://en.wikipedia.org/wiki/Software_testing), а также книги о тестировании программного обеспечения.
Инструментов тестирования — много, а наиболее широко применяются следующие:
CppUnit (http://cppunit.sourceforge.net/cppunit-wiki) – средство модульного тестирования программ, написанных на языке С++ (С не поддерживается).
Junit (http://www.junit.org/) – средство модульного тестирования программ, написанных на языке Java.
Nunit (http://www.nunit.org/) – средство модульного тестирования программ, написанных на языке C#.
Отладка
На этапе тестирования мы обнаружили ошибки и настало время понять причину их возникновения, прогнать программу в отладчике. Какой отладчик выбрать? К сожалению, свободно-распространяемых отладчиков не так много:
GDB (http://www.gnu.org/software/gdb/) – мощный свободно-распространяемый отладчик программ, который используется на множестве платформ для отладки программ, написанных на C, C++, Fortran и других, которые входят в состав коллекции компиляторов GNU GCC. Обеспечивает все основные функции отладки: пошаговое исполнение, вход в функции, просмотр стека, просмотр и модификация переменных, точки останова программы, удаленная отладка программы и работающего процесса.
JDB – аналогичный GDB отладчик, но для языка Java. Входит в состав комплекта разработчика на языке Java (http://java.sun.com/).
Система контроля версий
После того, как получена стабильно работающая программа, необходимо зафиксировать это достижение и использовать его как отправную точку для дальнейшего развития. Самый простой, но не самый эффективный способ — это сделать архив. Таким способом пользовался и я, когда был студентом. Помучившись с поиском нужной редакции кода и невозможностью быстро откатить изменения, я начал искать решение. В то время им стала VSS (Visual Source Safe). Позже, когда я занялся программированием под Linux и UNIX-подобные системы реального времени, я стал применять CVS. Это отличная система, но, к сожалению, дружественной к пользователю назвать ее трудно, да и переносимость хранилища у нее тоже имеет свои особенности. Более современной системой является Subversion, разрабатываемая Tigris.org и Collab.net.
Что же дает такая система? Возможность хранить основную стабильную версию программы в качестве базовой ревизии, а все остальное — в виде отличий от базовой ревизии. Это позволяет вести историю изменений в программе, иметь доступ к любой версии исходного кода в точках фиксации, а также легко делать патчи для исходного кода. Итак, какие системы использовать?
CVS (http://www.nongnu.org/cvs/) – старая, стабильная, проверенная временем система. Права доступа к дереву исходного кода определяются правами доступа к файлам. Клиенты и серверы системы есть для Windows и Linux. Интерфейс для Windows неудобен для среднего пользователя (по статистике нашей компании).
Subversion (http://subversion.tigris.org/) – современная, развивающаяся система контроля версий. Хранилище легко переносимо, так как представляет собой файл специального формата, данные в котором хранятся в сжатом виде. Права доступа определяются в самой системе и могут быть не связаны с файловой системой. Существуют удобные клиентские программы как для Linux (ksvn и esvn), так и для Windows (TortoiseSVN).
Документация
Когда есть стабильный код и скомпилированная программа, требуется написать документацию для пользователей. В этом помогут все те же инструменты: текстовый редактор и графический редактор, о которых писалось выше. Что еще более важно, часть документации у нас уже есть — ведь написан проект, который и является основой для написания документации для пользователей и разработчиков. Кроме того, создана программа, которая с большой долей вероятности будет дорабатываться другими программистами той же компании. Здесь придется к месту немного магии. Если вы привыкли писать комментарии для своих программ, вас очень порадует, что на основе исходного кода и комментариев можно автоматически сгенерировать документацию для разработчиков. Какие программы это делают?
Doxygen (http://www.stack.nl/~dimitri/doxygen/) – отличная система генерации документации для разработчиков, которая, анализируя специальные теги в комментариях, создает документацию по коду. Если дополнить ее утилитой Graphviz (http://graphviz.org/), позволяет генерировать графы переходов в программе, диаграммы классов и взаимосвязи функций. На выходе можно получить документацию в форматах LaTeX, RTF, CHM, HTML и PDF. Языки, которые понимает система: PHP, C, C++, Java и другие C-подобные языки.
Javadoc (http://java.sun.com/j2se/javadoc/) – система, аналогичная Doxygen, но применимая только для Java. Разработана Sun Microsystems и входит в состав инструментария Java-разработчика.
Пакет развертывания
Теперь есть все, чтобы собрать дистрибутив. Пользователям не нравится разворачивать программу в виде отдельных библиотек, исполняемых файлов и файлов настроек, которые он сам должен раскладывать по специальным каталогам. И еще хуже, если он будет вынужден скачивать дополнительные пакеты. Пользователь хочет разворачивать программы в одно нажатие, а настройку производить с помощью удобных графических форм. Для решения задачи сборки пакета развертывания создано множество приложений, которые частично или полностью решают следующие задачи:
включение проверки необходимых библиотек и настроек окружения;
выполнение установки дополнительных библиотек и настроек перед началом установки основного приложения;
загрузка недостающих библиотек из сети Интернет;
выбор параметров установки приложения;
развертывание библиотек, исполняемых файлов и настроек в системные каталоги;
создание скрипта удаления приложения.
В системах Windows и Linux существует несколько свободно-распространяемых пакетов для создания дистрибутивов.
1. Современные пакеты развертывания для Windows основаны на унифицированной в Microsoft системе MSI (Microsoft Installer):
NSIS (http://nsis.sourceforge.net/) — разработанный командой NullSoft пакет, используемый при установке плеера WinAmp и множества других приложений. Позволяет реализовать проект развертывания почти любой сложности благодаря тому, что проект пакета развертывания создается на языке скриптов.
WIX (http://wix.sourceforge.net/) — так же, как и NSIS, обладает огромной гибкостью. Используется Microsoft для создания установочного пакета для MS Office.
2. В Linux существует множество пакетов развертывания. Крупные дистрибутивы GNU/Linux используют в своей основе тот или иной формат пакетов:
deb — формат пакетов для установки и распространения программного обеспечения. Используется в Debian GNU/Linux и его производных (например, Ubuntu Linux). Проверяет зависимости программы от библиотек, а также позволяет производить установку зависимых пакетов. Утилита для работы с файлами deb называется dpkg. Она используется для простых операций с пакетами: установка, удаление, чтение информации... Для удобства пользователей существует утилита с графическим интерфейсом Synaptic, а также Aptitude с псевдографикой. Для создания пакетов необходимы утилиты debhelper, dh-make, devscripts, fakeroot, dpkg-build (http://www.debian.org/doc/maint-guide/). Создание пакета требует подготовки специальных скриптов и структуры директорий с файлами, помещаемыми в пакет.
RPM — разработанный в Red Hat формат пакетов для распространения и развертывания программного обеспечения. Проверяет зависимости пакетов и может автоматизировать процесс установки, обновления и удаления с помощью макросов. Для установки пакетов пользователь может использовать богатый набор утилит с графическим интерфейсом urpmi, YaST, yum. Для создания пактов используется утилита rpmbuild (http://docs.fedoraproject.org/drafts/rpm-guide-en/). Сложность работы с этой утилитой не больше чем с dpkg — также требуется подготовка специальных файлов и структуры директорий с файлами.
tgz — применяется в системах, основанных на Slackware. Представляет собой архив в формате tar.gz с файлами программного обеспечения. Для установки и удаления пакетов используется утилита с псевдографическим интерфейсом pkgtool, только для установки — installpkg, для удаления — removepkg, для обновления — upgradepkg (http://www.slackbook.org/html/package-management-package-utilities.html). Для создания пакетов используется утилита makepkg, которая выполняется в директории, подлежащей преобразованию в пакет и содержащей корректную структуру директорий и файлов (http://www.slackbook.org/html/package-management-making-packages.html).
emerge — продвинутая система управления пакетами, используемая в системах, основанных на Gentoo. Обеспечивает проверку зависимостей пакетов и загрузку из интернета всех пакетов для удовлетворения зависимостей. Для установки пакетов используется утилита emerge, которая автоматически проверяет зависимости и может удовлетворить их загрузкой недостающих пакетов из Internet. Для создания пакетов используется эта же утилита, с ключем --build. Также могут быть использованы утилиты quickpkg (http://www.gentoo.org/doc/ru/handbook/handbook-x86.xml?part=2&chap=3).
Пакеты развертывания в Linux не так просты для пользователя, как таковые в системах Windows, поскольку они преследуют разные цели использования. Так что сопоставлять пакеты развертывания для Linux и Windows очень сложно. (Прим ред.: Замечание актуально, если брать Linux «в целом», поскольку обусловлено разнообразием используемых в дистрибутивах менеджеров пакетов. Однако для конечного Linux-пользователя конкретной системы зачастую пакеты ПО могут быть и удобнее, чем в Windows.)
Сбор информации об ошибках
Теперь, когда приложение используется множеством пользователей по всему миру, стоит обратить внимание на тот факт, что периодически в программе возникают ошибки. Пользователь настаивает на их решении, но чтобы специалист мог проверить наличие ошибки, он должен знать всю информацию об ошибке, последовательность действий, а иногда даже и дамп памяти в момент возникновения ошибки. Но как пользователи передадут все нужные сведения разработчику? Где хранить эти данные? Как отслеживать какие проблемы решены, а какие — нет? Кто отвечает за решение проблемы? Кто проверит решение? Решать все эти вопросы только с использованием электронной почты не очень удобно — особенно если у программы множество пользователей. Так появились системы слежения за ошибками. Подобных систем с открытым исходным кодом — очень много, но наш опыт показал, что самой удобной и функциональной остается система Bugzilla (http://www.bugzilla.org/), разработанная в рамках проекта Mozilla. Эта система позволяет решить все вышеперечисленные задачи.
Иллюстрация 1: Web-интерфейс Bugzilla на bugzilla.mozilla.org
Заключение
В заключение отмечу, что поскольку мир все время меняется, может изменяться и список программ. Это лишь краткий обзор для тех, кто ищет средства для организации процесса разработки программного обеспечения с использованием программ с открытым исходным кодом. Мы нашли их путем долгих экспериментов, и все эти средства успешно применяются в наших проектах. Мы продолжаем непрерывно следить за развитием этих средств и появлением новых.
