Стандарты программирования на С++. 101 правило и рекомендация
Шрифт:
[Meyers97] §48 • [Stroustrup94] §2.6.2
2. Используйте автоматические системы сборки программ
Нажимайте на одну (единственную) кнопку: используйте полностью автоматизированные ("в одно действие") системы, которые собирают весь проект без вмешательства пользователя.
Процесс сборки программы "в одно действие" очень важен. Он должен давать надежный и воспроизводимый результат трансляции ваших исходных файлов в распространяемый
Мы встречались с организациями, где подобное требование игнорировалось. Некоторые полагают, что настоящий процесс сборки должен состоять в том, чтобы пощелкать мышью там и сям, запустить пару утилит для регистрации серверов COM/CORBA и вручную скопировать несколько файлов. Вряд ли у вас есть лишнее время и энергия, чтобы растрачивать их на то, что машина сделает быстрее и лучше вас. Вам нужна надежная автоматизированная система сборки программы "в одно действие".
Успешная сборка должна происходить молча, без каких бы то ни было предупреждений (см. рекомендацию 1). Идеальный процесс сборки должен выдать только одно журнальное сообщение: "Сборка успешно завершена".
Есть две модели сборки — инкрементная и полная. При инкрементной сборке компилируются только те файлы, которые претерпели изменения со времени последней инкрементной или полной сборки. Следствие: вторая из двух последовательных инкрементных сборок не должна перезаписывать никакие файлы. Если она это делает — по всей видимости, у вас в проекте имеется циклическая зависимость (см. рекомендацию 22), либо ваша система сборки выполняет ненужные операции (например, создает фиктивные временные файлы, чтобы затем просто удалить их).
Проект может иметь несколько видов полной сборки. Рассмотрите возможность параметризации процесса сборки при помощи таких важных параметров, как целевая архитектура, отладочная или коммерческая версии, вид пакета (программа-инсталлятор или просто набор файлов). Одни установки сборки могут давать только наиболее существенные исполнимые и библиотечные файлы, другие — добавлять к ним вспомогательные файлы, а окончательная сборка — создавать программу-инсталлятор, которая включает в себя все ваши файлы, файлы сторонних производителей и код инсталляции.
Со временем размер проекта обычно возрастает, растет и стоимость отказа от автоматизированной системы сборки. Если вы не используете ее с самого начала, вы теряете время и ресурсы. Все равно со временем потребность в такой системе станет непреодолимой, но при этом вы окажетесь под гораздо большим давлением, чем в начале проекта.
В больших проектах возможна даже специальная должность "хозяина сборки", который отвечает за работу этой системы.
[Brooks95] §13, §19 • [Dewhurst03] §1 • [GnuMake] • [Stroustrup00] §9.1
3. Используйте систему контроля версий
Как гласит китайская пословица, плохие чернила лучше хорошей памяти: используйте системы управления версиями. Не оставляйте файлы без присмотра на долгий срок. Проверяйте их всякий раз после того, как обновленные модули проходят тесты на работоспособность. Убедитесь, что внесенные обновления не препятствуют корректной сборке программы.
Практически все нетривиальные проекты требуют командной
Когда над проектом работают несколько разработчиков, они вносят изменения в проект параллельно, возможно, одновременно в разные части одного и того же файла. Вам нужен инструмент, который бы автоматизировал работу с разными версиями файлов и, в определенных случаях, позволял объединять одновременно внесенные изменения. Система управления версиями (version control system, VCS) автоматизирует все необходимые действия, причем выполняя их более быстро и корректно, чем вы бы могли сделать это вручную. И вряд ли у вас есть лишнее время на игры в администратора — у вас хватает и своей работы по разработке программного обеспечения.
Даже единственный программист нередко вынужден выяснять, как и когда в программу проникла та или иная ошибка. VCS, автоматически отслеживая историю изменений каждого файла, позволяет вам "перевести стрелки часов назад" и ответить не только на вопрос, как именно выглядел файл раньше, но и когда это было.
Не портите сборку. Код, сохраненный VCS, всегда должен успешно собираться. Огромное разнообразие инструментария данного типа не позволяет оправдать вас, если вы не используете одну из этих систем. Наиболее дешевой и популярной является CVS (см. ссылки). Это гибкий инструмент с возможностью обращения по TCP/IP, возможностью обеспечения повышенных мер безопасности (с использованием протокола ssh), возможностью администрирования с применением сценариев и даже графическим интерфейсом. Многие другие продукты VCS рассматривают CVS в качестве стандарта либо строят новую функциональность на ее основе.
Проект, над которым работает один программист, причем не более недели, вероятно, в состоянии выжить и без применения VCS.
[BetterSCM] • [Brooks95] §11, §13 • [CVS]
4. Одна голова хорошо, а две — лучше
Регулярно просматривайте код всей командой. Чем больше глаз — тем выше качество кода. Покажите ваш код другим и познакомьтесь с их кодом — это принесет пользу всем.
Регулярное рецензирование кода другими членами команды приносит свои плоды.
• Повышение качества кода при доброжелательной критике другими.
• Выявление ошибок, непереносимого кода (если это важно) и потенциальных проблем, связанных с масштабированием проекта.
• Улучшение качества дизайна и реализации путем обмена идеями.
• Быстрое обучение новых членов команды.
• Разработка общих принципов в команде.
• Повышение уровня меритократии [1] , доверия, профессиональной гордости и сотрудничества в команде.
1
Система, при которой положение человека в обществе определяется его способностями. — Прим. перев.