어떤 시점에서 구성 파일이 프로그래밍 언어가됩니까?

나는 한동안 구성 파일과 코드와의 관계에 대해 고민해 왔으며 바람의 날과 방향에 따라 내 의견이 바뀌는 것 같습니다. Lisp를 배우면서 처음 얻은 깨달음으로 계속 돌아 오지만, 데이터와 코드 사이에는 거의 차이가 없습니다. 이것은 구성 파일의 경우 두 배로 사실입니다. 올바른 관점에서 보면 Perl 스크립트는 perl의 구성 파일에 불과합니다. 이는 QA 및 구성 파일 변경을 담당해야하는 분과 같은 작업에 상당히 큰 결과를 초래하는 경향이 있습니다.

구성 파일에서 완전한 언어로의 이동은 일반적으로 느리고 일반적인 시스템을 갖고 자하는 욕구에 의해 주도되는 것 같습니다. 대부분의 프로젝트는 로그 작성 위치, 데이터 검색 위치, 사용자 이름 및 비밀번호 등과 같은 몇 가지 구성 항목으로 작게 시작하는 것 같습니다. 작업의 타이밍과 순서가 제어되기 시작하고 필연적으로 누군가 로직을 추가하기를 원합니다 (예 : 머신이 X이면 10을 사용하고 머신이 Y이면 15를 사용). 특정 시점에서 구성 파일은 도메인 특정 언어가되고 그 언어는 제대로 작성되지 않습니다.

이제 무대를 설정하기 위해 뛰어 들었으므로 여기에 내 질문이 있습니다.

1. 구성 파일의 진정한 목적은 무엇입니까?
2. 구성 파일을 단순하게 유지해야합니까?
3. 개발자, 사용자, 관리자 등의 변경을 책임 져야하는 사람은 누구입니까?
4. 소스를 제어해야합니까 (질문 3 참조)?

앞서 말했듯이 이러한 질문에 대한 제 답변은 계속 바뀌지 만 지금은 다음과 같이 생각하고 있습니다.

1. 프로그래머가 아닌 사람이 대량의 동작을 빠르게 변경할 수 있도록
2. 예, 거칠지 않은 것은 코드에 있어야합니다.
3. 사용자는 구성 파일을 담당해야하며 프로그래머는 구성 파일과 애플리케이션을보다 세밀하게 제어 할 수있는 코드 사이의 구성 계층을 담당해야합니다.
4. 아니요,하지만 더 미세한 중간 레이어는

매우 흥미로운 질문입니다!

저는 설정 파일이 매우 빠르게 본격적인 프로그램이 될 수 있다는 사실에 전적으로 동의하기 때문에 설정 파일을 매우 간단한 "key = value"형식으로 제한하는 경향이 있습니다. 예를 들어, OpenSER를 "구성"하려고 시도한 사람은 누구나 구성이 아니라 (고통스러운) 프로그래밍이라는 느낌을 알고 있습니다.

오늘날 상상할 수없는 방식으로 애플리케이션을 매우 "구성 가능"해야 할 때 정말 필요한 것은 플러그인 시스템 입니다. 다른 사람이 새 플러그인을 코딩하고 나중에 애플리케이션에 연결할 수있는 방식으로 애플리케이션을 개발해야합니다.

따라서 귀하의 질문에 답하려면 :

1. 구성 파일의 진정한 목적은 무엇입니까?

   애플리케이션을 설치할 사람들이 호스트 이름, 스레드 수, 필요한 플러그인 이름 및 해당 플러그인의 배포 매개 변수와 같은 배포 관련 매개 변수를 사용할 수 있도록 허용하려면 이 원칙의 예에 대한 FreeRadius의 구성) 등. 확실히 비즈니스 로직을 표현할 장소가 아닙니다.

2. 구성 파일을 단순하게 유지해야합니까?

   명확히. 당신이 제안했듯이, 설정 파일의 "프로그래밍"은 끔찍합니다. 나는 그것을 피해야한다고 믿는다.

3. 개발자, 사용자, 관리자 등의 변경을 책임 져야하는 사람은 누구입니까?

   일반적으로 애플리케이션을 배포하는 관리자를 말합니다.

