[우아한테크코스 5기] 1주차 회고 - (양념 반 후라이드 반) 설렘 반 걱정 반

2월 7일을 시작으로 우아한테크코스 5기가 시작했습니다.

필자는 영광스럽게도 'AOS 부나'라는 이름으로 우테코에 참여할 수 있게 되었습니다!

 

사실 우테코가 시작되기 전에 기대와 설렘도 있었지만, 내향적인 성격 탓에 걱정 또한 많이 했습니다.

하지만 처음으로 팀원들과 매칭되고 이야기를 나눠보니 괜한 걱정이었다는 것을 알 수 있었습니다.

다들 친절과 열정까지 겸비하신 분들이었습니다.

 

'우아한테크코스 선릉캠퍼스'

 

처음 캠퍼스에 들어오자마자, 말로만 듣던 열려있는 IT기업 사무실 냄새가 폴폴 진동했습니다.

앞으로의 10개월이 기대되는 순간이었습니다!

 

 

'국밥이 가성비라던 시대는 끝났다..'

 

한 주를 보내면서 느꼈던 점은 일단 경기에서 선릉역까지 출퇴근 시간대에 오가는 것이 체력 소모가 크다는 점이었습니다.

또한, 강남 근처라 그런지 점심 시간대에는 모든 식당에 직장인들의 웨이팅은 기본이었고, 물가 또한 어마무시했습니다.

이러한 점을 AOS 1조 데일리미팅에 참관하던 제임스 코치에게 털어놓으니 숨은 식당가를 추천해 주셨습니다.

직접 가보니 음식 종류와 자리도 정말 많고, 가격대 또한 비교도 안 되게 저렴했습니다 😭👏

고마워요 제임스!

 

(* 다행히 3월부터는 우테코에서 50만 원의 생활비를 지원해 주기 때문에 교통비 + 식비 문제를 일부 해결할 수는 있을 듯합니다.)

주변에 자취하시는 크루분들이 정말 부러웠습니다..ㅎㅎ

 

오른쪽 킷캣은 현재 페어인 수달이 나눠준 간식입니다.

와사비 맛도 맛있다고 해서 먹어봤는데 맛.. 있었습니다! 수달 최고 :)

 

---

 

Level1에서는 프리코스에서 진행했던 미션들처럼, 매주 하나씩 새로운 주제가 주어지는 방식이었습니다.

단순히 코딩을 한다기보다, 조금 더 Kotlin 스럽게 코드를 작성하는 방법에 대해 공부하는 것이 목표입니다.

 

그렇기 때문에 수업에서는 Kotlin이 무엇인지에 대해 우선적으로 교육해 주셨습니다.

그 외에, 여러 가지 기본적이지만 놓치고 있던 부분에 대해서도 공부해 볼 수 있었습니다.

 

 

Kotlin이란?

 

Kotlin은 Jetbrains에서 2011년 7월에 공개한 JVM, 안드로이드, 자바스크립트 및 네이티브를 대상으로 하는 정적 타입 지정 언어입니다.

(정적 타입 지정 언어는 컴파일 시 타입이 결정되는 언어입니다.)

Java와 상호 운용을 중요시하며, OOP스타일과 FP스타일을 모두 사용할 수 있으며, 이 둘을 혼합하여 사용할 수도 있습니다.

또한, Kotlin 코드를 Java로 변환한다고 했을 때 발생하는 성능 문제는 전혀 없으며, Java와 달리 타입 추론이 가능하고 훨씬 간결, 편리하게 코드를 작성할 수 있다는 장점을 가지고 있습니다.

 

 

왜 만들어졌을까?

 

2011년 7월은 Java 버전이 7까지 공개된 시절입니다.

지금과 달리 Java는 Stream, Lambda 등을 지원하지 않아 불편한 점이 많았습니다.

또한, 이러한 불편함에 비해 업데이트 속도가 매우 느려 개발자들의 아쉬움은 커져만 갔습니다.

아러한 부족함을 극복하기 위해 Jetbrains는 Kotlin이라는 훨씬 간결하고 편리한 언어를 개발하였고, 2012년 6월부터는 안드로이드에서도 코틀린 사용이 가능해졌습니다.

 

 

생성자 체이닝

 

생성자 체이닝이란 this, super 키워드를 통해 다른 생성자를 호출하는 기법입니다.

Java와 Kotlin은 공통적으로 주생성자를 반드시 호출해줘야 하기 때문에, 부생성자가 결국에는 타고 타고 주생성자를 호출해야 합니다.

여기서, 기본값을 지정하면 secondary constructor를 줄일 수 있습니다.

 

class Car(val name: String, var position: Int = 0)

위 코드는 실질적으로 2개의 생성자이지만, 기본값을 지정해 줌으로써 1개의 생성자인 것처럼 간결하게 만들 수 있습니다.

 

 

함수 vs 메서드

 

지금까지 함수 = 메서드라고 알고 있었으며, Kotlin 클래스의 val, var 키워드를 생성하여 만드는 변수가 필드라고 '잘못' 알고 있었습니다.

 

