Личный опыт разработки ПО

Для автоматизации сборки проектов традиционно используют системы сборки, такие как make на Unix подобных системах и nmake для компилятора Microsoft. Также традиционно написание файлов для сборки проекта под эти системы является задачей нетривиальной. Конечно в пользуясь только Mictosoft Visual Studio можно даже не подозревать о существовании этих файлов, так как интегрированная среда разработки достаточно удобно скрывает всю кухню, оставляя снаружи несколько диалоговых окон и кнопку Build. Но для сложных проектов использующих массу сторонних библиотек и кроссплатформенных проектов такой подход часто оказывается неприемлемым.

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

Что нужно сделать?

Собрать программу hello_world.

Как ее делать?

Взять файлы hello_world.h и hello_world.cpp и запустить компилятор передав их в качестве параметров.

Что делать когда компилятор закончит работать?

Взять получившийся в результате работы компилятора объектный файлы hello_world.o и запустить линковщик передав ему этот файл.

Все.

Причем каждый подпроект может иметь свой файл сборки, а главный make-файл сможет пройти рекурсивно по подпроектам, выполнив его файл сборки, а потом собрать проект из этих компонентов.

Выглядит все просто, проблемы возникают дальше и проблем несколько:

1. Разрешение зависимостей возникающих между частями проекта
2. Синтаксическая сложность и неоднозначность классических make-файлов
3. Привязка к конкретной утилите автоматической сборки и как следствие непереносимость на другие платформы

Для решения части этих проблем или всех сразу были созданы следующие инструменты: Automake (http://sourceware.org/automake/) , CMake (http://www.cmake.org/), SCons (http://www.scons.org/). Список далеко не полный.

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

Читать заметку полностью »

От основной ветки разработки можно отделить ветвь являющуюся ее копией на данный момент времени. Этим решаются следующие задачи:

• Фиксация состояния разработки (например выпуск новой версии) к которому можно будет вернуться в любой момент.
• Разработка независимо от основной ветви — актуально когда над проектом работают несколько разработчиков.

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

Читать заметку полностью »

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

Основные требования:

• Разработчик должен быстро приступить к работе не забивая голову установкой десятка библиотек.
• Библиотеки должны быть доступны из разных проектов, при этом необходимо избежать дублирования кода в репозиториях.
• Должна быть возможность сохранять определенные состояния проекта: новые версии, номерные сборки для тестеров и т.д.

Читать заметку полностью »

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

Читать заметку полностью »