일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 스프링
- 프로그래머스
- 알고리즘
- 백준알고리즘
- 1과목
- python
- 코딩교육봉사
- 공부일지
- 백준
- 소프티어
- kotlin
- 코딩봉사
- softeer
- 파이썬
- SQL
- MYSQL
- 코틀린
- 자바
- 데이터베이스
- CJ UNIT
- BFS
- 시나공
- programmers
- 문제풀이
- java
- C++
- 백준 알고리즘
- 정보처리산업기사
- SW봉사
- 회고
- Today
- Total
JIE0025
코드리뷰를 "잘" 받는 방법에 대한 고찰 본문
✅ 들어가는 글
한빛 세미나에 다녀왔다.
https://www.hanbitn.com/seminar/
코드 품질 향상을 위한 코드리뷰 방식에 대해 설명하는 세미나였다.
나는 코드리뷰를 잘 하는 개발자가 되고 싶다는 생각을 많이 했다.
인턴을 하면서도 어떻게 하면 코드리뷰를 잘 할 수 있을까 고민을 했지만,
과제를 끝내는것에 집중한 나머지 코드리뷰를 그렇게까지 신경쓰지 못했던것 같아 아쉬움이 남았었다.
그래서 이번에 코드리뷰 방식에 대한 생각 정리를 하고자 세미나를 신청하게 되었다.
세미나를 열심히 들으며 정리를 했는데, 해당 내용은 올리면 안된다고 해서
해당 내용과 비슷하지만,
나 스스로가 그동안 프로젝트를 하면서 코드리뷰에 대해 고민했던 부분을 이야기 해보겠다.
✅ 코드리뷰를 받는 입장에서 고민했던 것
✍️ 가독성에 신경을 쓰자 - ⭐️⭐️⭐️⭐️⭐️
왜 내가 문서화와 가독성에 진심인 개발자가 되었는가? 를 생각해보니
상대방의 입장을 생각하다보면, 자연스럽게 더 나은 커뮤니케이션을 위해 가독성을 신경쓰게 되었다....는 스토리가 있다.
코드리뷰는 나를 위해 상대방이 시간을 내는것이다.
따라서 가독성을 높여서 상대방의 시간을 최소화 해야한다.
아래는 내가 정말 처음 스프링부트를 이용한 서버 개발을 시도했을 때 작성했던 것이다.
코드를 개선하던 중, 했던 고민의 절차를 쫙 설명하고, 어떤 노력을 했는지 어떤 결과가 나왔는지 등
내가 갖고 있는 생각을 상대방이 전부 이해할 수 있도록 정리했었다.
(지금 와서 보니까 이 정도로 할 필요는 없어보인다. 문서화 하는데 소요되는 시간이 더 많으면 안된다. )
가독성을 살리기 위해
제목과 문단나누기, 코드공간에 대한 적절한 사용도 해주었다.
간단한 기능개발을 했을 때에도
어떤 것을 적용했는지, 반환하는 것은 무엇인지, 그 형태는 어떻게 되는지 한눈에 볼 수 있게 만들었다.
✍️ 커밋 단위에 신경 쓰기
내가 무슨 개발을 했는지 한눈에 보이게 만들자
이것 역시 가독성에서 출발하는 커뮤니케이션 방법이다.
너무나 많은 커밋을, 이런저런 기능개발과 개선, 버그 등 무수히 많은 복잡한 커밋으로 PR을 올리면
상대방은 코드리뷰를 할 수 없게된다.
내가 이것을 개발할거야/ 변경할거야 /개선할거야 라고 목표한 것이 있을 때
그 주제에 대해서 벗어나지 않는 상태로 PR을 올렸다.
커밋의 단위는 또한 개발/변경/개선하는 과정에서 적당한 크기의 코드 수정 범위를 설정했다.
(이건 경험하다 보면 좋다고 느끼는 범위가 있어서 예를 들기 어려운것 같다)
✍️ 내가 올린 코드, 내가 먼저 리뷰하자
사람이다보니 실수가 생길 수 있다.
분명 올리기 전까지 괜찮았는데 올리고 나서 다시 보니까
- 들여쓰기를 잘못했다던지
- 너무도 간단한 테스트 코드라서 그냥 이전에 썼던거 복사했는데 제대로 수정이 안됐다던지..
어차피 올리자마자 코드리뷰를 해주는 사람이 바로 보는 경우는 극히 드무니
내가 먼저 찾고 댓글에 달아두면 되는 것이다.
실제로 팀프로젝트에서
내가 먼저 리뷰를 남기자, 팀원분이 좋아요를 남겨주셨었다
✍️ 깃허브 관리 및 컨벤션
아래는 내가 프로젝트를 경험하면서 편리하게 사용했떤 관리 컨벤션이다.
팀원들과 상의하면서 필요없는것을 제거했다.
요약하면 아래와 같다.
1) 한글로 적었다 (프로젝트를 해보니까 영어보다는 한글이 직관적으로 느껴졌다)
2) PR에 대해서만 이름과 수정날짜를 추가했다. (모든 커밋은, 변경 내용만 적었다)
3) 이슈작성을 습관화 했다. (기록해야 까먹지 않고, 끝낼 수 있다)
결론
코드리뷰를 "잘" 하기 위해선
결국 가독성에 최선을 다해야한다는것이 아주 주관적인 생각이다.
😌 Insight
세미나를 통해
코드리뷰에서 중요한 점들을 정리한 이후,
내가 그동안 프로젝트를 하면서 코드리뷰에 최선을 다했었고, 잘 하고 있었다 깨달았다.
또한 내가 한 고민들이
어떻게 더 커뮤니케이션을 잘 할수 있을지 ,
다른 개발자 분들도 비슷하게 고민하고 있었다는 것도 알 수 있었다.
아직 신입으로 취업은 안해서,
실무에 들어가면 좀더 디테일하게 신경써야할것이 생길테고
다른 일정들에 치여 코드리뷰를 적극적으로 하지 못하는 상황이 생길 수도 있을것 같다.
그럼에도 언제나 남을 먼저 생각하며 커뮤니케이션하는 개발자로써
가독성에는 항상 신경쓸것을 다짐하는 하루이다.
'커뮤니티 활동 > 컨퍼런스 참석' 카테고리의 다른 글
[점핏] 두번째 개취콘 후기 (JUMPIT TO BACK-END) (0) | 2023.09.10 |
---|---|
[INFCON 2023] 인프콘 후기 : 우물을 벗어날 용기 (3) | 2023.08.21 |