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

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

Жестко запрограммированные настройки подходят для небольших программ, но их становится сложнее поддерживать.

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

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

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

Когда с нами начинает работать новый разработчик, одна из его первых задач - запустить наши проекты на их новых компьютерах. Это разбивается на две задачи; клонирование репозитория на свой локальный компьютер, а затем настройка проекта для запуска на их компьютере. Если бы мы жестко запрограммировали наши настройки, плохому разработчику потребовались бы недели, чтобы запустить проект на своей локальной машине.

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

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

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

Очень важно правильно настроить конфигурацию.

Наша команда работает над проектами Node.js, Java или PHP. Каждый программный стек имеет один метод конфигурации. Под этим я подразумеваю, что все проекты Node.js настраиваются с использованием одного метода конфигурации, все проекты Java настраиваются с использованием одного метода конфигурации, а все проекты PHP настраиваются с использованием одного метода конфигурации.

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

Этот пост является первой из серии из четырех статей. В следующем посте этой серии мы подробно рассмотрим, как работает наш модуль конфигурации Node.js и как мы его используем.



А пока не стесняйтесь оставлять любые вопросы или отзывы в разделе комментариев ниже!