[Smilegate/테크 하이킹] 협업을 위한 클린 코드와 아키텍처 W3 - 주석과 PR

 

한창 취업을 위해 서류를 작성하고 있습니다. 운이 좋게도 면접을 볼 기회가 있어 면접 준비도 해보고 서류도 계속 쓰고 바쁘네요 ㅠㅠ 올해 가기 전에 취뽀 성공하면 좋겠습니다! 여담으로 면접 후기나 취준 뿐만 아니라 여러가지 생각을 많이 했는데 기회가 된다면 이 부분도 글로 남겨 보도록 하겠습니다.

 

아무튼, 이번 스터디 주제는 주석과 github의 pr 남기는 법에 관련한 내용입니다.

 

주석

책에서는 어떤 주석을 사용하면 좋은지, 어떤 주석이 나쁜 주석인지를 말해주고 있습니다.

 

좋은 주석:

• 어떤 인스턴스를 반환하는지와 같이 정보를 제공하는 주석
• 문제 해결을 위한 저자의 의도를 드러내는 주석
• 실행이 오래걸린다와 같이 결과를 경고하는 주석
• Todo 주석
• 중요성을 강조하는 주석

나쁜 주석:

좋은 주석을 제외한 나머지.. 대표적으로 아래와 같다

• 주절대는 주석
• 형태를 그대로 대변하는 주석
• 오해의 여지를 남겨두는 주석
• 의무적으로 다는 주석 
• 등등

책의 저자는 결국 주석을 안 쓰는 것이 가장 좋다고 합니다. 가장 좋은 방법을 애초부터 네이밍을 잘 하고 코드를 잘 짜는 것이라고 합니다.

 

이전 챕터들을 읽어가며 어느정도 이 이야기가 근거 있고 맞는 말이라고 생각하였습니다. 그리고 추가적으로 느낀 것은 결국 우리가 클린 코드를 찾아보고 코딩을 하는 이유는 결국 사람을 위함이라고 생각했습니다.

 

혼자 개발을 하면 상관 없지만, 여럿이서 협업하는 코드의 경우 결국 가독성은 중요한 요소입니다. 그것을 위해 이전 챕터에서도 다뤄왔고 주석도 가독성을 위한 요소 중 하나이죠. 

 

따라서 제가 생각하기에 이번 챕터를 한 줄 요약하면, 사람의 이해를 돕는 가독성을 위한 주석이 가장 적절하다라고 판단하였습니다. 

 

아래는 이번 챕터를 읽은 스터디원의 의견들입니다.

• 함수를 잘 쓰면 커밋 메세지, 주석 잘 쓸 필요가 없다. 함수를 작성하는 중에는 주석을 많이 사용한다. 배경지식의 전달도 중요하지 않을까?
• 주석이 필요 없는 코드가 와닿았다. 삼항연산자를 좋아하는데, 남들은 이해 못 할때가 많다. 이럴때 함수로 빼는 방식으로 하는게 나을 것 같다.
• 주석 쓰기 귀찮다.. 코드 잘 짜면 주석은 필요 없는데 내가 잘 할 수 있을까?
• 대부분 동의 한다. 주석을 짜는 것과 좋은 코드 사이의 트레이드 오프는 어쩔 수 없는데, 이전 회사에서는 시간이 지나며 퍼져있는 주석이 많았는데 관리를 잘 안하더라. 코드는 작성되는 순간부터 썪는 것 같다.
• 대체적으로 동의하나 너무 극단적이지 않나 싶었다. 그리고 특히 "주석을 지우기를 주저한다"라는 말이 참 동의됐다.
• 결국 사람을 이해시키기 위한 것이므로 국어를 잘 해야겠다.

항상 책을 읽어온 후 한줄 나온 한 줄 의견을 보는 것 도 흥미로운 것 같습니다.

 

커밋 메세지와 PR

협업을 하며 PR, 커밋 메세지 작성은 필수라고 생각합니다. 주석과 더불어 어떻게 해야 더 좋은 커밋 메세지를 남길 수 있을까를 주제로도 이야기를 해보았습니다.

 

개인적으로 "커밋 메세지 남길 때 -m으로만 하는 사람들 보면 진짜 화가난다."라는 글을 어디선가 봤는데. 이 것과 관련하여 말해주니 스터티원 한 분도 그렇다고 동의하시더라구요ㅋㅋ

 

저같은 경우 아직은 혼자 개발 할 때가 많으니 커밋 메세지나 PR남기는 것이 익숙하지는 않았습니다. 이번 기회에 궁금한거 다 물어봤습니다.

 

질문1: 각자의 팀에서 어떻게 커밋메세지를 작성해요?

답변: 대부분 팀 내에서 그라운드 룰에 의거해서 작성한다. 모두가 잘 지키는 것은 아니다.

 

질문2: 휴먼 에러가 발생하면 어떻게 해요?
답변: 그래서 커밋 메세지 자동화를 시켜놓았다. 해당 링크를 참고하면 좋을 것이다. 커밋 메세지가 많아지면 결국 어노잉해질 수 밖에 없다. 그래서 이렇게 틀을 맞춰놓는 자동화도 좋다.

https://insight.infograb.net/blog/2023/05/25/git-commit-automation/

Git 커밋 메시지 자동화 가이드

 

질문3: 자동화 말고도 많이 사용하는 것은?

답변: 이슈, jira 등 다양한 것을 사용하긴 한다. github과의 연동이 잘 되기 때문에 함께 사용하면 편리하다.

 

질문4: 개발을 몰입해서 하다보면 기능 하나만을 하는게 아니라 여러가지 기능이 한번에 될 때가 있다. 이럴 때 커밋의 단위를 어떻게 해야할 지 고민이 된다. 보통 어떻게 하나

답변: 커밋 단위는 사람이 지키는 것 밖에 없는데, 일단 git squash라고 pr의 커밋을 모두 하나로 모아주는 것이 존재한다. 이것도 참고하면 좋을 것. 커밋을 언제 해야하는지는 기능 그리고 경험에 따라서 진행한다. 메세지를 잘 작성해야한다.

 

질문5: 그럼 어떻게 하면 커밋 메세지를 잘 쓸 수 있을까요?

답변: 다시 돌아와서 팀바팀, 룰바룰이다. 하지만 지키려고 하는 것이 몇가지 있다. 가장 중요한 것을 맨 앞에 쓰는 것이다.

 

질문6: 그럼 그 외에도 이것은 꼭 있었으면 좋겠다 하는 것은?

답변: 애초에 커밋 하나가 크면 안된다. 기능이 많으면 안된다. 또, 한 줄로 간결하게 설명할 수 있으면 좋다. 기능을 수정했으면 바로 찾을 수 있도록 남기자.

 

저는 아직 잘 모르는 팀과 실무의 세계였습니다...

그래도 이번에 질문을 하면서 궁금증도 많이 해소 되고 예시도 많이 볼 수 있었는데요. 이번에는 시간상 못했지만 다음 스터디 시작 때 함께 실습도 해보기로 했습니다. 

https://github.com/SmilgateTechHiking-CleanCode

SmilgateTechHiking-CleanCode

 

마지막

끝으로, git lens와 cli gpt, --vervose 등 저는 잘 쓰지 않았던 다양한 것들에 대해서 알고 가는 기회도 되었습니다. 다양하게 사용하며 관련해서도 익숙해지도록 해야겠습니다.

 

읽으시는 분들도 의견 주시면 감사하겠습니다.