뻘글만 쓰다가 각잡고 쓰려니 연재 주기가..느리네요 llorz

지난번에 이어 초보 개발자의 ESlint 기여 후기(with 오픈소스 컨트리뷰톤)가 계속됩니다.
너무 길다면 3줄 요약로 빠르게 읽읍시다.

---

3. Pull Request

가장 설레는 순간입니다. (회사에서도 설렙니다 진짜로 ㅎㅎ)

3.1 PR 제목 정하기(★)

작업하다보니 커밋을 많이 했는데... 본 소스에 너무 조각조각 땃땃따 올라가는 거 아닐까?
하는 생각을 다들 한두번쯤은 해보셨을 겁니다...

이대로 괜찮은가?할 때쯤.. 주변에 멘토나 사수분이 계시다면 질문해봅시다.
아니면, 이전 커밋로그들을 살펴봅시다..!
거기에 바로 "정답"이 있습니다.
(저도 같이 컨트리뷰톤을 참여하는 분들 로그 보고 깨달았습니다. 역시 코딩은 혼자하는 것보다 여러명이서 같이 하는게 좋아요!!)

바로 Github의 기능인 Squash and Merge!!

ESLint의 소스코드는 올릴 PR과 연관된 브랜치에 커밋된 내용을 PR의 제목으로 합쳐서 1개의 커밋 기록으로 만드는 Squash and Merge를 사용하고 있습니다.

따라서, 커밋 메시지는 물론, PR 제목을 작성할때도 원칙에 맞게 일관성 있게 작성해야합니다.
Git - 커밋 메시지 컨벤션(번역 되어있음) 같은 걸 참고하면, 오픈소스 관리자, 혹은 다른 참여자와 코드로 소통하는데 도움이 됩니다.

그래도 애매하다면, 코린이들을 위한 최고의 답지 다른 사람이 올린 PR들을 참고하여 요령껏 작성해봅시다...

3.2 본문 작성하기

프로젝트마다 보통 양식(template)이 자동 불러오기 되기때문에, 구체적으로 본인이 한 것에 대해 기재하면됩니다.

제가 만들었던 PR을 예시로 설명해보겠습니다

---