4. 소스를 제어해야합니까 (질문 3 참조)?

   저는 일반적으로 구성 파일 자체를 소스 제어 하지 않지만 모든 매개 변수와 기본값, 작업을 설명하는 주석을 사용하여 템플릿 구성 파일을 소스 제어합니다. 예를 들어 구성 파일의 이름이 database.conf이면 일반적으로 라는 파일을 소스 제어합니다 database.conf.template. 물론 저는 개발자로서 제가하는 일에 대해 이야기하고 있습니다. 관리자로서 각 설치에 대해 선택한 실제 설정을 소스 제어하고 싶을 수 있습니다. 예를 들어, 우리는 수백 대의 서버를 원격으로 관리하고 그 구성을 추적해야합니다. 우리는 소스 제어를 사용하기로 선택했습니다.

편집하다: 위의 내용이 대부분의 응용 프로그램에 해당한다고 생각하지만 물론 예외는 항상 있습니다. 예를 들어 애플리케이션은 사용자가 복잡한 규칙을 동적으로 구성하도록 허용 할 수 있습니다. 대부분의 이메일 클라이언트는 사용자가 이메일 관리에 대한 규칙을 정의 할 수 있도록합니다 (예 : " 'john doe'에서 온 모든 이메일은 To : 필드에 포함되지 않은 이메일은 삭제되어야합니다."). 또 다른 예는 사용자가 새롭고 복잡한 상업 제안을 정의 할 수있는 응용 프로그램입니다. 또한 사용자가 복잡한 데이터베이스 보고서를 작성할 수있는 Cognos와 같은 애플리케이션에 대해 생각할 수도 있습니다. 이메일 클라이언트는 사용자에게 규칙을 정의 할 수있는 간단한 인터페이스를 제공 할 것이며 이것은 복잡한 구성 파일 (또는 약간의 코드)을 생성합니다. 반면에 상업 오퍼에 대한 사용자 정의 구성은 구조화 된 방식으로 데이터베이스에 저장 될 수 있습니다 (단순한 키 = 값 구조도 코드 일부도 아님). 그리고 일부 다른 애플리케이션은 사용자가 파이썬이나 VB 또는 다른 자동화 가능 언어로 코딩 할 수도 있습니다. 즉 ... 마일리지가 다를 수 있습니다.

확인. 정말 간단한 구성을 원하는 사용자가있을 것입니다. 사용자에게 제공해야합니다. 동시에 "이것을 추가 할 수 있습니까? 구성 파일에서 어떻게합니까?"라는 요청이 계속 발생합니다. 두 그룹을 모두 지원할 수없는 이유를 모르겠습니다.

현재 작업중인 프로젝트는 구성 파일에 Lua를 사용합니다. Lua는 스크립팅 언어이며이 시나리오에서 매우 잘 작동합니다. 기본 구성 의 예를 사용할 수 있습니다 .

주로 key = value 문이며, 여기서 value는 Lua의 내장 유형 중 하나 일 수 있습니다. 가장 복잡한 것은 목록이며, 실제로 복잡하지 않습니다 (단지 구문 문제입니다).

이제 나는 누군가 시작할 때마다 서버의 포트를 임의의 값으로 설정하는 방법을 묻는 사람을 기다리고 있습니다.

최근에 저는 프로젝트를 진행하고 있었는데 이전에는 다음과 같은 형식 중 매우 간단한 구성 파일이었던 내 구성 파일 내에 조건문을 포함하고 싶다는 것을 깨달았습니다.

key = val
key2 = val
name = `hostname`

아주 조심스럽게 작성하지 않으면 유용 할 수있는 유연성을 허용 할 수 없었기 때문에 저는 작은 언어를 작성하고 싶지 않았습니다.

대신 나는 두 가지 형태를 갖기로 결정했습니다.

1. 파일이 "#!"로 시작하는 경우 실행 가능했고 실행 결과를 구문 분석했습니다.

2. 그렇지 않으면 그대로 읽었습니다.

