구성 유효성 검사

계속 발생하는 일반적인 문제를 해결하는 새로운 CLI 도구를 사용하려고 합니다. 사용을 시작하기 전에 올바르게 구성하는 방법을 알아야 합니다. 운 좋게도 사이트에는 수많은 예제 구성이 있습니다. 예제 중 하나를 좋아하는 편집기에 복사하고 값을 변경합니다.

직접 구축해야 한다면 계획되지 않은 작업에 몇 주가 걸렸을 문제를 해결할 수 있는 완벽한 도구를 마침내 찾았습니다. 명령 프롬프트로 돌아가서 도구를 실행하면 짧은 오류 메시지가 표시됩니다.

* ERR: unexpected argument (undefined) expected uint

이상하다. 무언가를 잘못 입력했을 수 있으므로 돌아가서 구성을 검토합니다. 눈에 띄는 문제가 없으므로 문서로 다시 이동합니다. 몇 분 동안 예제를 읽고 구성과 비교한 후에 당황하게 됩니다.

도구의 github 저장소에서 오류 검색을 실행합니다. 문제에 결과가 없습니다. 리포지토리의 문제에 질문을 게시하거나 소스를 자세히 살펴보고 무엇이 잘못되었는지 확인할 수 있습니다. 구성 로더의 소스를 살펴보는 것이 더 빠를 것이라고 결정했습니다.

5분 이내에 문제를 최근 커밋까지 추적할 수 있었습니다. 변경 사항은 remoteHost 구성 옵션에 대한 별도의 필수 필드로 호스트 및 포트 번호를 분할합니다. remotePort를 추가하고 다시 시도하십시오. 이번에는 문제 없이 시작됩니다. 구식 문서에 약간 짜증이 났지만 여전히 도구에 감사합니다.

이 시나리오에서는 문제를 해결하는 데 15분도 채 걸리지 않았습니다. 사람들이 구성을 작동시키려고 노력하는 데 며칠 이상을 소비하는 것은 드문 일이 아닙니다. 특히 다양한 구성 파일 형식, 환경 변수 설정, 명령줄 인수 및 동적 구성을 지원하는 보다 복잡한 시스템의 경우.

애플리케이션 구성은 UI 상호작용과 동일하게 취급되어야 합니다. 사용하기 전에 유효성을 검사하고, 친숙한 오류 메시지에 컨텍스트를 제공하고, 지원되지 않거나 알 수 없는 추가 속성을 무시하는 대신 포착해야 합니다. 또한 앱이 실행 중인 최종 해결된 구성을 보려면 DEBUG 또는 상세 로깅 옵션이 지원되어야 합니다. 무엇이 잘못될 수 있는지 추측하여 스테이징 환경에서 변경 불가능한 구성 파일을 반복해서 재생성해야 하는 것보다 더 실망스러운 일이 거의 없습니다. 비밀이 로드되고 있습니까? 해당 환경 변수가 정적 구성 옵션보다 우선합니까? 실제로 로드되는 것은 무엇입니까?

* ERR: config 'remoteHost' failed validation - unexpected characters ":9093"
* ERR: config 'remotePort' missing required property

이것은 올바른 방향으로 사용자를 가리켰을 것입니다.

자체 구성 유효성 검사를 작성하는 대신 JSON 스키마와 같이 잘 확립된 표준을 고수하십시오. 앱에서 YAML을 사용하더라도 여전히 JSON의 상위 집합입니다.

JSON Schema Validators