모든 사람이 비용, 혜택 및 위험을 극복 할 수있는 한 실제로 그렇게하는 데 아무런 문제가 없습니다.

… 수정은 코드 자체를 패치하기에 충분히 간단 해 보입니다.

당신이해야 할 일이있을 때, 완벽한 (제대로 원하는 제 3 자 라이브러리를 갖는)은 충분히 좋은 적입니다 (직접 패치). 때로는 그런 일을해야합니다. 상용 라이브러리에 대한 소스 라이센스를 구입하여 공급 업체에 도달하기 전에 문제를 해결할 수있는 여러 프로젝트를 수행했습니다.

… 변호사들은 이것이 위험하고 귀찮은 복잡성을 초래한다는 점에서 거의 항상 나쁜 생각이라고 주장하기를 원합니다.

다른 사람의 코드를 해부하고 문제를 식별하고 수정을 작성하는 데 필요한 정보가없는 경우 나쁜 생각입니다. 코드가 사내 또는 타사인지 여부는 사실입니다. 유일한 차이점은 무릎에 떨어지기 전에 칸막이 벽이나 건물 벽에 던져 졌는지 여부입니다.

이 패치를 수행 하지 않는 데 드는 비용을 들이지 않고 비난자가 아이디어를 무시 하고 있다면 숙제를하지 않는 것입니다. 패치로 해결 될 버그의 영향을받는 많은 사내 코드가있는 경우, 문제를 해결하고 수정하여 올바르게 작동하는지 확인하기 위해 코드를 변경하고 변경해야합니다. 그런 다음 패키지를 버그 수정 버전으로 업그레이드 한 경우 해결 방법을 찾아 제거하고 다시 테스트해야 할 수도 있습니다. 변경 한 사례가 없거나 테스트가 불충분 한 경우와 같이 그렇게 할 위험도 있습니다. 개인적으로 소스에서 버그를 해결할 수있는 기회가 있다면 flyswatter로 나머지 코드를 쫓아 모든 것을 얻을 수 있기를 바랍니다.

… 코드 변경은 우리에 의해 이루어졌습니다 … 코드 기반의 일부 여야합니다 … 새로운 프로젝트로 소개하고 자동화 된 빌드를 빌드 프로세스에 통합해야합니다.

패치를 수행하는 경우 패치는 자체 코드의 일부이므로 프로세스의 일부로 만들어야합니다. 이것은 시스템에 100 % 코드를 추가하는 것과 다르지 않습니다. 타사 배포판을 성사로 취급하고 소스 코드처럼 모듈에 넣습니다. 작성한 모든 패치는 별도의 파일로 저장되며 빌드 프로세스의 일부로 적용됩니다. 이렇게하면 항상 깨끗한 소스에서 패치 된 소스로, 빌드 된 제품으로 가서 진행 상황을 정확하게 보여줄 수 있습니다. (일부 사람들은 버전 관리에서 압축을 풀고 핸드 패치하고 다시 포장하여 저장합니다.

… 우리는 소스 제어 저장소에서 코드를 코드로 가져오고 코드 변경의 역사를 잃어 버립니다 …

써드 파티 라이브러리를 써드 파티 종속성으로 취급하는 경우, 해당 히스토리가 시작되지 않으며 아무것도 손실되지 않습니다. 타사의 저장소에 계속 액세스 할 수 있으면 필요한 사항을 상담 할 수 있습니다. 타사 릴리스는 변경되지 않은 자체 시스템에 체크인하는 비정질 얼룩처럼 처리해야합니다. 사용중인 릴리스와 이후 릴리스 사이의 변경 사항을 확인해야 할 경우 원하는 변경 사항이 포함 된 이전 버전에 대한 패치를 제공 할 수 있습니다.

또한 작은 코드 변경이 필요하기에는 너무 복잡한 것 같습니다.

빌드 프로세스가 충분히 정교하다면이를 추가하는 것이 자신의 코드를 추가하는 것보다 어렵지 않아야합니다. 압축 풀기 / 패치 / 빌드 프로세스가 자동으로 수행되는 시점까지는 약간의 노력이 필요하지만 일단 완료되면 영원히 끝납니다. 지금은 하나의 버그가있을 수 있지만 앞으로 20 개가있을 수 있습니다. 있다면 다음 19 개의 작업을 훨씬 덜 처리 할 수 ​​있기 때문에 지금은 모든 것을 지원할 수있는 토대를 마련한 것이 훨씬 더 행복 할 것입니다.

답변