97 этюдов для программистов. Опыт ведущих экспертов

После того как проект помещен в систему управления версиями, можно без труда просмотреть его историю, узнать, кто написал каждый фрагмент кода, и обратиться к конкретной версии файла или проекта с помощью уникального идентификатора. А что еще важнее — теперь вы можете делать рискованные изменения в коде, и больше не нужно оставлять закомментированный код на случай, если он потребуется в будущем. Ведь старая версия надежно хранится в репозитории. Можно (и нужно) помечать (tag) стабильные версии понятными вам именами, чтобы потом быстро получить именно ту версию, которая работает у вашего клиента. Можно создавать отдельные ветви (branches) и разрабатывать их параллельно: в большинстве проектов есть активно разрабатываемая ветвь и одна или несколько ветвей более ранних версий, для которых осуществляется активная поддержка.

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

Организуя работу над проектом, не жадничайте: поместите в систему управления версиями все, что относится к проекту. Помимо исходного кода занесите в репозиторий документацию, инструменты, сценарии для сборки, описания тестовых сценариев, графический материал и даже библиотеки. Когда весь проект надежно помещен в репозиторий (для которого регулярно делается резервная копия), возможный ущерб от потери диска или данных становится минимальным. Чтобы начать разработку на новой машине, достаточно получить копию (check out) проекта из репозитория. Это упрощает распространение, сборку и тестирование кода на разных платформах: на любой машине единственная команда обновления гарантирует вам загрузку последней версии программного обеспечения.

После того как вы оцените прелести работы с системой управления версиями, присмотритесь к следующим правилам, которые сделают вашу работу и работу вашей команды еще более эффективной:

• Сохраняйте каждое логическое изменение в виде отдельной операции. Если вы объедините большую кучу изменений в одну запись (commit), вам будет трудно разделить их впоследствии. Это особенно важно, когда проводится рефакторинг или изменение стиля в рамках всего проекта, что может легко скрыть другие модификации.

• Сопровождайте каждое изменение поясняющим сообщением. Как минимум кратко опишите, что вы изменили. И если вам требуется сохранить на будущее причины сделанных изменений, лучшего места не найти.

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

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

Брось мышь и медленно отойди от клавиатуры Берк Хафнагель

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

Случалось ли с вами такое? Приходилось ли вам задумываться, почему так происходит? Все дело в том, что, когда вы пишете код, активна логическая часть вашего мозга, а творческая отключена. Она никак не сможет себя проявить, пока логическая сторона не сделает перерыв в работе.

Вот вам пример из жизни. Я причесывал кое-какой старый код и наткнулся на «занятный» метод. Он предназначался для проверки правильности формата времени в строке вида hh: mm: ss xx, где hh — это часы, mm — минуты, ss — секунды, а xx принимает значение AM или PM.

Метод содержал следующий код для преобразования двух символов (представляющих час) в число и проверки, что час находится в заданном диапазоне:

try {

   Integer.parseInt(time.substring(0, 2));

} catch (Exception x) {

   return false;

}

if (Integer.parseInt(time.substring(0, 2)) > 12) {

   return false;

}

Тот же самый код появлялся еще дважды с соответствующими изменениями в смещении символов и в значении верхней границы, чтобы проверить правильность минут и секунд. Заканчивался метод следующими строками, проверяющими AM и PM:

if (!time.substring(9, 11). equals("AM") &

    !time.substring(9, 11). equals("PM")) {

   return false;

}

Если ни одно из этого ряда условий не оказывалось ложным (при этом возвращается false), метод возвращал true.