이것은 이제 사람들이 다음과 같은 "구성 파일"을 작성하도록 허용 할 수 있음을 의미합니다.

 #!/usr/bin/perl
if ( -x /bin/foo ) 
{
   print <<EOF;
foo=me
bar=you
EOF
}
else
{
   print <<EOF;
foo=bar
bar=foo
EOF
}

이렇게하면 사용자가 사용하기를 원할 경우 동적 구성 파일의 성능을 얻을 수 있으며, 내 미니 언어를 작성할 필요가없는 단순함을 얻을 수 있습니다.

모든 (충분히 오래 지속되는) 구성 파일 스키마는 결국 프로그래밍 언어가됩니다. 설명하는 모든 의미로 인해 구성 파일 디자이너는 자신이 프로그래밍 언어를 작성하고 있다는 것을 깨닫고 그에 따라 계획을 세우는 것이 현명합니다.

구성 파일에 대한 철학이 다릅니다. 애플리케이션 실행 방법에 대한 데이터는 여전히 data 이므로 코드가 아닌 데이터 저장소에 속합니다 (구성 파일 IMO는 코드 임). 최종 사용자가 데이터를 변경할 수 있어야하는 경우 애플리케이션은이를위한 인터페이스를 제공해야합니다.

데이터 저장소를 가리키는 데만 구성 파일을 사용합니다.

프로그래밍 언어로 간주되는 것을 정의하기 위해 계산 이론으로 전환 할 수 있습니다. 구성 파일 형식이 Turing Complete 이면 합리적으로 프로그래밍 언어로 간주됩니다. 이 정의에 따라 Sokoban 수준을 설명하는 파일 형식 이 프로그래밍 언어로 간주됩니다 ( 여기 참조 ). 일반 문법 및 푸시 다운 오토마타 와 같이 계산할 수있는 Turing Complete 아래에는 다른 수준의 복잡성이 있습니다 .

그것을 보는 또 다른 방법은 많은 구성 파일이 데이터 마크 업 만 가능하지만 적절한 프로그래밍 언어는 알고리즘 을 구현할 수 있어야한다는 것 입니다. 예를 들어 JSON은 구성 파일 형식이고 ECMA Script는 프로그래밍 언어입니다.

내 생각은 다음과 같습니다.

1. 애플리케이션의 런타임 동작을 쉽게 수정할 수 있도록합니다. 이것은 필요에 따라 프로그래머 또는 비 프로그래머가 될 수 있습니다. 이것은 개발 중에있을 수 있지만, 저는 종종 어떤 시점에서 프로그램을 더 유연하게 만드는 데 도움이되는 방법으로 구성 파일을 봅니다.

2. 예. 런타임의 다양한 동작을 제어하기 위해 다양한 옵션이 필요할 수 있다는 제약을 감안할 때 구성 파일은 가능한 한 간단해야한다고 생각합니다. 구성 설정을 그룹화하고 가능한 한 단순화하는 것을 선호합니다.

3. 변경 내용과 이유에 따라 다릅니다. 사용자가 변경하려는 경우 세부 사항에서 숨길 수있는 프런트 엔드를 만들어야합니다. 일반적으로 비 개발자에게도 마찬가지입니다.

4. 나는 종종 "기본"구성을 소스 제어하지만 실제 런타임에 대해 시스템별로이를 재정의하는 방법이 있습니다.

구성 파일에 논리를 추가하는 것에 관해서는 이것을 피하고 싶습니다. 애플리케이션의 로직에서 구성 파일 스위치를 사용하는 것이 더 낫다고 생각합니다. 구성 파일의 동작은 내 경험상 유지 관리 및 이해 부족으로 이어집니다. 구성 파일을 가능한 한 단순하게 유지하는 것이 좋습니다.

나는이 질문의 전제에 동의하는 경향이 있습니다. 나는 이것이 일어날 것이라고 일찍 예측함으로써 문제에 빠지지 않기 때문에 절대로 내 구성 시스템을 롤링 하지 않습니다 .

