나는 현재 더 큰 Bash 스크립트(내 오픈 소스 프로젝트)를 작업하고 있는데 엉망이 되기 시작했습니다. 논리를 함수로 나누고 가능한 경우 로컬 변수를 사용했으며 몇 개의 전역 변수만 선언했습니다. 그래도 유지 관리가 어려워집니다.
나는 스크립트를 여러 스크립트로 분할하고 이를 내 기본 스크립트에 소싱하는 것을 고려했습니다(다른 언어로 가져오는 것과 유사).
하지만 이것이 가능한 접근 방식인지 알고 싶습니다. 첫째, 여러 스크립트를 얻으면 스크립트 실행 시간이 심각하게 느려질 수 있고, 둘째, 배포가 더 어려워집니다.
그렇다면 이것이 좋은 접근 방식일까요? 다른 (오픈 소스) 프로젝트도 이 작업을 수행합니까?
답변1
예, 이것은 일반적인 관행입니다. 예를 들어 Unix 초기에는 다중 사용자 작업을 위한 부팅 단계를 통해 시스템을 안내하는 쉘 코드가 단일 파일이었습니다 /etc/rc. 오늘날 부팅 프로세스는 기능별로 구분된 많은 쉘 스크립트에 의해 제어됩니다. 필요에 따라 중앙 위치에서 가져온 공통 함수 및 변수. Linux 배포판, Mac 및 BSD는 모두 이 접근 방식을 다양한 수준으로 사용합니다.
답변2
쉘은 당시 작업에 적합한 도구였습니까? 코드 증가 문제를 경험한 개발자로서 저는 다시 작성하는 것에 대해 생각하는 대신 조각을 애플리케이션을 확장하려는 규모에 더 적합한 것으로 분리하는 것을 고려해야 한다고 말할 수 있습니다(예: Python, Ruby 또는 Perl) ?
Shell은 유틸리티 언어(스크립팅 언어)이므로 이 크기로 확장하기가 어렵습니다.
답변3
유지 관리가 더 쉬워지면 두 가지를 모두 수행할 수 있습니다. 쉽게 유지 관리할 수 있도록 논리적 부분으로 나눈 다음 Makefile을 작성하여 배포를 위해 모두 다시 정리하는 대신 포함 파일에서 출력 파일로 함수를 복사하는 빠른 스크립트를 작성할 수 있습니다. 해당 source줄을 삭제하거나 다음과 같은 사소한 작업을 수행합니다(탭 문자가 필요하므로 다시 탭해야 합니다 make).
all: myscript
myscript: includes/* body/*
cat $^ > "$@" || (rm -f "$@"; exit 1)
그러면 "소스" 버전(편집용)과 "바이너리" 버전(간단한 설치용)이 생성됩니다.
답변4
일반적이든 아니든, 콘센트 세트가 아닌 다른 것을 소싱하는 것이 좋은 생각이라고 생각합니다. 코드를 가져와서 실행하는 것은 혼란스럽고 환경 및 기타 변수 설정으로 인해 코드가 소스 코드에 크게 의존하게 되므로 재사용이 제한된다는 것을 알았습니다.
애플리케이션을 더 작고 독립적인 스크립트로 나누고 일련의 명령으로 실행하는 것이 더 좋습니다. 이렇게 하면 대화형 셸에서 각 개별 스크립트를 실행하고 각 명령 호출 사이에 파일, 로그 등을 검사할 수 있으므로 디버깅이 단순화됩니다. 단일 대규모 애플리케이션 스크립트는 디버깅이 완료된 후 일련의 명령을 실행하는 간단한 제어 스크립트가 됩니다.
더 작고 독립적인 스크립트 세트는 설치에 어려움을 겪었습니다.