[우아한테크코스] kotlin 프리코스 - 2주차 숫자 야구 회고록

 

우아한 테크코스 2주차가 끝났습니다.

1주차에서 학습한 내용들과 피드백을 공부하여 이번 주차는 1주차보다 할만했던 것 같습니다.

그런데.. 왜 이제서야 회고록을 쓰냐면.. 작성일 기준, 저번 주말 이틀 다 코딩테스트가 잡혀서 며칠을 밤새며 준비하느라 바빠서 이제서야 씁니다. ㅎㅎ...

이번 2주차는 실질적으로 하나의 프로그램을 만드는 느낌도 들었고, 현업이라 생각하고 Git의 자원관리 부분에서도 생각을 해보기도했습니다.

잡설을 마치고! 이번 시간에 무엇을 배우고 느꼈는지 확인해보겠습니다!

무엇이 핵심이었는가?

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

무엇을 배우고 느꼈는가?

 

1. 함수는 하나의 일만, 가독성 좋게 구현하자.

저번 주부터 신경 썼던 내용이기도 하다.

내가 우테코에서 배우는 것은 단순한 코딩이 아니라, `현업에서처럼` 코딩하는 것이다.

그러다보니, 나 혼자 알아보고 나 혼자 이해하는 그런 코딩은 절대로 금물인 것이다.

거기다가, 유지보수 측면도 생각해야하므로 당장만을 생각하고 코딩을 해서는 안된다.

 1. 함수는 하나의 일만
 2. 들여쓰기는 2이하
 3. 코딩 컨벤션을 지키자

이 세가지를 주의해서 최대한 신경써서 코딩을 했다.

이렇게 하다보니 코드를 완성했을 때, 많은 부분의 변화를 느꼈다.

 

우선, 확연하게 코드가 보기 좋아졌다.

코드를 보자마자 '아 이건 이거네?' 라고 생각이 들었다. 뿐만 아니라, 해당 코드가 무엇을 하고 있는지 확실하게 알기 때문에, 나중에 문제가 생겼을 때, 해당 부분을 빠르게 식별할 수 있어서 디버깅때 정말 편했다.

이런 식이면 예외 조건을 확실히 더 보기좋게 할 수 있었다.

`when`을 처음 사용한게 신기하다보니 막 써보고 싶었나보다..

 

2. 테스트 케이스를 통해 보다 쉽게 문제점이 있는지, 잘 작동하는지 파악하자.

이번 주간에서 가장 많이 배운 부분이다.

저번 주에도 테스트 케이스를 쓰긴 했는데, 그 때는 내가 직접 이용한다는 느낌 보다는 '통과 하자!' 이런 느낌이었다.다시 말해서, 그냥 주어진 테스트 케이스는 통과해야한다는 컷일 뿐, 내가 직접 테스트 케이스를 짜서 원하는 결과들을 뽑아내는 것은 아니었다.

 

하지만, 이번 주간에선 테스트 케이스를 직접 작성도 해서, 내가 원하는 결과가 나오는지 세세하게 분리해서 테스트를 해보았다. 이런 식으로 하니, 내가 무엇을 잘못하고 있는지, 아니면 잘 하고 있는지를 확실하게 알 수 있었다.

 

대표적인 예시론 다음과 같은 경우다.

    @Test
    fun `널 예외 테스트`() {
        assertSimpleTest {
            assertThrows<IllegalArgumentException> { runException() }
        }
    }

말 그대로, 입력값에 `Null`이나 공백이 들어가면 `IllegalArgumentException()`이 발생했는지 안했는지를 확인하느 것이다.

 

근데, 처음에 `NullPointerException()`이 뜨는 것이다.

'아니 왜지? 분명 `throw IllegalArgumentException()` 했는데??' 라고 생각했다.

하지만, 알고보니, 전에 나는

input?.let{inputException(it)}

이런 식으로 null 처리를 하고 난 뒤에 예외처리에 들어갔던 것이다.