• 운영 체제의 구성 기능 (예 : plist, gconf 또는 적절한 것)을 사용합니다.
• 또는 기성품 INI 파서와 같은 것으로 처리 할 수있는 간단한 플랫 파일입니다.
• 총알을 물어 뜯고 가벼운 언어 파서 (일반적으로 lua, 때로는 tcl)를 애플리케이션에 연결합니다.
• 또는 SQLite 또는 유사한 관계형 데이터베이스에 데이터를 저장합니다.

그리고 내가 내린 결정에 따라 살기 위해 자신을 사임하거나, 만약 내가 할 수 없다면, 애플리케이션에 더 적합한 위의 선택 중 하나를 사용하도록 리팩토링하십시오.

요점은 자체 개발 구성 솔루션을 사용할 이유가 없다는 것입니다. 우선, 사용자가 새로운 애플리케이션 별 구성 형식을 배우는 것이 더 어렵습니다. 다른 하나는 기성 솔루션을 사용할 때 무료로 제공되는 모든 버그 수정 및 업데이트의 이점을 누릴 수 있습니다. 마지막으로, 기능 크립은 휴식을 취합니다. 왜냐하면 실제로 주요 점검을 수행하지 않고는 기능을 하나 더 추가 할 수 없기 때문입니다. 왜냐하면 구성 시스템이 처음부터 실제로 손에 들어 가지 않기 때문입니다.

팀의 다른 개발자와 동의하는 것에 달려 있습니다. 구성 파일을 구성 파일처럼 사용하고 있거나 모델 기반 응용 프로그램을 만들고 있습니다.

구성 파일이 프로그래밍 언어가되는 현상 :

• 이름 = 값 쌍이 서로 의존하기 시작합니다.
• 흐름 제어가 필요하다고 느낍니다 (예 : (이것)가 그것보다 )
• 응용 프로그램을 사용하는 대신 추가 개발을 수행하려면 구성 파일에 대한 문서가 필수적입니다.
• 구성의 값을 읽기 전에 컨텍스트가 있어야합니다 (즉, 값은 구성 파일 자체의 외부 항목에 따라 다릅니다).

구성 파일은 항상 추악하고 비논리적 인 "완전한 프로그래밍 언어"가됩니다. 좋은 프로그래밍 언어를 설계하려면 기술과 기술이 필요하며, 프로그래밍 언어로 전환 된 구성 언어는 끔찍한 경향이 있습니다.

좋은 접근 방식은 python 또는 ruby와 같이 멋지게 설계된 언어를 사용하고이를 사용 하여 구성을위한 DSL 을 만드는 것 입니다. 이렇게하면 구성 언어가 표면적으로는 단순하지만 실제로는 완전한 프로그래밍 언어가 될 수 있습니다.

"유창한 인터페이스"로의 이동을 고려할 때 귀하의 질문이 매우 관련이 있다고 생각합니다. 많은 개발자들이 XML 구성 응용 프로그램과 관련하여 "빛을 보았습니다". XML을 사용하는 것은 매우 장황하고 올바르게 편집하기 어려울 수 있습니다 (특히 스키마가 제공되지 않은 경우). 유창한 인터페이스를 통해 개발자는 일반 텍스트 구성 파일 (또는 명령 줄 매개 변수)의 일부 키-값 쌍을 사용하여 도메인 별 언어로 응용 프로그램을 구성 할 수 있습니다. 또한 테스트 등을 위해 응용 프로그램의 새 인스턴스를 매우 쉽게 설정하고 구성 할 수 있습니다.

귀하의 질문에 대한 제 답변은 다음과 같습니다.

• 구성 파일의 진정한 목적은 무엇입니까?

구성 파일은 사용자가 런타임에 프로그램의 동작을 사용자 정의 할 수 있도록하는 방법입니다.

• 구성 파일을 단순하게 유지해야합니까?

이상적으로는 구성 파일이 최소한 프로그램을 구성하기위한 유창한 인터페이스로 보완되어야한다고 생각합니다 (이는 여러 측면에서 유용합니다). 구성 파일이 필요한 경우 키-값 쌍 외에는 매우 간단하게 유지해야합니다.

• 개발자, 사용자, 관리자 등의 변경을 책임 져야하는 사람은 누구입니까?

