[AOS] 우아한테크코스 6기 프리코스 2주차 회고 : 자동차 경주

📌 2주차 완주!

우테코 2주차 미션이 끝나고 3주차에 접어들었다! 이제 2주차 회고를 적어보려한다. 회고를 목요일에 바로바로 올리고 싶은데..글을 쓰는 과정이 꽤나 오래 걸린다. 2주차 미션은 '자동차 경주' 였는데 진행 방식은 똑같았고 추가된 요구사항이 몇 가지 있었다. 나는 한 번도 테스트 코드를 작성해본 적이 없기에 테스트 코드를 작성하라는 요구사항이 가장 눈에 띄었다.

📌  추가된 요구사항

• indent(인덴트, 들여쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다. 예를 들어 while문 안에 if문이 있으면 들여쓰기는 2이다. 힌트: indent(인덴트, 들여쓰기) depth를 줄이는 좋은 방법은 함수(또는 메서드)를 분리하면 된다.
• 함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어라.
• JUnit 5와 AssertJ를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다.

📌  기능 목록

이번에는 체크박스를 만들어 기능을 구현할 때마다 체크 표시를 하며 진행했다. 기능 목록을 더 상세하고 보기 좋게 작성해보고 싶은데 쉽지않다. 또한 처음부터 완벽히 정리하는 것보다 문서를 계속 업데이트 하며 살아있는 문서를 만들기 위해 노력해야겠다.(2주차 공통 피드백을 반영하여!)

README.md 파일에 작성하는 기능 목록은 기능 구현을 하면서 변경될 수 있다. 시작할 때 모든기능 목록을 완벽하게 정리해야 한다는 부담을 가지기보다 기능을 구현하면서 문서를 계속 업데이트한다. 죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다.

📌  미션 과정

✅ 객체지향적으로 짜자

1주차 때 '함수로만 짜는 것보단 객체를 구성해서 작성하라'는 코드 리뷰를 받았다. 그래서 다른 사람들의 코드를 보며 어떻게 객체지향적으로 짜는지 살펴보았다. 모두가 똑같은 구조를 가지는 것은 아니었지만 기능을 기준으로 나눠 분리하는 것 같았다. 그래서 이번에는 조금이라도 객체지향적으로 짜보려고 노력했다. 패키지를 따로 만들고 각각의 객체마다 클래스를 만들어 진행하니 헷갈리기도 했지만 main함수에서 보니 코드의 흐름이 잘 느껴져서 좋았고, 한층 더 정리된 느낌을 받았다!

나름대로 나눠본 패키지와 파일들

✅  함수를 최대한 작게 만들자

2주 차 미션에서 추가된 요구사항 중 하나는 '함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어라.'였다. 검색해 보니 함수를 작게 만들면 코드의 가독성과 유지보수성을 향상하고, 단위 테스트를 수행하기 쉽다는 사실을 알았다. 지금까지는 딱히 고려하지 않고 코드를 짰지만, 이번에는 신경 써서 최대한 한 함수가 하나의 기능을 하도록 만들어 보았다.

 

예를 들어, 처음 코드를 짤 때는 랜덤값을 얻는 기능과 랜덤값에 따라 position을 변경하는 기능을 한 함수에 짰다.

fun move() {
    var num = Randoms.pickNumberInRange(0, 9)
    if (num >= MIN_POWER) position++
}

 

리팩토링할 때는 함수를 더 나누는 것이 좋다는 생각이 들어 아래와 같이 수정했다.

fun move(num :Int) {
    if (num >= MIN_POWER) position++
}

fun getRandoms() : Int {
    return Randoms.pickNumberInRange(0, 9)
}

✅  테스트 코드를 작성하자

테스트 코드는 이번에 처음 작성해 봐서 어떻게 작성하는지 전혀 몰랐지만 검색과 test/kotlin/study를 참고하여 아주 기본적인 테스트만 구현해보았다. 테스트 코드를 작성하는 것은 초반에 작성한 기능 목록에 대해 다시 확인하고, 빠진 부분은 없는지 점검하는 기회가 되었다. 그리고 디스코드 커뮤니티에서 본 TDD 방법도 실제로 어떻게 진행되는지 궁금해져 찾아보았다. 해본 적이 없어 모두 명확히 이해되지는 않지만 한 번 TDD로 개발해 보고 싶은 마음이 들었다.

✅  끝이 없는 코틀린의 세계

1주 차 공통 피드백에서 ‘Kotlin에서 제공하는 API를 적극 활용한다’, ‘배열 대신 Kotlin Collection을 사용한다’라는 피드백이 있어 미션을 진행하며 더 찾아보았다. 코틀린에서 제공하는 컬렉션 API(filter, map, all, any 등)에 대해 알게 되었고, map 함수를 이번 미션에서 사용해 보았다. 또한 Association 함수나 foreach 반복문도 사용해봤는데, 1주 차 때 적용했다면 더 간결한 코드가 될 수 있었을 것이라고 느꼈다. 아직 쓰는게 익숙하지 않아 한번에 정리해봐야 할 듯!👀

✅  중복하지 않는 코드

1주 차 피드백을 보고 객체 지향 체조 원칙을 모두 찾아봤다. 클래스 이름이 Game이라면 메서드 이름을 gameStart()라고 짓는 것이 아니라 start()라고 간결하게 지어 Game.start()라고 호출할 수 있도록 했다. 이렇게 하니 가독성도 좋고 더 효율적이라고 느껴져 앞으로도 신경 써서 코드를 짜야겠다는 생각이 들었다.

📌  공통 피드백

• README.md를 상세히 작성하기
• 기능 목록을 재검토하고 업데이트하기 - 예외적인 상황도 기능 목록에 정리하기
• 값을 하드 코딩하지 않기
• 구현 순서도 코딩 컨벤션 - 클래스는 프로퍼티, init 블록, 부 생성자, 메서드, 동반 객체 순으로 작성하기
• 변수 이름에 자료형, 자료구조 사용하지 않기
• 한 함수는 한 가지 기능만 - 함수의 길이를 15라인이 넘어가지 않도록 하기
• 테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리해보기
• 처음에는 작은 테스트부터

📌 내가 받은 코드 리뷰 

📄 | 커밋메세지 컨벤션을 잘 지켜라

커밋메시지를 잘 작성해주신것 같은데, 컨벤션에서는 소문자를 사용하더라구요.

 

나는 지금까지 type의 앞글자를 대문자로 썼는데, 커밋메세지 컨벤션에서는 소문자로 사용한다는 피드백을 받았다. 구글에 검색해 블로그 글 몇 개만 대충 보고 컨벤션을 지키고 있다고 생각했는데 앞으로는 공식 문서나 원문을 스스로 읽는 습관을 가져야겠다. 아래는 내가 커밋메세지 컨벤션을 보고 짧게 정리한 글이다. 1주차 때 올렸는데 컨벤션 가이드를 보고 내용을 수정하였다!

[Git] 커밋 메세지 컨벤션(Commit Message Convention) 가이드

📁 | git을 통해 관리할 자원에 대해 고려하라

local.properties는 sdk에 대한 내용을 담고 있기때문에 gitignore을 통해 관리해야 할것같습니다.

 

라는 피드백을 받았다. 1주차 공통 피드백에서 나온 내용인데 2주차에서 못지켜서 반성했다. 사실 언제 올라간건지도 모르겠다..찾아보니 gitignore 파일을 만들어주는 사이트가 있다.

🤔 | 상수화에 신경써라

문자들처럼 숫자도 상수화 시키면 좋을 것 같습니다.

 

1주차 때와는 다르게 문자열을 상수로 만들어 object에 모아놓았다. 그러나 숫자나 특수문자는 상수화하는 것을 놓친 것을 코드 리뷰를 통해 알게되었다.

❌ | 변수명에 자료형을 쓰지마라

자료형 사용하지 않은 변수명으로 바꾸는게 좋을 것 같습니다.

 

2주차 공통 피드백에서도 나온 부분인데, 변수명에는 자료형이나 자료 구조 등을 사용하지 말아야 한다. 3주차에는 변수명을 짓고 다시 검토해봐야겠다.

🫥 | null safety에 관한 학습

? 사용으로 null 값을 가능하게 해주는 부분 잘 봤습니다. kotlin 언어 사용이 처음이다 보니 java와 다른 방식으로 null 처리해 준다는 것을 알게 되어 도움 많이 되었습니다. 그런데 inputCarName에서 name 값이 공백인 경우의 예외 처리를 해주었는데 그 이후에 null 가능을 위해 ?를 다시 사용하신 이유가 따로 있을지 궁금합니다.

 

이 리뷰를 받고 아주 뜨끔했다. 왜냐하면 아래와 같은 오류가 떠서 안드로이드 스튜디오에서 고쳐주는대로 수정했기 때문이다.

only safe ( .) or non-null asserted ( .) calls are allowed on a nullable receiver of type

 

답글을 달기 위해 코드를 다시 살펴보니 Null safety가 없어도 되는 부분에도 마구잡이로 넣어놓아서 창피했다. Null safety에 대한 공식문서 내용을 보고 해당 내용을 더 확실히 이해해야겠다.

📑 | 코틀린 컨벤션에 따라 작성하라

printResultMessage가 printRaceWinner보다 먼저 등장하기 때문에 "위에서 아래로 읽는 사람이 무슨일이 일어나고 있는지 논리를 따라 갈 수 있도록 관련 내용을 배치해라"라고 Class layout에 적혀있어서 남겨드립니다.

 

코틀린 컨벤션에 따라 배치도 고려해야한다는 사실을 알게 되었다. 코틀린 컨벤션을 꼼꼼히 읽지 못한 것을 반성하며..시간 내어 정독해봐야겠다!

🧪 | 테스트 코드 패턴에 대해

test 코드의 패턴중에 Given-When-Then 이라고 있는데 한번 참고해서 작성해보시면 좋을 것 같아요 테코톡에도 테스트코드관련된 영상이 많아서 참고해보시면 좋을것같아요!

 

2주차 미션을 진행하며 테스트 코드를 처음 작성해봤는데 생소한 부분이 많았다. 다른 분들의 코드를 보니 주석으로 Given-When-Then을 나누어 처리한 패턴이 많이 보였다. 마침 이러한 리뷰를 받아서 테코톡 영상을 보고 테스트 코드에 대해 더 공부해봐야겠다.

📌  회고

2주차 미션은 1주차 때보다 오래 걸렸다. 클래스와 메서드를 어떻게 적절히 분리해야하는지가 제일 많이 고민한 부분이었다. 아직 많이 부족하지만..분리를 했다는 사실에 만족하고 다음 미션에서 더 잘해보고 싶다. 또 이번에 처음으로 코드 리뷰에 참여해봤는데 정말 쉽지가 않았다. 얼마 없는 지식을 끌어내어서 리뷰를 하는데, 그마저도 애매하게 알고 있는게 많아 끙끙거리며 검색을 하고 리뷰를 달았다. 확실히 이런 과정에서도 얻어가는 것이 많은 것 같다. 그리고 다른 사람들에게서 '이 코드는 이렇게 한 이유가 궁금하다'와 같은 리뷰를 받으면 그에 대한 정확한 답글을 달기 위해 또  검색해보고 스스로 생각해보는 시간이 많아졌다. 이게 바로 코드 리뷰의 장점 아닐까! 다음주에는 더 많은 코드 리뷰에 도전해봐야겠다.🙌

📌  다음 목표

• 기능 목록을 계속 업데이트하여 살아있는 문서 만들기(예외사항 기능 목록에 꼼꼼히 작성하기) 
• 코틀린 컨벤션 잘 지키기
• 클래스와 메서드를 적절히 분리하는 연습하기