[우아한테크코스] 프리코스 2주차 리뷰

프리코스 2주차 리뷰

나에게는 정말 길고도 긴 프리코스 2주차가 종료되었다. 🎉🎉

 

이번 글에서는 2주차 소감문에 작성하였던 과제를 진행하며 학습한 "과정" 중 미쳐적지 못한 부분에 대해서 큰 단위로 나누어 조금 더 자세히 풀어보려고 한다.

자바 컨벤션에 관하여

맨 처음 과제가 숫자야구 인 것을 확인하고 솔직히 처음에는 "안심"했다. 난이도 자체가 어렵지 않기 때문에 빠르게 작성할 수 있을 줄 알았다. 하지만 여러 요구사항들을 보고 나서 나의 그런 마음은 자만이었다는걸 알 수 있었다.

 

우아한테크코스에서 이번 주차에는 여러 컨벤션과 제한사항을 갖고 프로그래밍을 하는 것을 요구했다.

그 중 알고 있었던 컨벤션은 단 하나 커밋과 관련된 템플릿 뿐이었는데 이 또한 잘못사용하고 있다는 사실에 경악했다.

 

그리고 딱 한가지 생각에 휩싸였다. "나는 정말 프로그래밍을 편하게 해왔구나." 어찌보면 혼자서 공부를 해왔던 나에게는 남들을 보면서 겉핥기로 따라했을 뿐이었기 때문이지만 이 또한 자기합리화 에 불과한 발상이었다.

 

그렇게 처음 접하는 컨벤션을 막상 적용하자니 코드가 손에 잡히지 않았다. 이는 흡사 초등학교 운동장에서만 축구를 하다 프로경기를 뛰어본 느낌과 유사했다. 그래서 처음 내가 취한 행동은 정독이었다. 해당 문서들은 목적을 가지고 작성이 되었기 때문에 어떠한 용도로 사용되는지 살펴보고 비슷한 컨벤션을 정리하거나 적용한 대략 열개남짓한 블로그들을 구글링하며 적응해나갔다.

 

그리고 이를 신경쓰며 처음으로 적용을 해보았다. 첫 소감은 "여전히 불편하지만 사람들이 왜 규격화 하여 사용하는지 이유를 알겠네" 였다.  컨벤션은 지금 뜯어보면 정말 큰내용이 없었다. 자바 스타일 컨벤션은 블록 후에는 +4 칸의 들여쓰기를 해라, 의도적인 줄바꿈 후에는 들여쓰기 +8을 해라 등 물론 일부분을 적용한 것이지만 단순한 제약 뿐이었다.

 

하지만 그 단순함은 나에게 큰 놀라움을 주었다. 그동안 내가 해왔던 코드들이 전부 부정적으로 보일만큼 가독성이 높아지고 코드가 명확해지는 느낌이었다.

나는 이전에 여러 사이드 프로젝트를 진행해 보았지만 후반부로 갈수록 리팩터링이 많아질때마다 분명 내가 작성한 코드이고 내가 개발한 기능이지만 찾기 힘들고 찾더라도 무슨 기능을 하는지 알기 힘든경험이 있었다.(주석도 안달고 개발하는 멍청이 개발자) 

 

다시한번 가독성의 중요성을 느끼게 되는 순간이었고 저번주차 공통리뷰였던 "이름의 길이가 길어져도 메서드와 변수명은 의미가 확실해야된다"를 생각하며 이번주차의 핵심인 제약사항을 준수하며 깔끔한 코드를 만드는 것에 초점을 두어 진행하였었다.

 

 

커밋 컨벤션

저번주에 강조했던 커밋이 이번 주차에도 뉴비개발자(나)를 괴롭히기위해서 제약사항이 나왔다.

나는 기존에 커밋 템플릿을 이용해왔고 그렇기 때문에 나름 자신있는 부분이었으나 오히려 과거에 내가 해온방식이 잘못된 것이란걸 깨닫고 큰 충격이었다. 기존에 나는 커밋 템플릿 중 하나인 fix를 refactor의 의미로 사용해왔으나 이는 의미자체가 달라지는 것이었다.

그걸 깨닫고 우아한테크코스의 Discussion 탭의 아고라에 여러 개발자들의 의견을 듣기위해 질문을 남긴적이 있었고 완전히 나의 실수였다는 걸 알았다.

 

그래서 처음 커밋을 배운다는 자세로 기존에 내가알던 지식 관념,습관을 전부 버렸다. 버려야지 새로운 형태를 온전히 받아 들일 수 있다고 생각하였고 커밋 메시지를 작성할 땐 내가 무엇을 어떻게 개발하였는지가 메시지 안에 전부 담기도록 노력하였다.

나는 저번주에 커밋은 "의미" 단위로 작성하는 것이 중요하다고 한번 말한적이 있었는데 그런 신념을 지키기 위해 노력했다. 이번 커밋컨벤션은 다음과 같은 형식을 지니고 있다.

 

Commit Type : Subject Description of Commit - Message  or Patch footer

 

이를 생각하며 Commit Type을 명확히하고 Subject는 해당 변경사항 또는 추가된 부분이 명확하게 들어나면서 길지않게(보통은 50자를 넘기지 않는다고 한다)작성하였다.

 