이에 대한 답은 조직에 달려 있다고 생각합니다. 소프트웨어가 올바르게 구성되었는지 확인하는 것은 소프트웨어를 배포하는 사람의 책임이어야합니다.

• 소스를 제어해야합니까 (질문 3 참조)?

다른 사람에게서이 대답을 훔칠 것입니다. :) 소스 제어에 템플릿 구성을 저장하고 각 로컬 사용자의 요구에 맞게 수정하는 아이디어가 마음에 듭니다. 한 개발자의 구성 파일이 다른 개발자의 악몽 일 가능성이 있으므로 사용자에 따라 달라지는 내용은 소스 제어에서 제외하는 것이 가장 좋습니다. 템플릿이 있으면 애플리케이션을 배포하는 사람 (또는 다른 개발자)이 구성 파일에 유효한 값을 정확히 볼 수있는 좋은 방법입니다.

구성 파일 이 코드 인 파이썬 프로그램을 보았습니다 . 특별한 작업 (조건부 등)을 할 필요가 없다면 다른 구성 스타일과 크게 다르지 않습니다. 예를 들어 다음 config.py과 같은 파일 을 만들 수 있습니다 .

num_threads = 13
hostname = 'myhost'

INI 파일에 비해 사용자에게 부담이되는 유일한 것은 문자열 주위에 ''를 넣어야한다는 것입니다. 다른 통역 언어에서도 같은 일을 할 수 있다는 것은 의심 할 여지가 없습니다. 필요한 경우 구성 파일을 복잡하게 만들 수있는 무제한의 기능을 제공하여 사용자를 놀라게 할 수 있습니다.

예, 구성 파일은 간단해야합니다. 그들은 '논리'자체를 포함하지 않아야합니다. 조건문 전체가 아니라 if 문에있는 표현식 목록으로 생각하십시오.

사용자가 응용 프로그램 내에서 코딩 된 옵션 중 사용할 옵션을 결정할 수 있도록하기위한 것이므로 복잡하게 만들려고하지 마십시오. 결국에는 자멸 할 수 있습니다. 간단한 구성 파일을 작성하게 될 수도 있습니다. 그렇지 않으면 원래 구성 파일을 구성하는 방법을 제어합니다!

Microsoft에서 "Oslo"작업의 목적 중 하나는이 문제의 해결을 허용하는 것입니다 (필수 사항은 아님).

1. 응용 프로그램은 포함 된 모든 새 구성 요소의 모델과 함께 제공됩니다. 또한 기존 모델을 사용합니다. 예를 들어 웹 서비스를 포함 할 수 있으므로 웹 서비스의 시스템 모델을 재사용 할 수 있습니다.
2. 모델에는 도구가 텍스트 또는 그래픽으로 액세스 할 수있는 충분한 정보를 포함하여 모델을 설명하는 메타 데이터가 포함됩니다.
3. 모델의 일부는 "구성"에 해당합니다.

이것은 오늘날의 구성 파일에 해당하는 내용이 구성의 텍스트 및 그래픽 편집을 모두 지원할 수있을만큼 풍부 할 수 있음을 의미합니다. 그래픽 도구는 "Oslo"(코드 명 "Quadrant")와 함께 제공됩니다.

나는 반대자가 될 것이고 그것이 XML로 표현 될 수있는 것보다 더 많은 것을 구현할 때 유일한 언어라고 제출할 것이다. 또는 XML이 언어로 간주되는 경우.

또는 대부분의 구성 파일을 클래스로 생각할 수 있지만 속성 만 있고 메서드는 없습니다. 그리고 방법 없이는 그것이 언어라고 생각하지 않습니다.

궁극적으로 "언어"는 삐걱 거리는 추상화이지만 예, 가장자리는 모호합니다.

