금요일 해킹부터 출시까지: 오픈 소스 프로젝트 생성 및 출시에 대한 고찰-Golang-php.cn

From Friday Hack to Release: Reflections on Creating and Releasing a Open Source Project

금요일 패치 해킹부터 출시까지: 오픈소스 프로젝트 생성 및 출시에 대한 고찰

초보 및 중급 개발자를 대상으로 자신의 아이디어를 오픈 소스 프로젝트로 공개하거나 관심을 갖는 시리즈의 일부입니다.
이러한 반성은 편향적이고 개인적입니다. 더 많은 기사가 예정되어 있습니다. 몇 가지 생각을 공유함으로써 여러분이 자신의 프로젝트를 수행하는 데 영감을 주기를 바랍니다

반성(이것)
Java 개발자로서 Go 언어 배우기(TODO)
오픈 소스 건강 및 커뮤니티 파일(TODO)
오픈소스 보안(TODO)

요구 사항

모든 것은 몇 년 전에 시작되었습니다. 때때로 나는 나 또는 다른 사람이 항상 동일한 Bash 스크립트를 다시 작성하는 것과 관련된 것처럼 보이는 무언가가 필요했습니다.
전반적인 요구 사항은 높은 수준인 경우가 많기 때문에 간단했습니다.
우리 개발자들이 주로 하는 일은 A지점에서 B지점으로 정보를 섞는 것 뿐입니다. 그렇죠?

여기서 목표는 여러 Git 저장소를 다른 Git 제공자, 디스크, 아카이브 형식, CLI 앱으로 미러링하는 것이었습니다.
나는 개인적으로나 직장에서 이것이 필요했습니다. 사람들이 이런 일을 수동으로 처리하는 데 많은 시간을 투자하는 것을 보니 마음이 불편합니다.

그래도 항상 단순한 Bash 스크립트로 유지되는 것 같았습니다. 신속하게 완료되지만 특별한 경우, 오류 처리, 모듈화, 패키징 등 추가 사항이 추가되어야 하는 경우 - 우리 대부분이 동의하는 것처럼 Bash 스크립트는 더 큰 도구를 지원하지 않습니다.

그래서 이를 위한 완전한 CLI 애플리케이션을 만들기로 결정했습니다.

사전 결정

그러한 도구가 이미 존재합니까?

가장 먼저 해야 할 일은 바퀴를 재발명하지 않는 것이었습니다.
오픈 소스로 이 문제를 해결하는 몇 가지 도구가 있습니다. Go로 작성된 최소한 하나, Bash 스크립트 몇 개, 그리고 Gitea와 같은 가져오기 기능을 포함하는 경우.
나는 그것들을 시험해 보았지만 내가 원하는 방식으로 완전히 작동하는 것을 찾을 수 없었습니다. 그리고 프로젝트를 어디로 진행하고 싶은지에 대한 다른 생각이 있었기 때문에 깊이 들어가지 않기로 결정했습니다
기존 프로젝트에 패치를 적용하기 시작했습니다.

상업적인 도구도 몇 가지 있지만, 이 작은 도구는 오픈소스 형태로도 존재해야 한다고 느꼈습니다.

결론: 이 세상에는 이 CLI 도구가 있을 곳이 있었습니다.

Work-hackdays나 개인적인 자유 시간에 해킹을 하시나요?

스프린트가 끝날 때나 다른 경우에는 직장에서 해킹 시간을 가집니다. 한 가지 접근 방식은 시간이 지남에 따라 이러한 상황에서 이를 해킹하여 유용한 것으로 만드는 것입니다.
나는 다음과 같은 이유로 개인 여가 시간에 완전히 하기로 빨리 결정했습니다.

직장에서의 해킹 기회는 전체 프로젝트를 장기간 진행하는 것이 아니라 짧은 학습과 창의성을 발휘하는 데 사용해야 합니다.
해당 솔루션이 핵심 조직의 비즈니스에 적합하지 않습니다. 그렇다면 항상 이상한 일이 될 것입니다.
업무에 연결하면 더 많은 일처럼 느껴질 것입니다. 저는 재미를 위해 이 일을 하며 바둑 등을 배우고 있습니다. 그러면 나에게 압박감과 스트레스가 가해질 것입니다.
업무 시간에 작업을 수행하면 시간이 오래 걸릴 것입니다. 몇 시간, 몇 주에 걸쳐 진행됩니다.

결론: 남는 시간에 재미있게 해야겠다.

기술 스택 선택

