• Профессионал отвечает за написанный код. Он не выпускает код, если не уверен в его работе. Задумайтесь на минуту. Как вы можете считать себя профессионалом, если готовы выпустить код, в котором у вас нет уверенности? Профессиональные программисты ожидают, что отдел контроля качества ничего не найдет в их коде, потому что они выпускают его не раньше, чем тщательно протестируют. Конечно, группа контроля качества что-нибудь да обнаружит, ведь идеальных людей нет. Но как профессионалы мы должны стремиться к тому, чтобы контролю качества ничего не досталось.
• Профессионал — это командный игрок. Он отвечает за результат всей команды, а не только за свою работу. Профессионалы помогают друг другу, учат друг друга, учатся друг у друга и даже прикрывают друг друга при необходимости. Когда один участник команды спотыкается, другие вступаются за него, зная, что когда-нибудь им самим понадобится прикрытие.
• Профессионал не приемлет длинных списков дефектов. Огромный список дефектов — это признак неряшливой работы. Системы, в которых система управления дефектами содержит тысячи записей, — это трагедия беспечности. Более того, в большинстве проектов сама потребность в автоматизированной системе управления дефектами есть симптом беспечности. Только очень крупные системы могут иметь такое большое количество ошибок, что для управления ими требуется автоматизация.
• Профессионал поддерживает порядок. Он гордится своим мастерством. Его код понятен, хорошо структурирован и легко читается. Профессионалы следуют оговоренным стандартам и лучшим практикам. Они никогда, ни при каких обстоятельствах не работают впопыхах. Представьте себе, что вы можете покинуть собственное тело и наблюдать, как врач делает вам операцию на открытом сердце. У этого врача есть крайний (в буквальном смысле) срок завершения работы. Он должен закончить операцию до того, как аппарат искусственного сердца повредит слишком много кровяных клеток в вашем организме. Как, по-вашему, он должен себя вести? Вы бы хотели, чтобы он вел себя как типичный программист, пишущий код в спешке и беспорядке? Хотите ли вы услышать от него: «Как-нибудь потом все это исправлю»? Или все же он должен тщательно придерживаться правил своей науки, рассчитывать время и быть уверенным, что избранный им подход — лучший из доступных ему? Чего хотите вы — беспорядка или профессионализма?
Профессионалы обладают чувством ответственности. Они отвечают за собственную карьеру. Они отвечают за правильную работу своего кода. Они отвечают за уровень своего мастерства. Они не отказываются от своих принципов, когда на них давят сроки. На самом деле, когда давление растет, профессионалы еще крепче держатся за тот порядок, который считают правильным.
Держите все в системе управления версиями
Диомидис Спинеллис
Храните все, что касается любых ваших проектов, в системе управления версиями. Необходимые для этого ресурсы уже имеются: бесплатные инструменты типа Subversion, Git, Mercurial и CVS, вдоволь дискового пространства, дешевые и мощные серверы, повсеместный доступ в Интернет и даже службы хостинга проектов. После того как вы установили систему управления версиями, сохранить ваши труды в репозиторий очень просто: достаточно лишь выполнить соответствующую команду в чистом каталоге с кодом. А освоить нужно всего две новые основные операции: запись (commit) в репозиторий изменений, сделанных вами в коде, и обновление (update) вашей рабочей версии проекта до той, которая находится в репозитории.
После того как проект помещен в систему управления версиями, можно без труда просмотреть его историю, узнать, кто написал каждый фрагмент кода, и обратиться к конкретной версии файла или проекта с помощью уникального идентификатора. А что еще важнее — теперь вы можете делать рискованные изменения в коде, и больше не нужно оставлять закомментированный код на случай, если он потребуется в будущем. Ведь старая версия надежно хранится в репозитории. Можно (и нужно) помечать (tag) стабильные версии понятными вам именами, чтобы потом быстро получить именно ту версию, которая работает у вашего клиента. Можно создавать отдельные ветви (branches) и разрабатывать их параллельно: в большинстве проектов есть активно разрабатываемая ветвь и одна или несколько ветвей более ранних версий, для которых осуществляется активная поддержка.