Единственный исполняемый файл
(В оригинале - One Binary)
Мне встречались проекты, в которых процесс сборки модифицировал исходный код с целью получить различные исполняемые файлы для различного окружения. Такой подход все только усложняет и добавляет риск того, что версии окажутся рассогласованными между собой. Такой подход приводит к получению нескольких практически идентичных копий ПО, каждую из которых нужно установить в корректное окружение. Слишком много движущихся частей в механизме повышают вероятность того, что что-нибудь где-нибудь пойдет не так.
Однажды я работал в команде, где изменение каждого свойства запускало полный процесс сборки, в результате тестерам значительную часть времени приходилось ждать, даже в случае незначительных изменений (и да, процесс сборки был, конечно же, очень долгим). На другом проекте, на котором я работал, было правило запуска процесса сборки с нуля для получения финальной версии – релиза, что означало то, что не было гарантии того, что клиент получал то же самое, что тестировали тестеры.
Правило же здесь простое: создавать единственную версию исполняемых файлов, с возможностью идентификации этой версии и продвижения ее по «линии жизни» проекта. А специфику среды сохранять непосредственно в среде окружения (в файле или папке, например)
Если у вас процесс сборки изменяет исходный код или сохраняет установки среды непосредственно в коде, это означает лишь то, что никто на этапе дизайне не продумал того, как разделить ядро приложения от платформо-зависимых деталей. Или даже хуже – команда знала, что и как надо делать, но приоритеты были расставлены так, что сделано этого не было.
Конечно же, бывают и исключения. Возможно, вам нужно будет делать сборку для различных окружений, имеющих очень серьезные отличия и ограничения. Однако эти исключения не применимы в большинстве случаев из серии «извлечь из базы, показать на экране и записать назад в базу». Или же вам приходится мириться с доставшимися в наследство проблемами, которые сложно исправить прямо сейчас. В таком случае вам нужно последовательно двигаться вперед, небольшими шагами, но начать движение надо как можно раньше.
И еще одна важная деталь. Сохраняйте установки среды окружения в системе контроля версий наравне с кодом. Нет ничего хуже, чем повредить конфигурацию и не быть в состоянии посмотреть, какое именно изменение все сломало. Информацию об окружении лучше помещать отдельно, поскольку она меняется с другой частотой и по другим причинам по сравнению с кодом. Некоторые команды используют распределенные системы контроля версий для этого (подобные bazaar и git), поскольку в них проще поместить изменения непосредственно из рабочего окружения (что рано или поздно, но неизбежно случается) назад в репозиторий.
Автор оригинала - Steve Freeman