저는 JS/TS, Python/Ruby로 몇 가지 프로젝트를 진행하면서 수년 동안 Java/Kotlin 세계에서 대부분의 시간을 보냈으며 모든 수석 개발자와 마찬가지로 때때로 다른 작업도 하기도 했습니다.
하지만 오랫동안 저는 Go나 Rust를 정말 배우고 싶었습니다. 그래서 새로운 언어에 뛰어들 수 있는 동기를 얻을 수 있는 기회가 될 것입니다
Go를 선택한 이유는 Open Source DevOps 세계의 꽤 많은 CLI 애플리케이션이 Go로 작성되어 있고, 때때로 타사 프로젝트에 패치를 제출할 수 있기를 원하기 때문입니다. 또한 Go로 작성한다는 것은 여러 대상 아키텍처가 포함된 하나의 바이너리를 의미합니다.

예를 들어 Pico CLI 및 GraalVM을 사용하면 Java에서 이 작업을 수행할 수 있었는데, 이전 시도 이후 좋은 인상을 받았지만 대신 Go를 배우고 싶다고 결정했습니다.

결론: Go로 해보고 배워야겠습니다.

기타 학습 목표

이를 통해 대부분의 보안 관행(스코어카드, SLSA,

)을 따라 멋지게 패키지된 오픈 소스 프로젝트를 제공하는 주제에 대해 더 깊이 탐구하고 싶었습니다. GoRelease와 같은 도구를 사용하여 다양한 종류의 빌드를 만들 수 있습니다.

결론: 원하는 주제를 배우고 탐구할 수 있는 기회를 가져보세요.

범위를 유지하세요

많은 실험을 하려고 계획했고 Go를 처음 접했기 때문에 구조화되지 않은 작업을 많이 할 것이라는 것을 알았습니다.
여기에서 범위를 설정하는 것이 중요했습니다. 알파 릴리스에는 언제 충분할까요?
어떤 기능을 갖춰야 할지 일찌감치 결정했고, 좀 더 다듬고 확장하고 싶은 마음이 들 정도로 좋았습니다.
이것만 있으면 오래 앉아있을 수 있겠네요.

결론: 부끄럽기도 하고 자랑스럽기도 할 때 프로젝트를 알파로 출시하세요.

추정 – 얼마나 어려울 수 있나요?

새로운 언어를 배우는 것은 언어 자체를 배우는 작은 부분이지만 생태계와 관용어를 배우는 데 훨씬 더 중요합니다.
어떤 라이브러리가 사용되며, 어떻게 사용되며, 이런 저런 작업을 수행하는 관용적 방법은 무엇입니까?
저는 이 프로젝트 동안 배우고 연구하는 데 많은 시간을 투자해야 할 것입니다. 아마 제가 할 시간의 50% 정도일 것입니다.
내가 아는 언어와 생태계에서 코딩만 했습니다.

결론: 새로운 코어 스택을 배우고 실험할 때 예상 시간을 3배로 늘리세요. 언어 구문은 사소한 것입니다.

창조 과정

초기 커밋

기본 구현은 하루 만에 완료되었습니다. 빌드, 오류 처리, 문서화, 극단적인 사례, 유지 관리 등이 없었습니다.
대부분의 금요일 해킹은 여기서 끝나며 대부분은 더 이상 진행되지 않습니다.

그러나 모든 선임 개발자가 알고 있듯이, 제대로 작동하는 것을 만드는 것은 제품 출시까지 훨씬 더 먼 일입니다.

곧 끝났죠? 꼭 그렇지는 않습니다.

시간 찾기

가끔은 프로젝트에 보낼 시간을 찾기가 정말 어려웠습니다. 특히 직장에서 지친 봄을 보냈기 때문입니다.
매일 밤 특정 주제에 대해 2시간 동안 책을 읽거나 새로운 기술을 배우고 싶은 기분이 드는 것은 아닙니다.
또는 문서를 작성하는 데 시간을 소비합니다. 저는 아이도 있고 집도 있는데 다른 취미보다 개인 프로젝트에 더 많은 시간을 할애할 여유가 없었습니다.
하지만 항상 주어야 할 것이 있습니다. 결국 시리즈를 덜 보게 되었고 이 기간 동안 게임은 거의 존재하지 않았습니다.

그래도 프로젝트에 더 많은 시간을 할애하고 싶었지만 거의 항상 동기가 부여되었습니다. 밤에는 잠도 덜 자고 코딩하거나 공부하는 세션도 몇 번 있었습니다.
더 나아가고 싶은 마음이 너무 컸기 때문입니다. 그리고 역기 들기, 책 집필, 개발 등 무엇이든 재미있으면 즐겁습니다.