이것이 왜 문제냐면, `?`를 통해 null이라 판별을 안하므로, null 예외 처리를 바로 하이패스 해버린 것이었다.

테스트케이스 덕분에 이 점을 빠르게 파악하고 다음과 같이 수정할 수 있었다.

    fun playGame() {			//게임 실행
        initGame()
        setOpponentNumber()
        while (true) {
            print("숫자를 입력해주세요 : ")
            val input = readLine()
            inputException(input)	// 예외 처리 구간 진입
            compareNumber(input!!)
            printResult()
            if (ballStrike[1] == 3) {
                initResult()
                break
            }
            initResult()
        }
    }
    
    fun inputException(input: String?) {	//예외 처리 구간
    require(!input.isNullOrEmpty()) {		// 널 예외 처리
        throw IllegalArgumentException()
    }

    val regex = "[1-9][1-9][1-9]".toRegex()
    require(input.matches(regex)) {			// 3자리 숫자 예외 처리
        throw IllegalArgumentException()
    }

    require(input[0] != input[1] && input[0] != input[2] && input[1] != input[2]) { //서로 다른 숫자 예외 처리
        throw IllegalArgumentException()
    }
}

이 처럼, 이번 주간에서 얻은 테스트 케이스 사용법을 통해, 앞으로도 보다 쉽게 테스트 케이스를 통한 정상 작동 여부, 문제점 파악을 할 수 있게 됐다. 많이 애용해야겠다!

 

3. Git의 자원관리를 하자.

생각치도 못한 부분이었다. 평소엔 코딩테스트를 하거나, 팀 프로젝트를 할 때, 그냥 바로 Git에 Push를 했으니..

근데, 코치님들의 조언에 따르면, Git에서 굳이 관리할 필요가 없는 자원들이 있으므로, 이런 것들은 Git에 올리지 않는 것이 효율성에서 더 좋다고 하셨다. 그래서 무엇을 올리지 말아야하고, 왜 그런지 확인을 했다.

 

우선, 대표적으로 `.class'파일과 설정파일, 빌드시 생성되는 파일들을 올리지 않는 것이 좋았다.

`.class`파일은 `.java`파일을 컴파일러를 통해 만들어지는 파일이므로, `.java`파일이 있다면 전혀 올릴 이유가 없는 파일인 것이다. 그리고 설정파일과 빌드시 생성되는 파일도, 결국 각자의 로컬에서 다뤄지는 부분이지, Git에 올릴 이유가 없을 뿐더러, 나중에 `merge`를 할 때, 충돌하여 문제가 발생할 가능성도 있기 때문에, 안올리는 쪽이 협업에서 중요하다.

 

그리고 더붙여서, 나중에 실무에서는 보안을 신경써야 할 것이다. 그러다 보면, Git에 올리지 말아야할 보안 파일들 또한 다루게 될 것이다. 그러므로, 이 때에도 해당 파일을 절대로 올리면 안되는 것이다.

 

최종적으로, 무엇을 왜 올리지 말아야할지 알았으니, 나는 `.gitignore`를 수정하여 git에 올리지 말아야할 파일들을 작성했다. 물론, 순수 타이핑을 해도 되겠지만, 그보다는 플러그인을 이용하거나 밑의 사이트를 이용해서 작성했다.

https://www.toptal.com/developers/gitignore

---

회고록을 마치며...

---

이번 주는 너무 힘든 주간이다보니, 회고록이 늦어져서 조금 찝찝했다.

하지만, 그래도 잘 해냈다고 생각이 들어 조금 안심이 든다.

1주차와는 다르게 2주차는 문법이 익숙해져서 그런지, 확실히 빠르게 작성도 했었고, 문법 외적인 측면에서 많은 신경을 쓸 수 있었다. 이러한 배움들이 모이고 모여서 나중에 현업에서도 쓸 수 있는 개발자가 될 것이라고 믿고 계속 정진해야겠다.