우리 애플리케이션의 코드는 덜 중요해집니다. 스크립팅이 있습니다. 클래스, 메서드, 메서드 인수 및 속성의 동작을 정의하는 모든 종류의 속성이 있습니다. 사용자는 데이터베이스 트리거 및 데이터베이스 제약 조건을 정의 할 수 있습니다. 매우 복잡한 구성 파일이있을 수 있습니다. 때때로 사용자는 XSLT 스타일 시트를 정의하여 입력 및 출력을 조작 할 수 있습니다. 시스템을 개방 (SOA)해야하기 때문입니다. 또한 복잡한 구성이 필요한 BizzTalk와 같은 것들이 있습니다. 사용자는 복잡한 워크 플로를 정의 할 수 있습니다.

이 복잡한 환경을 처리하려면 더 나은 코드를 작성해야하므로 애플리케이션 코드가 더 중요해집니다.

저는 특히 데몬의 경우 구성 파일로 파이썬 프로그램을 사용하는 것을 좋아합니다. "구성 포트"를 제외하고 데몬을 구성에서 완전히 비우는 방법을 선호합니다. 그런 다음 python 프로그램은 데몬에 연결하고 데몬에서 객체를 만들고 함께 연결하여 원하는 구성을 만듭니다. 모든 것이 설정되면 데몬은 자체적으로 실행할 수 있습니다. 물론 장점은 구성 파일을 작성하기위한 완전한 프로그래밍 언어를 얻고 이미 다른 프로그램에서 데몬과 대화 할 수있는 방법이 있으므로 디버깅 및 통계를 얻는 데 사용할 수 있다는 것입니다. 가장 큰 단점은 언제든지 들어오는 다른 프로그램의 메시지를 처리해야한다는 것입니다.

구성 파일 : "내 목적은 무엇입니까?"
당신 : "버터 구성."
구성 파일 : "Ok ..."
구성 파일 : "내 목적은 무엇입니까?"
당신 : "당신은 버터를 구성합니다."
구성 파일 : "오 마이 갓."

1. 구성 파일의 "진정한 목적"은 없습니다. 귀하의 응용 프로그램에 적합한 것이 무엇이든간에. 일반적으로 시스템간에 다르거 나 애플리케이션 실행 중에 변경되지 않는 항목은 구성 파일에 있어야합니다. 다른 서비스의 기본값, 포트 및 주소는 모두 훌륭한 후보입니다. 키와 시크릿도 훌륭한 후보이지만 보안상의 이유로 일반 구성과 별도로 처리해야합니다. 구성 파일의 목적이 빠른 변경을 허용하는 데 동의하지 않습니다. 목적은 응용 프로그램 설정에서 유연성을 허용하는 것이어야합니다. 구성 파일이 유연성을 허용하는 빠르고 쉬운 방법이라면 훨씬 더 좋습니다. 그러나 구성 파일이 자주 변경 되지 않도록 의도 해서는 안됩니다 .

2. 예, 아니오. 응용 프로그램의 코드를 단순하게 만들어야합니까? 예. 작성하는 모든 내용을 간단하고 요점으로 만들어야합니다. 필요 이상으로 복잡하지 않습니다. 구성도 마찬가지입니다. 그러나 이것은 매우 응용 프로그램에 따라 다릅니다. 구성을 "너무 복잡"하게 만들 수 있으므로 구성에 있어야하는 내용을 하드 코딩하는 것은 잘못된 설계입니다. 사실, "간단하게 유지"하려는 것이 구성 파일이 결국 엉망이되는 이유입니다. 때로는 가장 간단한 방법은 모듈화하는 것입니다. 이것이 여러분의 설정 파일이 끔찍한 설정 언어가 아닌 잘 알려진 범용 프로그래밍 언어로 작성되어야하는 이유입니다 (읽기 : 모든 "설정 언어"suck ).

3. 다시 말하지만, 구성 파일을 수정해야하는 사람은 완전히 응용 프로그램에 따라 다릅니다. 하지만 저는 miniquark에 동의합니다. 애플리케이션을 배포하는 사람이 구성을 담당해야합니다.

4. 소스 제어가 가능한 모든 것. 소스 제어는 훌륭합니다. 항목을 매우 쉽게 롤백 할 수 있으며 변경 한 내용에 대한 전체 기록과 변경 한 사람에 대한 기록이 있습니다. 그래서 왜 안돼?