아직도 수동으로 go cli를 코딩하고 있습니까?

도움말 텍스트 "파일 제공 경로"가 세 번 나타납니다.

$ grep -1 'path to serve' OpenSesame_cliDef.go
        Port string // listening port
        Path string // path to serve files from
        Help bool   // show usage help
--
        flag.StringVar(&Opts.Path, "path", "./",
                "path to serve files from")
        flag.BoolVar(&Opts.Help, "help", false,
--

const usageSummary = "  -port\tlistening port (OPENSESAME_PORT)\n  -path\tpath to serve files from (OPENSESAME_PATH)\n  -help\tshow usage help (OPENSESAME_HELP)\n\nDetails:\n\n"

손으로 코딩하는 경우 첫 번째 항목이 생략될 가능성이 큽니다. 그러나 도움말 텍스트는 Path string 변수가 정확히 무엇인지 설명하는 데 도움이 되므로 유감입니다.

        Path string // path to serve files from

또한 손으로 코딩하는 경우 항상 처리하지 않으면 두 번째와 세 번째 발생이 매우 쉽게 동기화되지 않습니다.

이 모든 것은 DRY(Don't Repeat Yourself) 원칙을 위반합니다. 그것을 피하는 방법? 답은 다음 파일입니다.

"파일을 제공할 경로" 도움말 텍스트가 한 번만 정의되지만 자동으로 세 개의 서로 다른 적절한 위치에 배치됨을 볼 수 있습니다.

이것은 우리가 말하는 go cli 처리 코드 자동 생성입니다. 위의 두 파일을 보십시오. 어느 것이 유지 관리하기 더 쉽습니까? CLI 처리 코드 자동 생성 기능이 있으므로 다음에 CLI 처리를 다시 수행할 때 수동으로 코딩하지 마십시오.

이미 수동으로 작성된 CLI 처리 코드가 있는 경우 어떻게 합니까? 글쎄, 자동 생성으로 변환하는 것은 전혀 어렵지 않습니다. 다음은 두 가지 간단한 단계입니다.

• introduce config.go , 기존 코드에서 처리하는 기존 cli를 자동 생성된 config.go 파일로 포팅합니다.

• implemented -d, -c, & -help 새로 추가된 명령줄 플래그/매개변수에 대한 더 많은 비즈니스 로직 처리를 추가합니다.

매우 간단하고 땀이 전혀 나지 않습니다. 모두 자동 생성config.go 파일 덕분입니다.

자, 이제 how is the config.go file auto-generated ? all the following explanation borrowed from here

이 섹션에서는 프로그램이 생성되는 모든 단계를 살펴봅니다.

이것은 전체 Initialize -> Make use -> More changes to cli definitions 주기를 완료했습니다.

위에 인용된 위키Go command line flag handling code auto generation의 나머지 부분을 확인하십시오. 여기에서 동일한.yaml 구동 파일을 사용하여 go 표준flag 명령줄 처리 코드를 자동으로 처리할 수 있음을 알 수 있습니다. 생성되었지만 viper 및 cobra뿐만 아니라 set the argument values at three different levels을 수행할 수 있는 모든 기능을 갖춘 cli 코드까지 가능합니다.

따라서 Host 값을 설정하는 우선 순위는 가장 낮은 우선 순위에서 가장 높은 우선 순위입니다.

세 가지 다른 수준.