# Единственный исполняемый файл

(В оригинале - One Binary)

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

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

Правило же здесь простое: создавать единственную версию исполняемых файлов, с возможностью идентификации этой версии и продвижения ее по «линии жизни» проекта. А специфику среды сохранять непосредственно в среде окружения (в файле или папке, например)

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

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

И еще одна важная деталь. Сохраняйте установки среды окружения в системе контроля версий наравне с кодом. Нет ничего хуже, чем повредить конфигурацию и не быть в состоянии посмотреть, какое именно изменение все сломало. Информацию об окружении лучше помещать отдельно, поскольку она меняется с другой частотой и по другим причинам по сравнению с кодом. Некоторые команды используют распределенные системы контроля версий для этого (подобные bazaar и git), поскольку в них проще поместить изменения непосредственно из рабочего окружения (что рано или поздно, но неизбежно случается) назад в репозиторий.

Автор оригинала - [Steve Freeman](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Freeman)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/ru/thing_12.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.