Про то, что у работающего проекта всегда должен быть минимум одна резервная копия - наверное, знают все. Надеюсь, что большинство знает из чужого опыта. Так, один товарищ недавно потерял более 1,5 месяцев кропотливой работы по забивке базы (не только своей, даже преимущественно не своей). Проекту Берсерк-Онлайн приходилось прибегать к резервной копии ровно один раз за примерно 3 года существования... Но если бы этой копии не было - весьма возможно, что пришлось бы ставить на нас большой жирный крест.
Но в данном случае речь идет, конечно, не про резервную копию сайта, базы и иже с ним. Речь - про продукт трудов разработчика, дизайнера, - исходники программы или сайта (например, нарезанные PSD для дизайнеров). Есть масса способов потерять свое время, и масса способов его сохранить. Далее, в продолжении статьи, я попробую привести несколько примеров... Возможно, встретится что-то знакомое. Речь пойдет также про CVS и другие системы контроля версий (Perforce, Subversion).
Речь про системы контроля версий зашла не случайно. Не далее как сегодня, обнаружилась "пропажа" почти доделанного, но недотестированного куска кода во флэш клиенте игры. Конечно, потеря двух рабочих дней - не так страшна, как потеря всего проекта (а ведь бывает и такое). Но это - то время, которое можно потратить с большей эффективностью. Поэтому - даже если вы - единственный и неповторимый разработчик, руководитель группы разработчиков, состоящей из одного человека - возьмитесь за репозитарий исходного кода.
Если речь идет про домашний компьютер - лучше, чтобы репозитарий исходного кода хранился на отдельном жестком диске. Или хотя бы присутствовал RAID массив (зеркало, RAID1). Еще лучше, если репозитарий размещен на специально выделенном компьютере. Еще лучше, если на этом выделенном компьютере есть RAID1. Не реже, чем раз в 2 рабочих дня - очень желательно сливать рабочую версию исходного кода в репозитарий. В идеале - раз в сутки.
Начинал я, как и многие другие, с хранения архивной копии исходников внутри ZIP/RAR архива. Это лучше, чем отсутствие резервной копии, но хуже, чем использование репозитария.
Во-первых, отсутствует возможность быстро и легко посмотреть внесенные в проект изменения. На анализ уходит ощутимо больше времени. Во-вторых, сложно вспомнить, в какой именно день проект работал так, как ему положено, и никак иначе. В-третьих, архивные копии занимают ощутимо больше места - некритично, но неприятно.
Если над проектом работает команда разработчиков (пусть даже из 2х человек) - все сложнее. Работая в одиночку, программист может сливать в репозитарий даже нерабочую копию проекта. Для себя. Но если над проектом работает несколько человек, вливание плохо работающего кода может помешать остальным. Есть несколько способов для борьбы с этим недугом.
Первый, и самый простой. Громко гаркнуть на весь офис что-то вроде "Пашка, с репозитария файлы лучше не бери, там косяки". Просто, но неэффективно. Наиболее правильный - второй способ - не пытаться объять необъятное и не затевать изменений, которые влекут за собой более чем 2 дня работы. В идеале - даже 1 день. Главное - трезво оценивать свои возможности и потребность сохранения работы в репозитарии раз в 1-2 дня.
Комментарии при заливке в репозитарий должны быть понятными и четкими. Вовсе не значит, что там надо расписывать всю работу, которая сделана. Или использовать формальный язык или технические термины. Главное - иметь возможность самому сориентироваться в этих названиях, например, спустя месяц. У нас вполне допускаются комменты вроде "Исправления кода класса ХХХХ за гребаными индусами" или "Исправление ошибки с захаванными Ктулху столами". В других компаниях и коллективах, конечно, все может быть иначе.
Теперь о том, как можно потерять изменения.
Если вы работаете над проектом с разных компьютеров, иногда можно с одного компьютера "забыть" залить что-то в репозитарий. Или откатиться с рабочей копии до состояния репозитария (это я и сделал недавно, при переезде на новый компьютер). Иногда я правлю скрипты прямо на сервере из дома (если это необходимо), и забываю залить изменения в репозитарий (недоступен из дома). Впрочем, уже очень давно этого не делал - свое время дороже.
Можно запоганить свой код при неудачной синхронизации, можно просто забить на наличие репозитария... Проблем может быть масса, и чтобы их не было, надо всегда придерживаться одной, единой парадигмы: сливаем копию исходников из репозитария, правим, тестируем, заливаем на сервер, убеждаемся в работоспособности, заливаем в репозитарий. Всегда. Экономит время и нервы. Проверено. Несколько минут, потраченных на эти "лишние" шаги, могут сэкономить бесценное время в будущем.
Жесткие диски в наше время стоят копейки. Огромных размеров жесткие диски. А сколько стоит ваш труд? Сколько стоит весь ваш труд за полгода? Год? За все время с начала карьеры? Покупку нового железа под репозитарий, можно рассматривать не как трату, а как экономию. Вспоминается анекдот:
Жена - мужу:
- Вот сколько с тобой живу, и все больше убеждаюсь в том, что ты неэкономный!
- Да как так? Наоборот, я очень экономный и бережливый!
- Нет! Вот огнетушитель ты купил 3 года назад и мы его до сих пор ни разу не использовали!
Человек имеет свойство допускать ошибки. Железо имеет свойство ломаться. С этими свойствами можно бороться достаточно незначительными денежными вливаниями - например, 15 тысяч рублей на сервер под репозитарий; или 3 тысячи рублей на еще один винчестер. Это - очень эффективно.
Обязательно напишу про несколько систем контроля версий и их интеграцию в другие программные продукты.