서론
네이버 부스트캠프 웹모바일 8기를 시작한지 벌써 3주가 지났네요.
시간은 항상 빨리 가는 거 같습니다.
최근에 악귀라는 드라마를 보고 있는데 1시간짜리 악귀는 20분처럼 느껴지고, 12시간 챌린지는 3시간처럼 느껴지네요.
근소하게 챌린지가 더 시간이 빨리 가는군요 ㅋㅋ
이번 주차는 반성거리가 더 많습니다.
네이버 부스트캠프 웹・모바일 8기 챌린지 3주차 회고에서는 반성점에 대해 말하고,
3주차부터 바뀌었던 챌린지 일정에 대한 후기도 말해보겠습니다.
코드 리뷰 반성
이번 코드 리뷰에서는 다른 팀원에게 큰 도움이 안 되었다고 느꼈습니다.
이전처럼 다른 팀원의 코드를 분석해서 좋은 점, 개선했으면 좋을 점, 궁금한 점에 대해 고민했습니다.
그렇지만 이전과는 다르게 의견의 퀄리티가 많이 낮았다고 생각합니다.
아래는 제가 가장 크게 반성 중인 의견을 각색한 내용입니다. (컨텐츠 보호를 위함)
현재 A 클래스는 Read와 Write 역할이 모두 들어있습니다.
Read와 Write를 분리하면 A 클래스의 역할이 더 명확해질 거 같아요.
그런데 지금 구조에서는 굳이 하지 않아도 될 거 같기는 합니다.
왜냐면 OOO 하기 때문입니다.
당시에는 근거가 있는 적절한 의견을 전달했다고 느꼈는데요..
"굳이 하지 않아도 될 거 같기는 합니다" 라는 말이 너무 무책임하다고 느껴졌어요.
무책임한 의견은 안 하느니만 못하다라고 생각하기 때문에 깊게 반성했습니다.
그럼 같은 의견을 어떻게 책임감 있게 전달할 수 있을지 고민을 해봤는데요.
현재 A 클래스는 Read와 Write 역할이 모두 들어있습니다.
Read와 Write를 분리하면 A 클래스의 역할이 더 명확해질 거 같아요.
OOO 덕분에 지금 구조에서는 역할을 분리하지 않아도 괜찮아 보이는데요.
역할을 분리했을 때의 장단점을 한 번 고민해보시는 것도 좋아 보입니다.
혼자서 고민을 해봤는데 차이가 있어 보일까요..?
내용은 같지만 표현을 다르게 해보았습니다.
제 리뷰를 듣는 사람이 "그래서 어쩌라고..?"라는 생각이 들지 않게 의도를 좀 더 명확히 해봤어요.
이 글을 보시는 분이 있으시다면 댓글로 의견 남겨주시면 정말 감사하겠습니다
다음주에도 더 나은 코드 리뷰를 위해 계속 고민해봐야겠습니다.
(아마 취업을 한 후에도 계속 고민하지 않을까 싶네요 ㅠㅠ)
구현 반성
구현 과정에서도 반성할 부분이 많았습니다.
이번 챌린지 과정에서는 처음으로 스파게티 코드를 찍어냈기 때문입니다.
너무 구현하고 싶은데 마음대로 안 되는거에요...
에잇 모르겠다 생각하고 스파게티를 생산하기 시작했습니다.
결국에는 구현에 성공했지만 스파게티 구조때문에 개선 단계에서 더욱 막막해지더라고요.
현업에서는 당연히 결과가 중요하겠습니다만 (현업을 해보지 않아서 정확히는 모르겠습니다 ㅎㅎ;)
지금은 챌린지 과정이니 과정이 더 중요하다고 생각합니다.
그래서 결과에 대한 욕심과 부담을 참고 과정에 좀 더 집중해야겠습니다.
성장에 대한 고민
위에 적은 내용과 연계해서 이번주의 저는 과연 성장을 했나 생각을 해봤습니다.
오늘 하루만 고민한건 아니고 과정 순간 순간 계속해서 고민했어요.
그런데 성장에 대한 욕심이 집착이 되었고, 집착 때문에 오히려 학습 효율이 떨어졌습니다.
그래서 그냥 더이상 고민하지 않고 묵묵히 하기로 했어요 ㅋㅋ
성장하지 못해서 자기합리화하는 거 아니냐고 한다면 할 말이 없습니다만
잘 모르겠네요.
스스로 명확한 답을 내릴 수도 없고, 다른 사람이 답을 알려줄 수 있는 문제도 아니라고 생각해서
정말 어려운 고민인 거 같습니다.
2주차 회고에서 중걍마에 대해 말했었는데요.
중요한건 꺾여도 그냥 하는 마음을 가지고, 네이버 부스트캠프의 좋은 팀원과 멘토님들을 믿고
그냥 묵묵히 해봐야겠습니다.
피어쉐어를 하며 느낀 점
(내용에 문제가 있을 시 댓글 부탁드립니다. 즉시 삭제 조치하겠습니다.)
마지막으로 피어쉐어 과정에 대해 느낀 점을 말해보겠습니다.
3주차부터는 개선 과정이 추가되었는데요.
1일차에는 구현, 2일차에는 개선하는 형태입니다.
바뀐 일정이 너무 좋았지만 아쉬운 점도 있었습니다.
바로 개선에 대한 피드백 시간인 "피어쉐어" 입니다.
간단히 피어쉐어에 대해 설명드리면,
2일차 오전에는 구현에 대한 코드 리뷰를 진행하고, 코드 리뷰 후 개선을 진행합니다.
그리고 저녁에 다시 모여서 개선 결과를 리뷰 합니다.
그런데 개선 결과 리뷰가 많이 어려웠습니다.
오전의 코드 리뷰 시간 전에는 1시간동안 팀원들의 코드를 볼 수 있는데요.
개선 결과는 미리 팀원의 코드를 볼 수 없었기 때문입니다.
라이브로 설명을 듣고 코드를 보면서 약간의 의견 전달은 가능했지만, 조금 더 오래 보고 싶다는 생각도 많이 들었습니다.
그리고 6시간이라는 개선 시간도 많이 짧다고 느껴졌어요.
오전에 들은 피드백에 대해 고민하고, 공식적으로 권장하는 개선 목록을 구현하려면 6시간이라는 시간은 너무 짧았습니다.
그래서 생각해본 방법인데요!
하루에 두 번 코드 리뷰를 진행하지 말고 나눠서 진행하면 어떨까 싶습니다.
개선에 대한 코드 리뷰를 저녁이 아니라 다음날 오전으로 하는거죠.
그러면 개선 시간도 넉넉하게 확보되고, 개선 결과 코드도 미리 확인할 수 있으니 서로의 성장에 더 좋지 않을까 싶습니다.
(물론 스케줄은 더 빡빡해지고 코드 리뷰에 들이는 시간과 노력은 더 들겠지만요 ㅎㅎ;;)
마무리
이렇게 3주차 회고도 마무리가 되었네요.
칭찬할 점은 없고 반성할 점만 있던 3주차였습니다.
어째 1, 2주차보다 반성할 점이 두 배나 더 있는지 모르겠네요 ㅠㅠ
4주차는 챌린지의 마지막 주차인데요.
과연 어떤 과제와 이슈가 절 즐겁게(?) 할지 기대됩니다.
감사합니다!