최근에 함께 일하는 선임 개발자는 개발자가 최신 버전을 얻고 프로젝트의 일부로 주요 내부 라이브러리를 컴파일하도록 요구하는 사례를 만들었습니다. 이는 개발자 팀이 개발자 머신에서 소스 코드를 사용할 수 있으면 라이브러리 소스를 읽을 수 있으므로 시간이 절약된다고 주장한 내부 Maven 저장소에서 얻는 안정적인 버전으로 프로젝트 팀이 작업해야한다는 반론을 반대합니다. 필요한 기능을 사용할 수 있는지 확인하는 코드입니다.
선임 개발자는 유효한 논증이 있습니까? 아니면 개발자가 라이브러리 소스 코드 실행을 읽어야 캡슐화의 기본 철학에 반하고 라이브러리를 처음부터 사용해야합니까?
답변:
이 선임 개발자의 주장은 이해가되지 않습니다.
그들은 개발자가 가끔 소스 코드를 읽을 수 있도록 내부 라이브러리를 지속적으로 검색하고 컴파일하는 오버 헤드를 추가하고 싶습니까? 개발자가 기능을 사용할 수 있는지 확인해야 할 때만 소스 코드를 살펴 보는 것보다 훨씬 많은 시간을 낭비하게됩니다.
라이브러리와 클라이언트가 다른 개발 그룹에 의해 개발되고 라이브러리가 활발하게 개발되고 있다면 이것은 특히 나쁜 생각입니다. 클라이언트 개발자는 라이브러리의 불안정성에 대한 절연성을 갖지 않습니다.
개발자가 소스 코드를 정상적인 빌드에 포함시키지 않으면 서 소스 코드를 사용할 수없는 이유를 모르겠습니다.
제안은
클라이언트 측 개발자가 라이브러리의 소스 코드를 읽고 필요한 기능을 사용할 수 있는지 확인함으로써 시간을 절약 할 수 있습니다.
다른 제안을 할 수 있습니다
라이브러리를 문서화하여 사용 가능한 기능을 표시함으로써 시간을 절약 할 수 있습니다.
소스를 로컬로 읽을 수있는 능력이 도움이된다는 주장을 사지 않을 것입니다. 그러나 라이브러리가 활발히 개발 중이라면 (프로젝트 요구에 대한 지원을 추가 할 가능성이 있음) 개발자에게 요구하는 것은 부당하지 않다고 생각합니다 업데이트를 자주 다운로드하십시오 (하루에 여러 번 가능). 그래도 개발자가 소스에서 컴파일하도록 요구하는 대신 컴파일 된 (및 단위 테스트 된) 바이너리를 사용할 수있게하는 것이 비즈니스 적으로 더 합리적이라고 생각합니다.
프로젝트 내에서 최신 컴파일 버전을 사용할 수있는 일종의 공유 저장소를 설정할 수 있습니까? 이상적으로는 일정에 따라 가져 오기 및 빌드를 수행 한 CI 서버를 원하지만 팀이 이끄는 네트워크 리소스 일지라도 정기적으로 업데이트하는 것이 도움이 될 수 있습니다. 물론 이것은 도서관 팀 판에 있어야하지만 분명히 그들은 관심이 없으므로 느슨해지지 않아야합니다.
소스 코드를 사용할 수 있으면 이점이 될 수 있지만, 저장소를 모니터링하는 CI 빌드 에이전트가있는 경우 개발자가 요구하는 것보다 해당 에이전트가이 라이브러리를 컴파일하여 외부로 종속 프로젝트에 복사하도록하는 것이 더 합리적입니다. 복사본을 만들 때 두 가지 다른 컴파일 단계를 실행하십시오.
현재 빌드 에이전트에 연결되지 않은 프로젝트를 진행 중이며 기본 응용 프로그램을 빌드하기 전에 하위 응용 프로그램을 빌드해야합니다. 내 후부에 심각한 고통입니다. 하위 응용 프로그램을 변경하려면 먼저 전체 프로젝트를 빌드 한 다음 하위 빌드 폴더로 이동하여 컴파일 된 제품을 가져 와서 다른 하위 폴더에 복사해야 전체 프로젝트를 다시 빌드해야합니다 최신 버전의 하위 앱이 기본 앱 빌드에 포함되어 있는지 확인합니다. 이것은 어떻게해야 하는가가 아니다. 최소한이 프로세스를 자동화하는 MSBuild 스크립트가 있어야하며 새 코드가 트렁크에 커밋 될 때마다 빌드 에이전트가 외부를 업데이트하는 것이 좋습니다.
많은 사람들이 모든 사람들에게 내부 라이브러리를 구축하는 것은 의미가 없다고 대답했기 때문에 그 이유를 정당화 할 수있는 반대 견해를 제시 할 것입니다.
라이브러리를 많이 사용하며 설명서가 없습니다. 따라서 모든 사람이 참조 할 소스를 가져야합니다. 이 라이브러리가 매우 자주 사용되는 라이브러리 인 경우 참조를 편리하게 사용하는 것이 유용 할 수 있습니다.
사람들이 라이브러리에 의존하는 자신의 코드를 작성하기 시작할 때 팔을 공중에 던지는 대신 라이브러리의 무언가가 작동하지 않습니다. 라이브러리가 로컬로 구축 된 경우 라이브러리 코드 내부로 바로 들어가기가 매우 쉽습니다.
나는 그의 결정이 정당하다고 말하는 것이 아니라, a) 질문이 이야기의 한 측면을 제시했고 b) 그럴듯한 동기가있을 수 있다고 지적했다.
이런 종류의 테스트는 실제로 더 잘 수행 될 것입니다. 그러나 개발자가 아닌 테스터 가 수행해야합니다 . 그런 의미에서, 그것은 당신이나 도서관 개발자의 일이 아닙니다.
당신이 묘사 한 것에서 프로젝트에 테스터가없는 것처럼 들립니다.이 경우에는 관리상의 문제이며 상당히 심각한 문제입니다.
... 필요한 기능을 사용할 수 있는지 확인하기 위해 라이브러리 소스 코드를 읽을 수 있으므로 시간이 절약됩니다.
상당히 절충적인 추론. 최신 버전 라이브러리가 최신 버전 프로젝트로 컴파일되지 않으면 여러 가지 이유가있을 수 있습니다. lib 소스 코드로 드릴하면 시간 낭비가 될 수 있습니다.
추론을 놓치는 것보다 또 다른 것은 개발과 QA 활동 사이를 전환 하여 흐름 을 깨야 할 때 발생하는 생산성 손실을 피할 수없는 (그리고 내 경험에서 상당히 고통 스럽습니다) .
팀에 테스터가있는 경우, 그러한 것은 매우 간단하고 훨씬 쉽게 처리 할 수 있습니다. 귀하의 "고급"개발자가 귀하에게 제공하는 것은 기본적으로 초안 테스트 요구 사항입니다.
프로젝트 나 라이브러리를 변경할 때마다 빌드가 성공했는지 확인하십시오.
요구 사항 세부 사항을 명확하게하고 공식적인 테스트 시나리오를 설계하며 테스트 실패를 처리하는 방법에 대한 협상과 같은 일반적인 QA 활동이 진행됩니다.
Sr Dev가 제안하는 것은 나에게 전혀 의미가 없습니다. 소스를 찾아 볼 수는 있지만 더 좋은 방법이 있습니다.
어떤 아티팩트 리포지토리를 사용하고 있습니까? 컴파일 된 라이브러리 옆에 각 버전의 소스 jar을 배치 할 수 있어야합니다. 대부분의 IDE는 소스 브라우징을 위해 이것을 컴파일 된 라이브러리에 첨부 할 수 있습니다. Maven 플러그인이있는 Eclipse가 자동으로이를 수행합니다.
최신 코드가 필요한 경우 버전 스냅 샷을 배포하면됩니다.
이것은 단순히 빌드 스크립트에서 발생해야합니다.
왜 또는 어떻게 이것이 문제인지 알 수 없습니다. 또한 참조에 누락 된 것이 있으면 소스에 추가하고 변경 사항을 적용 할 수 있습니다. 물론 도서관이 발 아래서 바뀔 수 있다는 것은 약간 두려운 것처럼 보일 수 있지만, 도서관 관리자가 올바르게 일하면 좋은 일입니다.