내가 잊어버린 것들

저는 오랫동안 팀으로 일하는 것에 너무 익숙해졌습니다. 솔로 프로젝트에서는 훨씬 더 많은 모자를 관리해야 하고 기술적인 부분이 아닌 모든 부분에서 꽤 능숙해야 합니다.
나는 좋은 CLI 디자인과 관용적인 선택을 파헤치는 데 꽤 많은 시간을 보냈습니다. 또 다른 영역은 다양한 플랫폼에 대한 릴리스 프로세스 및 바이너리 구축이었습니다.
오픈 소스의 SLSA 및 기타 표준을 따르는 데도 시간이 걸렸습니다. 그리고 우리는 좋은 테스트 범위를 원합니다. 그렇죠?
팀으로 작업하면 다른 사람이 원하는 로고를 작성하고 문서 작성에 필요한 작업을 수행할 수 있기를 바랍니다.
혼자 작업하세요. 당신만 아니면 불가능합니다.
코드 작성은 프로젝트 전달의 50%도 되지 않습니다. 그리고 나머지가 있습니다.

사기꾼 증후군이 닥친다

임포스터 증후군은 지식 기반 개발자 세계에서 흔히 발생합니다. 사람마다 기술이 다르며, 어느 시점에나 당신보다 더 잘 아는 사람이 항상 있기 마련입니다.
팀에 속해 있으면 함께 논의할 사람이 있습니다.
혼자서는 별로.

그러나 때때로 코드에서 어리석은 일을 할 수도 있다는 점을 받아들이는 것이 중요합니다.
그리고 오픈 소스는 완벽하기 위한 것이 아닙니다. 다른 사람에게 도움이 될 수 있는 것들을 배우고, 해결하고, 공개하는 것입니다.

더 그라인드

글쎄요. 완료되면 완료된 것입니다.

몇 차례 늦은 밤 디버깅과 리팩토링을 했지만 몰입과 도파민의 순간도 셀 수 없이 많았습니다.

나에게는 프로젝트의 전반적인 아키텍처가 근본적으로 움직이지 않을 것이라고 느꼈던 릴리스 시점이 왔습니다. 인터페이스를 식별했고 그것이 확장 가능하다고 느꼈습니다.
코드베이스는 괜찮습니다.
대부분의 기본 기능이 있으며 모든 것이 개선될 예정이지만 여전히 작업할 수 있는 기반입니다.

여파와 교훈

범위를 조기에 설정하세요. 중지할 위치를 결정하세요. 프로젝트 구조, 문서, 릴리스, 파이프라인, 커뮤니티 지침을 조기에 설정하세요. 앞으로는 과거에 감사할 것입니다.
스트레스 받지 말고 학습 과정을 즐기세요. 끝나면 끝입니다.
꾸준함: 오픈 소스는 단거리 경주가 아닌 마라톤입니다. 화상을 입지 마십시오. 그것은 당신의 인생이 아니라 취미입니다. 그러나 끈기있게 행동하십시오. 매일 작은 일을 해보세요.
배우고, 배우고, 배우세요: 모든 것을 문제가 아닌 학습과 발전의 기회로 여기세요.
코딩은 쉬운 부분입니다. 메인 코드는 시간이 가장 적게 걸리는 코드입니다. 문서화, 테스트 등과 같은 다른 모든 작업에 시간이 소요됩니다.
추가 기능 수행: 코딩만큼 재미있습니다. 예, 문서화를 통해 설명하고 다시 설명하는 데 드는 시간을 절약할 수 있습니다. 지루하다면 재미있게 만드십시오. Docs-as-code, vim-pong 등
휴식을 취하세요. 번아웃은 현실입니다. 필요할 때 뒤로 물러서세요. 다른 모든 창의적인 학습 과정과 마찬가지로 일괄적으로 진행하세요.
시스템 사용: 가능한 한 빨리 실제와 현실 세계에서 나만의 dogfood를 사용하세요. 더 나은 방법은 피드백을 제공할 사람/커뮤니티를 찾는 것입니다.
여행을 즐겨보세요. 만드는 것은 멋진 일입니다.
완료: 이 세상에는 반만 완료된 프로젝트가 엄청나게 많습니다. 완성하세요.
AI를 도움으로 사용: 코드 개선, 코드 검토, 문서 구조, 요약 등과 같은 약간의 추가 작업을 AI에 위임하여 시간을 절약합니다. 맹목적으로 믿으십시오. 답변을 검토하고 비판하세요.