메서드는 클래스 내에 선언되어 있는 함수를 의미합니다.

(다른 말로 클래스를 참조하는 함수라고도 할 수 있습니다.)

 

그렇기 때문에 Kotlin에서는 멤버 함수, 지역 함수가 메서드에 속합니다.

추가로, Kotlin에서는 Extension을 지원하는데, 이것이 함수냐 메서드냐에 대한 의견이 분분하다고 합니다.

하지만, 이 또한 클래스를 참조해야 하기 때문에 메서드라고 주장하는 의견이 거의 대다수라고 합니다.

 

반대로, 클래스 외부에 선언되어 있는 Top-level 함수의 경우는 메서드라고 할 수 없습니다.

Java에서는 class 외부에 함수를 작성할 수 없기 때문에 메서드라는 개념만 존재했지만, Kotlin에서는 이 둘을 분리해서 칭한다는 사실을 알 수 있었습니다.

 

프로퍼티(Property) vs 필드(Field)

객체지향에서 객체의 고유한 속성(=특징)을 가지는데 이를 프로퍼티라고 합니다.

그리고 이에 대한 실체를 필드라고 부릅니다.

 

Kotlin은 val 또는 var 키워드를 통해 변수를 선언할 수 있습니다.

이는, 단순히 어떠한 데이터에 대한 타입 추론뿐만 아니라 getter/setter를 생략할 수 있도록 하기 위함도 있습니다.

또한 getter/setter를 커스텀할 때, 숨어있는 field를 확인할 수 있습니다.

 

반면, Java는 변수를 선언하고 나면, getter와 setter 함수를 별도로 선언해주어야 합니다.

 

즉, Java에서는 Field라고 부르던 개념이 Kotlin에서는 Property라고 칭하며,

Property는 아래와 같은 역할을 포함하는 개념이라고 할 수 있습니다.

• val의 경우 field + setter
• var의 경우 field + getter + setter

 

일급 시민 객체(First citizen object)

 

Kotlin에서 함수는 일급 시민 객체입니다.

일급 시민 객체는 아래 3가지 조건을 만족하는 함수를 의미합니다.

• 변수에 함수를 할당할 수 있어야 합니다.
• 함수의 인자로 함수를 전달할 수 있어야 합니다.
• 함수의 반환으로 함수를 전달할 수 있어야 합니다.

 

값과 상태를 Kotlin 스럽게 체크하자

자바에서 사용되는 IllegalArgumentException, IllegalStateException를 표준 예외라고 부르는데, throw xxxException()과 같은 방식을 Kotlin에서는 require()과 check() 함수를 통해 훨씬 간결하게 작성할 수 있습니다.

 

require vs check : 값에 대한, 객체에 대한 상태 차이

Require (값을) 요구하다 / IllegalArgumentException 예외 발생

Check (상태를) 체크하다 / IllegalStateException 예외 발생

 

 

테스트 코드

 

테스트 코드도 문서입니다.

과거에는 프로덕션 코드를 테스트할 때 직접 출력해서 확인하였지만, 테스트 이후에 불필요한 코드를 지우는 것이 번거롭기 때문에 테스트 코드를 따로 분리하게 되었다고 합니다.

 

Happy case, Exception case 중에 Exception case를 먼저 테스트하는 것이 좋은 습관입니다.

(Exception case : 최솟값, 최댓값 같은 경곗값을 기준으로 테스트)

 

테스트 케이스를 얼마나 작성해야 하는가에 대한 절대적인 기준은 없지만, 리뷰어, 페어, 본인이 심리적 안정감이 들 때까지 테스트 코드를 작성하는 것도 좋은 방법이라고 합니다.

 

 

random은 테스트하기 힘드므로 테스트하기 어려운 부분을 분리해야 한다!

1. Car클래스와 테스트하기 어려운 메서드를 open으로 변경한다.
2. generateRandomNumber()로 분리 -> 접근제어자를 private에서 open으로 변경한다.
3. 테스트 코드 파일에서 자동차에 대한 익명 클래스를 만든다. (val car = object: Car { override generateRandomNumber })

⭐ 테스트 가능한 구조로 바꾸어야 한다.

⭐ 외부에서 사용할 수 있도록 하위호환되도록 만들어야 한다.

 

 

그 외 알아두면 좋은 내용

grep.app 에 방문하여 키워드를 검색하면 어떤 네이밍을 많이 사용하는지 grep 해줍니다.

예를 들어, judgement와 judgment의 사용 빈도를 알 수 있습니다.

실무에서 요구하는 역량은 새로운 프로젝트를 만드는 것보다 90% 이상은 이미 있는 프로젝트를 유지보수하는 것이기 때문에 기존에 있는 코드를 잘 읽고 수정(리팩토링)하는 역량이 필요합니다.

따라서 네이밍이 얼마나 중요한지 고민해 볼 필요가 있습니다.