그리고 Description 부분에는 Commit Type에 따라 중점을 달리두었다. feat, 즉 새로 기능을 개발한 경우  왜 이 기능을 개발했는지를 중점으로 기술하고 fix나 refactor같은 기존의 코드에 수정이 이루어진 경우에는 왜 이기능이 수정되어야했는지, 아니면 왜 구조적으로 변경이 되어야했는지를 기술하고 footer에 가장 최근에 일어난 commit의 id를 적었다. (사실 이슈생성후 커밋이라면 이슈의 번호를 적는것이 커밋을 추적하는데에 더 도움이 된다고생각한다. 하지만 fork 레포지토리였기 때문에..)

 

커밋에 관한 나의 작은 주관

나는 여태까지의 모든 커밋 방법은 물론 템플릿을 잘못 적용하여 사용한 부분도 있었지만 그런 부분보다 항상 영문으로 작성을 하였었다. 코린이 시절(지금도 코린이다..) 협업을 위해선 영문으로 작성하는게 좋다는 말을 듣고 그런 습관을 현재까지도 적용하고 있지만 사실 내가 외국계기업을 노리거나 갈 수 있을만한 실력도 아닐 뿐더러 '한국에서 많은 작업을하면서 영문으로 커밋메시지를 기술하는게 과연 협업에 도움이 되는가? 그리고 직관적인가?'에대해 항상 고민을 해왔다.

 

나는 여태까지의 습관으로 2주차까지는 영문으로 작성해왔지만 앞으로는 협업 시와 혼자 코딩을하더라도 한글로 기술하여 직관적이고 가독성이 좋은 방향을 추구하고자 한다.

 

TDD

TDD 는 아마 나와 같은 경로로 공부를 한 사람이라면 그 중요성을 잘 알고있을것이다.(본인은 인프런에서 김영한님의 강의를 들으며 서버개발자를 꿈꾸게되었다) 김영한님이 입이 닳도록 그 중요성을 강조하였기 때문이다.
하지만 나는 여러 협업 프로젝트와 개인 프로젝트를 진행하면서 DDD 아키텍쳐를 중점으로 사용하며 TDD를 배제하는 프로그래밍을 해왔다. 하지만 이번과제가 "너는 정말 멍청한 방법으로 개발을 해왔구나"라는걸 우아한테크코스에서 일깨워준 과제였던거 같다.

 

보통 기능을 개발하면(API를 예시로 들었을때) 나는 그걸 Postman같은 툴을 이용하여 "어 기능 동작되네? 다행이다" 같은 안일한 마인드로 개발을 했었다. 하지만 이번 과제를 진행하며 기능을 메서드 단위로 잘게 쪼개 그를 테스트해보고 극한의 극한까지 부하 또는 예외를 주면서 더 완벽하게 보수를 해나갈 수있게 해주는게 테스트코드를 작성하는 의의라는걸  몸으로 느끼는데까지는 얼마걸리지 않았다.

 

테스트코드를 작성하며 나의 기능에 내가 감독관이되어 검증을 거치는 것은 자기에게 피드백을 던지며 자신이 성장할 수있게되는 가장 효율적인 방법이다.

나의 기능이 얼마나 많은 버그를 만들어 낼지 계산하지 않고 오로지 기능 구현에만 치중하는 것은 런타임에 언제든지 에러를 만날 수 있다는 뜻이며 이는 곧 시스템의 실패로 이어진다. 그것은 내가 성장하고자하는 방향이 아니기에 TDD의 중요성을 깨달은 지금 TDD 아키텍쳐를 적용한 프로젝틀를 하나 만들어보며 "체화" 시키려고한다. (과제가 숫자야구였기 때문에 인디언포커 같은걸 만들어보려한다.)

 

메서드는 한 기능만!

정말 이 제약조건이 진정한 객체지향적인 프로그래밍을 도와준 사항인 것같다.

나는 보통 한 메서드에 여러기능이 들어가 있는 것을 솔직히말하면 "신경"쓰지 않았다. (기능 구현만을 중요시하던 멍청한 개발자) 하지만 이번 제약사항을 겪으며 모든 메서드의 이름을 유의미하게 짓고 그 메서드들이 서로 유기적으로 작용하는 것을 보고 과장하자면 하나의 생명체를 만들어내는 느낌이라고 느껴졌다.

 

정말 제약사항이란건 그 단어의 의미와는 다르게 많은것을 배워갈 수 있는 기회로 작용하는 것같다.

 

2주차 진행 소감

정말 많은 실수를 하며 실수로 부터 배운 주차이다.

저번주에 그런말을 했었다. "이 기회에 아는 부분도 모르는 부분도 남과 자기자신에게서 배우며 성장해나가겠다고" 했었다. 그 기회가 이번 주차에 왔던것 같다. 커밋과 여러 컨벤션 그리고 리팩터링을 진행하며 자기 피드백까지 할 수있다는 점에서 유익하고 뜻 깊었다.

 

알고있던 지식에 변화를 주고 새로운 지식을 습득하는것은 처음에는 상당히 어렵지만 그 어려움이 짜릿하다. 사실 혼자서도 진행할 수 있겠지만 나는 객관적으로나 주관적으로나 게으른 면이 있기에 이런 체계속에서 압박감이 느껴질 때 비로소 효율성이 높아지는 사람인것 같다. 그런 한점에서 우아한테크코스는 강력한 동기부여인셈이다.  이러한 동기부여를 한달간의 기간속에서만 유지하는 것이아닌 나의 열정으로 변환하는 법 또한 천천히 배워나가는 중이다.