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

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

• Профессионал не приемлет длинных списков дефектов. Огромный список дефектов — это признак неряшливой работы. Системы, в которых система управления дефектами содержит тысячи записей, — это трагедия беспечности. Более того, в большинстве проектов сама потребность в автоматизированной системе управления дефектами есть симптом беспечности. Только очень крупные системы могут иметь такое большое количество ошибок, что для управления ими требуется автоматизация.

• Профессионал поддерживает порядок. Он гордится своим мастерством. Его код понятен, хорошо структурирован и легко читается. Профессионалы следуют оговоренным стандартам и лучшим практикам. Они никогда, ни при каких обстоятельствах не работают впопыхах. Представьте себе, что вы можете покинуть собственное тело и наблюдать, как врач делает вам операцию на открытом сердце. У этого врача есть крайний (в буквальном смысле) срок завершения работы. Он должен закончить операцию до того, как аппарат искусственного сердца повредит слишком много кровяных клеток в вашем организме. Как, по-вашему, он должен себя вести? Вы бы хотели, чтобы он вел себя как типичный программист, пишущий код в спешке и беспорядке? Хотите ли вы услышать от него: «Как-нибудь потом все это исправлю»? Или все же он должен тщательно придерживаться правил своей науки, рассчитывать время и быть уверенным, что избранный им подход — лучший из доступных ему? Чего хотите вы — беспорядка или профессионализма?

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

Держите все в системе управления версиями

Диомидис Спинеллис

Храните все, что касается любых ваших проектов, в системе управления версиями. Необходимые для этого ресурсы уже имеются: бесплатные инструменты типа Subversion, Git, Mercurial и CVS, вдоволь дискового пространства, дешевые и мощные серверы, повсеместный доступ в Интернет и даже службы хостинга проектов. После того как вы установили систему управления версиями, сохранить ваши труды в репозиторий очень просто: достаточно лишь выполнить соответствующую команду в чистом каталоге с кодом. А освоить нужно всего две новые основные операции: запись (commit) в репозиторий изменений, сделанных вами в коде, и обновление (update) вашей рабочей версии проекта до той, которая находится в репозитории.

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

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

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

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

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

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

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

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

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

Берк Хафнагель

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

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

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

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

try {