아무도 고칠 수 없는 4년 된 오타 🧟 및 개발자 도구 구축에 관한 더 많은 이야기

Source: Dev.to

Making Software의 진행자로서, 좋은 소프트웨어를 만들기 위해 실제로 필요한 것이 무엇인지에 대해 꽤 현실적인 대화를 나눌 수 있습니다. 최근에 Raghd Hamzeh (Okta의 시니어 소프트웨어 엔지니어이자 OpenFGA의 핵심 유지보수자)와의 대화에서, 충분히 조명받지 못하는 엔지니어링의 한 측면을 파고들었습니다: 사용자가 다른 엔지니어일 때는 어떤 일이 일어날까? API, SDK, 혹은 단순히 공유 라이브러리를 만든 적이 있다면, 개발자들이 가장 보람 있고 동시에 가장 “목소리 큰” 청중이라는 것을 알게 될 것입니다.

1. “Breaking Change” 가려움은 실재한다 😬

Raghd는 우리 many가 공감할 수 있는 이야기를 털어놓았습니다: 제품에 네 살짜리 오타가 있으면 미치도록 골치가 아프다. 사소한 네이밍 불일치일지라도, 한 번 생기면 매번 눈에 들어옵니다.

모든 유지보수자가 겪는 내부 전쟁을 우리 모두 알고 있습니다: 깨끗한 API를 위해 모두의 빌드를 깨뜨릴까? 아마도 아닐 겁니다. 이는 1개월 차에 내린 결정—예를 들어 파라미터 전달 방식—이 5년 차에 살아가야 할 레거시가 된다는 강력한 교훈이 됩니다.

2. “외계인” SDK는 그만 👽

OpenFGA의 Ruby SDK를 작업하면서 이 문제를 정면으로 마주했습니다. Ruby 개발자는 의견이 강하다 (제가 직접 경험했기에 말합니다).

다중 언어 도구를 만들 때는 두 가지를 끊임없이 균형 맞춰야 합니다:

• 일관성: Go SDK와 Python SDK가 동일하게 동작하도록 보장하기.
• 관용구: Ruby 개발자가 마치 추가 단계가 있는 Java 코드를 작성하고 있다는 느낌을 받지 않게 하기.

Raghd의 의견은? 100 % 완벽하게 만들 수는 없습니다. 때때로 “완벽히 관용적인” 구현보다 플랫폼의 장기적인 건강을 우선시해야 프로젝트가 유지보수 가능하게 됩니다. 그 긴장은 절대 사라지지 않으며, 우리는 그 속에서 더 나아가게 됩니다.

3. 실제 인간을 위한 “AI” 파일 🤖

AI가 떠오르면서 많은 레포지토리에 agents.md 파일이 포함됩니다. Raghd는 강력히 이렇게 말했습니다: 우선 인간 기여자를 위해 그 파일을 작성하라.

오픈소스 꿈을 함께 이루고 싶다면, 기대치를 명확히 제시하세요:

• 커밋은 어떻게 구조화해야 할까?
• 핵심 아키텍처는 어떻게 생겼는가?
• PR을 제출하기 전에 이슈를 열어야 할까?

이러한 “코드가 아닌” 결정들을 미리 문서화하면 엄청난 마찰을 줄일 수 있습니다. “이 PR은 우리가 원한 것이 아니다”를 “우리가 모두 따르는 설계도는 이것이다”로 바꾸어 줍니다.

Full episode

Check out the full episode of Making Software here: Link to episode