오픈 소스 개발자로서 Slack과 협업하기: 2부

1부 요약

첫 번째 블로그 게시물에서 저는 오픈 소스 개발자로서 Slack SDK에 기여하는 여정을 공유했습니다. URL 구성을 단순화하고 불일치를 방지하기 위해 API 요청의 기본 URL에 슬래시가 있는지 확인하는 것과 관련된 문제를 해결했습니다. 아직 읽어보지 않으셨다면, 후속작의 맥락을 파악하기 위해 여기서부터 시작하시는 것이 좋습니다.

---

새로운 도전이 시작됩니다

첫 번째 기여를 마친 후 같은 프로젝트의 또 다른 문제를 다루고 싶었습니다. 시작을 준비하면서 인증 테스트 중 하나에서 문제를 발견했습니다. 이 문제는 이전에 구현한 후행 슬래시 기능 때문에 발생했습니다.

상황은 다음과 같습니다. 이제 초기화 중에 base_url에 항상 슬래시가 추가되었습니다. 그러나 일부 테스트 케이스에서 사용된 api_method도 /로 시작했습니다. 이 조합으로 인해 이중 슬래시(예: https://slack.com/api//auth.test)가 발생하여 일부 API 요청이 중단되었습니다.

---

문제 보고

이 버그의 중요성을 깨닫고 신속하게 관리자에게 보고하고 문제를 설명하는 새로운 이슈를 열었습니다. 투명성을 보장하고 명확한 해결 경로를 제공하기 위해 버그를 해결하는 풀 요청도 제출했습니다. 그러나 관리자는 메인 브랜치의 중단을 방지하기 위해 원래 병합을 되돌리기로 결정하고 극단적인 경우에 필요한 수정 사항과 테스트가 포함된 새 PR을 제출하도록 요청했습니다.

---

수정 및 새로운 구현

문제를 해결하기 위해 _get_url 함수를 재작업하고 base_url 및 api_method에 후행 또는 선행 슬래시가 포함되어 있는 경우에도 이중 슬래시를 방지하기 위한 추가 보호 장치를 추가했습니다.

업데이트된 구현은 다음과 같습니다.

def _get_url(base_url: str, api_method: str) -> str:
    """Joins the base Slack URL and an API method to form an absolute URL.

    Args:
        base_url (str): The base URL (always ends with '/').
        api_method (str): The Slack Web API method. e.g., 'chat.postMessage'.

    Returns:
        str: The absolute API URL, e.g., 'https://slack.com/api/chat.postMessage'.
    """
    # Strip leading slash from api_method to prevent double slashes
    api_method = api_method.lstrip("/")
    return urljoin(base_url, api_method)

---

주요 조정

1. 선행 슬래시 제거: api_method에서 .lstrip("/")을 사용하면 연결 중에 이중 슬래시가 발생하지 않도록 보장합니다.
2. 테스트 사례 개선: 다음과 같은 시나리오를 포괄하도록 테스트 모음을 확장했습니다.
   • 후행 슬래시가 있거나 없는 base_url
   • 앞에 슬래시가 있거나 없는 api_method. 둘 다 슬래시가 있는 극단적인 경우입니다.

업데이트된 테스트의 예는 다음과 같습니다.

def test_get_url_prevent_double_slash(self):
    api_url = _get_url("https://slack.com/api/", "/auth.test")
    self.assertEqual(api_url, "https://slack.com/api/auth.test", "Should prevent double slashes")

    api_url = _get_url("https://slack.com/api", "auth.test")
    self.assertEqual(api_url, "https://slack.com/api/auth.test", "Should handle base_url without trailing slash")

    api_url = _get_url("https://slack.com/api/", "auth.test")
    self.assertEqual(api_url, "https://slack.com/api/auth.test", "Should handle api_method without leading slash")

    api_url = _get_url("https://slack.com/api", "/auth.test")
    self.assertEqual(api_url, "https://slack.com/api/auth.test", "Should handle both inputs cleanly")

---

테스트 및 엣지 케이스에 대한 고찰

이 경험을 통해 저는 철저한 테스트의 중요성을 배웠습니다. 원래 구현이 기존 테스트를 모두 통과했지만 api_method의 선행 슬래시와 같은 특정 예외적인 경우를 설명하지 못했습니다.

다음은 주요 내용입니다.

1. 단위 테스트는 완벽하지 않습니다. 단위 테스트는 많은 문제를 파악하는 데 도움이 되지만 모든 극단적인 경우를 다루지는 못할 수도 있습니다. 특히 입력이 크게 다를 경우에는 기능의 끝이 미흡할 수 있습니다.
2. 협업 및 의사소통: 버그를 즉시 보고하고 관리자와 솔루션을 논의하면 더 큰 중단을 방지할 수 있습니다. 내 변경 사항을 되돌리기로 한 결정은 메인 브랜치를 안정적으로 유지하는 것의 중요성을 강조했습니다.
3. 반복 및 학습: 오픈 소스 기여는 반복적입니다. 각 단계는 개선하고, 피드백을 통해 배우고, 코딩 관행을 강화할 수 있는 기회입니다.

---

최종 생각

Slack의 SDK에 기여하는 것은 매우 귀중한 경험이었습니다. 새로운 기능 구현부터 의도하지 않은 부작용 해결까지의 이 여정은 실제 소프트웨어 개발의 복잡성과 오픈 소스의 협업 정신을 강조했습니다.

오픈 소스 프로젝트에 기여하는 것을 고려 중이라면 실수에 대한 두려움 때문에 주저하지 마세요. 모든 버그, 모든 수정 사항, 작성된 모든 테스트는 더 나은 개발자가 되기 위한 단계입니다.

오픈소스 기여 시 어떤 어려움에 직면했나요? 아래 댓글로 토론해 보세요!

위 내용은 오픈 소스 개발자로서 Slack과 협업하기: 2부의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!