Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Саттер Герб. Стандарты программирования на С++. 101 правило и рекомендация - royallib.ru.doc
Скачиваний:
58
Добавлен:
11.03.2016
Размер:
715.24 Кб
Скачать

3. Используйте систему контроля версий Резюме

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

Обсуждение

Практически все нетривиальные проекты требуют командной работы и/или более недели рабочего времени. В таких проектах вы будете просто вынуждены сравнивать различные версии одного и того же файла для выяснения того, когда (и/или кем) были внесены те или иные изменения. Вы будете вынуждены контролировать и руководить внесением изменений в исходные файлы проекта.

Когда над проектом работают несколько разработчиков, они вносят изменения в проект параллельно, возможно, одновременно в разные части одного и того же файла. Вам нужен инструмент, который бы автоматизировал работу с разными версиями файлов и, в определенных случаях, позволял объединять одновременно внесенные изменения. Система управления версиями (version control system, VCS) автоматизирует все необходимые действия, причем выполняя их более быстро и корректно, чем вы бы могли сделать это вручную. И вряд ли у вас есть лишнее время на игры в администратора — у вас хватает и своей работы по разработке программного обеспечения.

Даже единственный программист нередко вынужден выяснять, как и когда в программу проникла та или иная ошибка. VCS, автоматически отслеживая историю изменений каждого файла, позволяет вам "перевести стрелки часов назад" и ответить не только на вопрос, как именно выглядел файл раньше, но и когда это было.

Не портите сборку. Код, сохраненный VCS, всегда должен успешно собираться. Огромное разнообразие инструментария данного типа не позволяет оправдать вас, если вы не используете одну из этих систем. Наиболее дешевой и популярной является CVS (см. ссылки). Это гибкий инструмент с возможностью обращения по TCP/IP, возможностью обеспечения повышенных мер безопасности (с использованием протокола ssh), возможностью администрирования с применением сценариев и даже графическим интерфейсом. Многие другие продукты VCS рассматривают CVS в качестве стандарта либо строят новую функциональность на ее основе.

Исключения

Проект, над которым работает один программист, причем не более недели, вероятно, в состоянии выжить и без применения VCS.

Ссылки

[BetterSCM] • [Brooks95] §11, §13 • [CVS]

4. Одна голова хорошо, а две — лучше

Резюме

Регулярно просматривайте код всей командой. Чем больше глаз — тем выше качество кода. Покажите ваш код другим и познакомьтесь с их кодом — это принесет пользу всем.

Обсуждение

Регулярное рецензирование кода другими членами команды приносит свои плоды.

• Повышение качества кода при доброжелательной критике другими.

• Выявление ошибок, непереносимого кода (если это важно) и потенциальных проблем, связанных с масштабированием проекта.

• Улучшение качества дизайна и реализации путем обмена идеями.

• Быстрое обучение новых членов команды.

• Разработка общих принципов в команде.

• Повышение уровня меритократии1, доверия, профессиональной гордости и сотрудничества в команде.

Во многих фирмах еще не столь популярны, как хотелось бы, вознаграждения за качество кода, а также какие-либо вложения времени или средств в его повышение. Надежд на кардинальное изменение ситуации мало, но все же изменения в этой области, пусть медленно, но происходят; в частности, это связано с вопросами надежности и безопасности программного обеспечения. Коллективное рецензирование кода помогает в решении этих вопросов, в дополнение к тому, что это отличный и к тому же бесплатный метод обучения сотрудников.

Даже если ваш работодатель не намерен заботиться о рецензировании кода, постарайтесь донести мысль о его необходимости до менеджеров (маленькая подсказка: покажите им эту книгу), и в любом случае организуйте такой обмен опытом. Затраченное на это время окупится сторицей. Сделайте рецензирование кода обязательной частью цикла разработки программного обеспечения в вашей команде.

Лучшие результаты дает оперативное рецензирование кода, разрабатываемого в настоящий момент. Для этого не требуется никакого формализма — достаточно простой электронной почты. При такой организации работы легче отслеживать ваши собственные действия и избегать дублирования.

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

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

Ссылки

[Constantine95] §10, §22, §33 • [McConnell93] §24 • [MozillaCRFAQ]