개발자 스크립트를 관리하는 올바른 방법은 무엇입니까?

개발자는 작업에 도움이되는 스크립트를 만듭니다. 예를 들어 특정 매개 변수를 사용하여 Maven을 실행하거나 개발 과정에서 발생하는 불필요한 백그라운드 작업을 종료하거나 특정 서버에 연결합니다. 스크립트는 핵심 빌드 스크립트가 아니며 Continuous Integration 서버에서 사용되지 않습니다.

그들을 관리하는 가장 좋은 방법은 무엇입니까? 디렉토리 (아마도 /scripts)에 넣고 Git에 체크인하려면? 일부 파일 서버에서 별도로 유지 관리하려면?

그것들을 소스 코드로 취급하는 것에 대한 주장은 그것들이 소스이고 변경 될 수 있다는 것입니다. 이를 수행하지 않는 이유는 단지 보조 도구 일 뿐이며 모든 개발자가 특정 스크립트 (예 : 일부 개발자가 Windows에서 작업하는 Linux 관련 스크립트)가 필요하지는 않다는 것입니다.

일반적으로 이러한 스크립트는 버전 제어의 항목 (예 : 파일 경로)에 의존하기 때문에 개발자 스크립트도 버전 제어로 이동합니다.

이러한 스크립트가 버전 화되어 있으면 모든 개발자가 모든 개발자가 자신의 스크립트를 작성하지 않도록해야합니다.

또한 이러한 스크립트의 버그 수정 또는 개선 사항은 버전 제어를 통해 모든 개발자에게 자동으로 배포됩니다.

@simon의 답변 외에도.

소프트웨어 엔지니어링의 모든 것이 프로그래밍, 디자인 또는 모델링에 관한 것은 아닙니다. 근무일 동안 지속적으로 수행하는 수많은 작업이 있습니다. IDE 외부에서 프로젝트를 빌드하는 것에 대해 이미 언급 했지만 더 많은 것이 있습니다.

경험이 많고 적극적인 개발자는 이러한 작업을 자동화하는 경향이 있습니다. 일부는 이러한 작업이 SDLC의 일부 가되고 손으로하는 일 이 지루하고 오류가 발생하기 쉬운 도구를 구축 하기까지합니다 . 프로그램은 아무리 지루한 지에 관계없이 반복적 인 일을하는 데 능숙합니다. 우리 인간 은 그렇게 좋지 않습니다.

이 도구 / 스크립트에는 다른 긍정적 인 부작용이 있습니다

1. 생산력
2. 지식의 이전
3. 자율성 (이민자)

예, 스크립트는 SCM에 있어야하며 개발자 도구 상자에 하나 이상의 도구 여야합니다.

폴더에 관해서는 /scripts중요하지 않습니다. 간단하게하기 위해 스크립트에 선언 된 모든 경로 가 프로젝트 폴더와 관련 되도록 프로젝트의 루트 디렉토리에 두었습니다 . 외부 폴더 나 파일에 액세스해야하는 경우 소프트 링크를 만듭니다 .

스크립트를 SCM에 체크인하기 전에 고려해야 할 사항.

• 보안을 위해 반드시 스크립트없이 하드 코딩 한 자격 증명을 - 이상적으로, 스크립트가 아니라 매개 변수화한다 -

• 실행 취소 할 수없는 명령 (가장 일반적인 rm -rf) 을 실행하는 등 스크립트가 시스템에 이상한 일을하지 않도록하십시오 .

• 이것들이 프로젝트 소스의 일부가되었으므로 문서화에 감사드립니다.

• 스크립팅은 로켓 과학이 아닙니다. 스크립트를 간결하게 만드십시오. 대신 한 그들 모두를 지배 ... 그리고 어둠 속에서 바인드 그들합니다 , 더 작고 간결합니다. 마치 SRP를 적용하는 것처럼.

좀 더 부정적인 의견을 제시 할 것입니다. 한편, 일반적이고 효과적이며 유용한 개발자 스크립트는 물론 다른 개발자와 공유해야하며,이를 수행하는 가장 좋은 방법은 동일한 저장소에있는 코드와 함께 배치하는 것입니다.

그러나 스크립트를 커밋하는 데 대한 높은 기준을 설정했습니다. 스크립트는 소프트웨어 자체와 마찬가지로 코드입니다. 즉, 다른 코드와 유사하게 처리해야합니다.

• 코드 검토 통과
• 가능하면 테스트 및 자동화
• 코드베이스를 변경할 때 고려할 사항 (특히, 많은 개발자가 스크립트를 사용하는 경우 스크립트를 손상시키는 변경을하면 많은 문제가 발생 함)
• 유지 (우선 순위, 시간, 문서화 등 모든 것을 포함)

소프트웨어 자체보다 스크립트에 더 많이 적용되는 여러 가지 추가 고려 사항이 있습니다.

• 무엇보다도 조직과 이해 관계자가 개발자의 삶을 편하게 해 줄 스크립트를 유지하는 데 투자하도록 설득하는 것이 훨씬 더 어렵습니다. 즉, 위의 기준을 충족하기가 더 어렵다는 것을 의미합니다. 사용자 환경에 적합한 스크립트를 작성하는 것이 쉽지만 매개 변수화하고 안정적으로 만들고 문서화하는 데 훨씬 더 많은 시간이 걸립니다. 이것은 개발자가 스크립트를 최신 상태로 유지하는 것을 정당화 할 수 없다면 스크립트가 죽은 코드가 될 수 있고 될 것임을 의미합니다.
• 여러 개발자가 스크립트를 유지 관리하기위한 복잡한 스크립트에 익숙하거나 여러 개발자가 코드의 소유권을 느끼는 경우는 거의 없습니다. 원래 개발자가 떠날 때 다른 사람이 소유권을 가져 오는 것을 찾는 것이 어려울 수 있습니다 (그리고 스크립트 작동 방식을 배우는 시간을 찾고 정당화하는 것이 훨씬 어려울 수 있음).
• 스크립트가 개발자 시스템과 상호 작용하고 어떤 방식 으로든 환경을 구축 할 가능성이 훨씬 높습니다. 또한 환경이 다른 여러 개발자가있을 가능성이 큽니다. 스크립트가 제대로 유지 관리되지 않았거나 모퉁이가 고려되지 않아 환경을 망쳐 놓는 경우 소프트웨어의 야간 빌드를 중단하는 것이 아니라 개발자가 하루 동안 작업을 수행하는 데 비용이 많이 듭니다. 환경을 정상으로 되돌립니다. 이것은 나쁜 혈액과 신뢰 상실을 유발할 수 있습니다.
• 스크립트는 종종 소프트웨어 자체의 외부에 있기 때문에 유지 관리가 어려울 수 있습니다. 스크립트가 자동화를 통해 실행되지 않는 경우 오래된 스크립트를 잊거나 잊어 버릴 수 있습니다.이 시점에서 스크립트가 죽은 코드가되어 누군가가 정리하는 데 시간이 걸리는 기술 부채 일뿐입니다.

요약하면 스크립트는 개별 개발자에게 매우 도움이 될 수 있지만 코드베이스 자체의 일부로 스크립트를 공유하는 것은 훨씬 어려운 작업이 될 수 있으며 해결되는 것보다 더 많은 문제를 일으킬 수 있습니다.