우아한테크코스 프리코스 1주차 회고
우아한테크코스 프리코스 1주차 회고
우아한테크코스 1주차를 늦게나마 회고한다. 바쁘진 않았지만, 확신이 없어서 육체적인 체력보다 정신적인 체력이 더 부족했다. 잘하는 사람들이 디스코드에 들어와서 그들끼리 아는 주제로 대화를 해서 그런가? 나는 이런 것들 언제 다 알지? 불안감이 덮쳐 온다.
과제를 받고나서, 이어지는 대화. 밤을 새서 할 만한 과제는 아닌 것 같은데, 그들끼리 대화하는 것 보면 지금 잘못하고 있는 건가? 하기도 싶다.
과제 자체에 대해서는 심플하게 짜야하는게 아닌가? 싶기도하고 무엇보다 누가 알려주지 않기에 각자 과제를 푸는 방식이 많이 다르기도 하다.
과제를 풀고나서 리뷰 글이 올라오기 시작한다. 기능 요구사항보다 더 고민을 많이 한 소스코드들. 똑같은 결과값이 나오는 과제인데 그들과 비교가 된다.
아니, 비교할 수 밖에 없다. 안일하게 생각했고, 내가 생각하기에 간단하게 짜서 그런가? 싶기도하고 내가 코드를 짤 때의 방향을 잘 못 잡았나? 싶다. 부럽다. 나도 그들 처럼 되고 싶다. 디스코드에 올라온 포비의 글을 보면서 다시 한번 다짐하게 된다.
포비가 올린 글
뭐지? 난 구현 자체도 힘든데 OOP, TDD, 리팩터링, rebase, MVC, DDD, DTO, 헥사고날 등등등 모두 처음 들어보는 용어들 다들 너무 잘 하네 난 힘들겠다. 그냥 포기해 버릴까?
마음 속에서 이런 속삭임이 들린다면 어떻게 하면 좋을까요? 여러분은 이런 상황 속에서 어떤 선택, 어떤 마음 가짐으로 임하는 것이 좋을까요?
나의 답변
자기 자신을 믿는게 중요하다고 생각해요! 코딩할 때의 즐거운 자신! 무언가를 만들면서 기뻐하는 자신!
그렇다 자기 자신을 믿어야 한다. 마치 목적지에 도달하기 위해 같은 도로에 탄 자동차들을 보듯이. 그들과 속도는 다르지만, 목적지는 없어지지 않는 것 처럼.
코드 회고
요구 사항에 맞춰 기능명세서를 작성하자.
README.md 파일에 나와있는 요구사항을 본다음 "이럴 것이다" 라고 추측하면서 요구사항을 작성했던 것 같다. 다행히 마지막 점검 때 안 넣은 기능을 추가하였다. 이런 일을 방지하기 위해, 요구사항은 따로 붙여넣기 해서 계속 점검하자.
테스트 코드를 요구사항에 맞춰 작성하기
1가지의 요구사항에 여러 기능이 많을 경우 분리해서 작성하는것이 맞지만, 그렇지 않은 요구사항일 경우 요구사항에 맞춰서 테스트 코드를 작성하는게 어떨까 생각해 본다. 요구사항과 맞는 테스트 코드를 작성하게 되면, 요구사항 누락을 방지할 뿐만이 아니라, 내 코드가 어떻게 요구사하에 맞춰서 작성이 되었는지 한눈에 알아보기 쉬울 것이라 기대하기 때문이다.
줄임말 쓰지 말자
고수님이 코드리뷰를 하면서 피드백 요청한 내용 중에 인상 깊었던 리뷰 있어서 이 부분은 흡수해야 된다고 생각한다. 줄임말은 모두가 합의하지 않는 이상 의도하지 않는 방향으로 해석될 수 있기 때문이다.
변수명을 줄여쓰지 않고 풀네임을 쓰도록 권장하는 것으로 알고있어요! 예) StrikeNumber, StrikeCount
매직 넘버 쓰지 말자
다른 분들의 코드를 보면서 전반적으로 매직 넘버(의도를 알 수 없는 Number)사용을 지양해야 하는 부분을 알게 되었다. 의미 없이 들어간 상수가 있는지 확인해 보려고 한다.
자신 회고
내 페이스에 맞게 유지하자
내가 커밋 한 것은 얼마 되지도 않는다. 하지만 다른 잘하시는 분들의 코드를 볼 때 커밋 횟수가 엄청나다. 되돌아 봤을 때, 처음에 커밋을 이렇게 적게한 이유가 있다. 복잡해 보이기 싫어서 그랬던 것 같다. 남이 내 코드를 본다고 생각할 때 엄청난 양의 커밋 메시지가 있으면 자칫 읽기가 힘들까봐 계획적으로 커밋 메시지를 남겼다. 무엇이 맞는지는 모르겠다. 하지만 남들이 내 코드를 보고 이해할 수 있도록 남겨놓는게 정답이라 생각한다.
비교가 된다면 참여하지 말자
디스코드에 들어가면 나도 모르게 비교하게 된다. 나도 최선을 다하고 있는데, 이사람들은 잠도 자지 않는가? 그런 생각이 들기도 한다. 다수를 이기려하니까 그런 것 같다. 남과 비교하지 말고 자신의 페이스대로 나가자 그리고 기대 하지말자. 기대가 크면 더 상처 받는다.