Диомидис Спинеллис
Храните все, что касается любых ваших проектов, в системе управления версиями. Необходимые для этого ресурсы уже имеются: бесплатные инструменты типа Subversion, Git, Mercurial и CVS, вдоволь дискового пространства, дешевые и мощные серверы, повсеместный доступ в Интернет и даже службы хостинга проектов. После того как вы установили систему управления версиями, сохранить ваши труды в репозиторий очень просто: достаточно лишь выполнить соответствующую команду в чистом каталоге с кодом. А освоить нужно всего две новые основные операции: запись (commit) в репозиторий изменений, сделанных вами в коде, и обновление (update) вашей рабочей версии проекта до той, которая находится в репозитории.
После того как проект помещен в систему управления версиями, можно без труда просмотреть его историю, узнать, кто написал каждый фрагмент кода, и обратиться к конкретной версии файла или проекта с помощью уникального идентификатора. А что еще важнее — теперь вы можете делать рискованные изменения в коде, и больше не нужно оставлять закомментированный код на случай, если он потребуется в будущем. Ведь старая версия надежно хранится в репозитории. Можно (и нужно) помечать (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.
Если приведенный код кажется слишком многословным и трудным для понимания, не волнуйтесь. Мне тоже так показалось, и я решил, что нашел код, который стоит подчистить. Я переработал его и написал несколько модульных тестов, чтобы проверить, по-прежнему ли правильно работает новый код.
Закончив работу, я остался доволен результатами. Новый вариант легко читался, был вдвое меньшего размера и точнее, поскольку прежний код проверял только верхнюю границу часов, минут и секунд.
Когда я собирался на работу на следующий день, меня посетила идея: а почему бы не проверить правильность строки с помощью регулярного выражения? Через несколько минут у меня была рабочая реализация, состоящая всего из одной строки кода:
public static boolean validateTime(String time) {
return time.matches("(0[1–9]|1[0–2]):[0–5][0–9]:[0–5][0–9] ([AP]M)");
}
Смысл не в том, что в итоге мне удалось заменить 30 с лишним строк кода одной, а в том, что пока я не отошел от компьютера, мне казалось, что мой первый вариант был лучшим решением задачи.
Поэтому, когда вы в следующий раз столкнетесь с неподатливой задачей, сделайте себе одолжение. По-настоящему разобравшись в сути проблемы, займитесь чем-то, что включит творческую часть вашего мозга: нарисуйте схему проблемы на бумаге, послушайте музыку или просто выйдите из дома. Иногда лучшее, что вы можете сделать, чтобы решить задачу, — это бросить мышь и отойти от клавиатуры.
Читайте кодКарианне Берг
Мы, программисты, странные создания. Мы любим писать код. Но что касается чтения кода, мы обычно сторонимся этого дела. В конце концов, писать код гораздо увлекательней, а читать код трудно — иногда почти невозможно. Особенно тяжело читать код, написанный другими. Не всегда из-за того, что он плохо написан, но потому, что другой человек думает и решает задачи иначе, чем вы. А вам не приходило в голову, что чтение чужого кода может помочь улучшить ваш собственный код?
Когда вы в следующий раз будете читать какой-нибудь код, остановитесь и задумайтесь. Трудно его читать или легко? Если трудно, то почему? Он плохо отформатирован? Система именования непоследовательна или нелогична? Несколько задач смешались в одном фрагменте кода? Возможно, выбранный язык затрудняет чтение кода. Старайтесь учиться на чужих ошибках, чтобы не повторять их в своем коде. Вас могут ожидать сюрпризы. Например, приемы разрыва зависимостей могут быть полезны для введения слабого связывания, но они могут также затруднить чтение кода. А код, который одни считают элегантным, другие могут назвать нечитаемым.
Если код читается легко, обратите на него внимание и посмотрите, нельзя ли чему-то научиться у этого кода. Возможно, в нем применяется шаблон проектирования, который вам не знаком или который вы пытались реализовать ранее. Или он содержит методы более короткие и более точно именованные, чем ваши. В некоторых проектах с открытым исходным кодом можно встретить массу примеров великолепного, понятного кода, тогда как в других вы столкнетесь с прямо противоположным! Скачайте немного кода из репозиториев таких проектов и поизучайте его.
Чтение собственного старого кода из проекта, над которым вы больше не работаете, тоже может оказаться поучительным опытом. Начните с какого-нибудь самого старого кода и постепенно продвигайтесь к коду, который пишете сегодня. Возможно, вы обнаружите, что читать старый код совсем не так легко, как было в то время, когда вы его писали. Ваш ранний код может вызвать у вас определенное смущение, типа того, которое испытываешь, когда тебе рассказывают о том, что ты говорил накануне вечером, выпивая в пабе. Посмотрите, как с годами росло ваше мастерство; это может стать весьма ободряющим открытием. Выясните, какие части кода тяжело читать, и подумайте, продолжаете ли вы писать код в том же стиле сегодня.
Итак, когда вы в следующий раз почувствуете необходимость улучшить свое мастерство программирования, не беритесь за книги. Читайте код.