PR 제목: Update: Add exceptionPatterns to id-length rule (fixes #13094)

Prerequisites checklist

• I have read the contributing guidelines.
  (ESLint에 기여하기전에, 기여 가이드라인을 읽어보라는 뜻입니다.)

What is the purpose of this pull request? (put an "X" next to an item)

[X] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[x] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

issue #113094
(어떤 목적으로 PR을 올렸는지 체크하는 항목입니다!
저는 룰에 일부를 추가했고(변경), 변경된 룰에 대한 내용을 DOCS에 갱신했으므로 각자 항목에 체크했습니다.)

What changes did you make? (Give an overview)

I continued the PR #13099

• Unnecessary 'parserOption' was removed from id-length.js(test)

• Two valid tests were added. They test with multiple exception patterns.

• Two invalid tests were added, too. They test with an identifier that doesn't match configured pattern.
  (One tests tooLongError, another tests tooShrotError. )

• To avoid creating new RegExp in "return value", I exatracted a function.

• docs/rules/id-length.md was updated about exceptionPatterns

(어떤 변경사항들이 있었는지 개요를 적으면 됩니다.
저는 일단 PR #13099을 이어서 한다고 적고, 이후 변경점에 대해서 꼼꼼하게 적었는데
보통은 간략하게 개요만 적으셔도 됩니다.(커밋 메세지를 잘 적었으면 그걸로 확인하면 되니까요!))

Is there anything you'd like reviewers to focus on?

I want know how these test-cases are suitable.
I thought them in my own way.........🤔 but not sure.. 😂
(리뷰할때 리뷰어들이 추가로 체크해줬으면 하는 것을 적으면됩니다.
저는 이전에 TDD를 해보긴했지만, 테스트케이스를 어느정도 입력하는게 적절한지 잘모르겠어서..
그 사항에 대해서 적었습니다.)

---

영작이 힘들땐 구글 번역기와 요즘 유튜브에서 광고하는 Grammarly를 적절히 사용하는 것도 꿀팁입니다. 구글은 영원한 나의 친구..ㅎㅎ

이렇게 PR을 올리고 나면

맨아래에 생기는 CI/Test에서 모든 영역이 테스트 되길 기다렸다가

통과되거나, licence/cla에 걸리면
JS CLA(Contributor License Agreement)에 sign 해주시면 끝입니다.

이제 오픈소스 관리자분들이 확인하실때까지 기다리고 있으면 됩니다.

---

4. Code Review

코드 리뷰는 해당 오픈소스의 관리자분들이, 기여자들이 올린 코드를 점검해주시는 과정입니다.
일종의 의견 교환 과정이라고 생각하시면 됩니다.

불필요한 자원이 낭비되고있지는 않은지, deprecated된 method인지...
변수나 function이름이 어색하지 않은지..
코딩에 100% 정답은 없지만, 모범답안이나 선호되는 방식은 있기때문에

관리자분들이 그런 부분들을 체크해주시면서 코멘트를 달아주십니다.

• Test case
  
  (둘째줄부터)이번 PR에 성공하는 경우의 수를 나눠서 테스트를 만들었는데요.
  멤버분이 "여러개의 패턴을 갖고 있는데, 그중 첫번째는 매치되지 않고 이후에 매치되는 케이스"를 추가하면 더 좋아질 것 같다고 의견을 주셨습니다.

다시 경우의 수들을 생각해봐도 꼭 필요한 부분입니다. 문제가 있었다면 제가 놓쳤을뿐...ㅎ
그래서 저렇게 대답하고 추가했습니다.. 참쉽죠?

• Refactoring
  이전 PR에서 부탁받은 리팩토링 부분을, 제 생각대로 리팩토링해본 소스코드입니다
  
  디버거를 보면서, 나름 선방쳤다(?) 생각했던 코드인데
  사실 만들면서... 다른 코드들을 본 결과 rule관련 로직들에 for문을 잘 안쓰는 거같다는 찝찝함이 가시질 않았습니다.
  그래서 뭔가 리뷰를 보면 답이 나오지 않을까? 생각했는데..

리뷰어님이 for문(정확히는 forEach문) 대신 map을 사용해서 코드를 짧게 줄일 수 있는 방법을 알려주셨습니다. 정말 몰랐는데 javascript 내장 method 중에 이렇게 편리한 메소드가 있는것도 알게 되었습니다.....!

짧아진데다가, 그냥 문장읽는 것처럼... 코드 가독성이 좋아진 것 보이시나요..?
10+@줄을 n줄로 줄이는 마법....

js를 꼼꼼히 공부해야겠습니다.

• documentation

docs는 처음 적을 때 긴장을 좀 많이 했었습니다. (ESlint를 쓰는 모든 사용자들이 읽는거니까...)

regular expression을 사용한다는 얘기도 구체적으로 적어야할까..?하는 생각을 하다가
어짜피 문자열 패턴 처리에 Reg exp를 쓰는게 당연한 일이고.. 아니면 예제코드를 보거나하면 알수 있으니까 안 적고 마무리했었는데요.

의견으로 덧붙여주신 코멘트에서 더 구체적으로 설명해주셔서 그 문장으로 교체했습니다.
(사실 ^BEFORE같은 표현만 적혀있으면, 이게 뭐지..?하는 사람들도 분명 있을 것 같으니까, 해당 설명에는 Reg exp라고 구체적으로 명시해주는 게 "가이드"에는 어울리는 것 같아요.. )

여튼 이런 식으로 리뷰(의견 교환)가 진행되고,
관리자분들 혹은 리뷰멤버들이 주신 의견대로 코드를 고치면 우측상단의 Reviewers에서

버튼을 클릭해서 재검토를 부탁드리면 됩니다.
그리고 재검토가 끝나면 "LGTM" 이라는 코멘트와 함께!! 해당 오픈소스 멤버분들이 Approved를 찍어주십니다. ( “Looks Good To Me” 라는 뜻이예요!)

해당 이슈에 관련된 ESlint관리자분들이 모두 aprroved를 찍어주시고 나면 며칠뒤에 진짜로 master에 Merge!!가 됩니다. 🤗
이제 최신버전 ESLint에서 내가 제안한 기능을 사용하실 수 있습니다!!

5. Merge!!

머지가 되면 머가 좋나요?

🔥그래서?

1. 한번 merge가 되면 contributor라는 뱃지가 GitHub에 생깁니다.
   
   다음에 또 PR을 할때, 아 이사람이 전에도 이 오픈소스에 관심이 있었던 사람이구나..
   하는 암묵적 표시를 티낼 수 있습니다. ㅎㅎ 계속하면 아마 좋은일이 있겠죠?

2. ESlint 블로그 release 공지사항에 이름이 올라갑니다.
   
   (뿌듯...)

3. ESlint 공식 guide 문서에 내가 변경한 내용이 추가됩니다
   
   (뿌듯...(2))

4. 좋은 일을 한것 같아 기분이 좋습니다.
   
   내가 기여한 부분 덕분에, 다른 사람들이 편하게 일할 수 있을 거 같은 Feeling....
   어렵지 않은데, 유용하고 좋은일한것 같은 이 기분..

한번 해봤으니, 또 할수 있을 것 같은 자신감이 생깁니다.(!)

---

3줄 요약(★)

1. 헷갈릴 땐 다른 사람들이 한 걸 보자!

2. 오픈소스에 기여하면 뿌듯하다.

3. 또 할수 있을 것 같은 자신감이 생긴다.

---

📕 오픈소스 컨트리뷰톤 후기

뭐든 혼자하려면 힘든데,
확실히 여러 명이서 같이하니까 의견도 많이 나오고, 진행 기록도 한국어로 남게되는 점이 참 좋습니다.
스몰 토크를 하다보면 정보교환도 잘 되고.. 참가하길 정말 잘한것 같아요ㅎㅎ

처음엔 이슈 고르는 것도 힘들었는데... 다른 분들이 먼저 해결하신 기록들을 더듬어가다보니, 실마리가 보이더군요. 덕분에 오픈소스 라이프 사이클도 읽을 수 있었구요.
도움받은 만큼 남겨두고 싶어서 후기도 열심히 써봤습니다.🥰

코로나덕분에 오프라인이 거의 불가능한 상태라...
첫주에는 '아 나 기여 못하고 끝나는거아닌가ㅠ'<-하고 있었는데

앞서가신 팀원들 코멘트 기록을 참고한 덕분에 무사히 contribute에 성공할 수 있었습니다.
역시 최고의 답지코딩은 여러명이서 하는게 최고...S2

또, 생각보다 PR-Merged과정이 빨리 끝나서 아 이정도면 다른것 도전도 할수 있겠다는 자신감이 생기더라구요. 역시 일단 한번 해보는게 중요한 것 같습니다.

함께해주신 오픈소스 컨트리뷰톤 ESLint팀원분들과 이끌어주신 멘토님께 감사드립니다.🎉

(이 글이 다른 오픈소스 컨트리뷰트를 노리는 분들께 도움이 되길바라며...
도움이 되셨다면 하트 1개 눌러주세요ㅎㅎ!)