[우아한테크코스] 📚 레벨로그 - 레벨1 인터뷰

 

📚 레벨로그

 

원시값, 컬렉션을 왜 포장해야 하는가?

• 원시값, 컬렉션을 하나의 클래스로 감싼 형태를 래퍼 클래스, 일급 컬렉션이라고 한다.
• 원시값과 컬렉션을 포장하면 상태에 대한 처리를 외부가 아닌 내부에서 할 수 있다.
• 즉, 상태를 외부에 노출시키지 않고, 객체에게 메시지를 던지는 구조로 만들면서 객체지향적이고 응집도 높은 설계가 가능하다.
• Wrapping한 상태에 대한 로직을 여러 곳에서 중복적으로 작성할 필요가 없다.
• 하나의 클래스 내에서 행위를 관리하므로, 상태에 대한 로직이 변경되었을 때 단 하나의 클래스만 수정하면 된다. (높은 유지보수성을 보장한다.)

 

TDD(Test Driven Development)란?

• TDD는 테스트 주도 개발로, 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 방법론이다.
• TDD는 크게 3가지 단계로 이루어진다.
  • Red - 실패하는 테스트 코드를 작성한다. 이 때, 컴파일조차 되지 않을 수 있다.
  • Green - 가능한 빠르게 테스트 코드가 통과하게끔 수정한다. 이때 어떠한 죄악을 저질러도 좋다.
  • Refactor - 이전 단계를 거치며 발생한 코드의 중복, 매직 넘버 등을 제거한다.
• TDD를 거치면서 자연스럽게 기능 구현 및 코드 수정에 대한 근거를 얻을 수 있다. 예를 들어, Green 단계에서 어떠한 죄악을 저질러서 단순히 테스트 코드가 빠르게 통과하게끔 구현했다면, Refactor 단계에서는 이 코드가 '왜' 통과해야 하는지 근거를 찾도록 생각이 유도된다. 이 과정을 통해 얻은 근거를 바탕으로 코드를 수정할 수 있다.
• 프로덕션 코드를 작성하기 전에, 각 기능에 대한 테스트 코드를 먼저 작성하다보니, 이와 반대되는 상황에서 테스트 코드 작성을 깜빡하는 상황을 방지할 수 있다.
• 각 기능에 대한 테스트 코드가 작성되어 있기 때문에, 기능을 수정할 때 테스트 코드를 믿고 과감하게 도전할 수 있다.
• 작성하고자 하는 테스트 코드가 어떤 기능인지 먼저 고려해야 한다. 즉, Development 이전에 Design 과정을 거쳐야 하므로 설계에 대한 고민을 깊게 하며 더 탄탄한 프로그램을 만들 수 있다.
• TDD를 거치며 만들어진 테스트 코드는 하나의 레퍼런스이다. 특정 기능이 어떠한 목적으로 만들어졌는지, 어떤 경우에 예외가 발생하는지 등을 테스트 코드를 살펴보면 알 수 있다.
• 위와 같은 TDD의 장점은 곧 개발자에게 자신감을 불어넣어 준다. 기능이 변경되었을 때 프로그램이 오동작하지는 않을지 걱정했다면 이제는 먼저 작성해 놓은 테스트 코드를 믿고 과감하게 실행에 옮길 수 있을 것이다.
• 하지만 TDD가 항상 좋다고 할 수는 없다. 예를 들어, 데드라인(예를 들어 미션..)이 몇 시간 남지 않은 상황에서 테스트 코드를 작성하겠다고 결과물을 제출하지 못한다면 아무 소용이 없다. 이때에는 오히려 TDD에 대한 안 좋은 감정만 남게 될 것이다. 결론적으로, TDD도 결국 하나의 개발 방법론이자 도구이기 때문에, 현 상황이 TDD를 적용하기 알맞은 상황인지를 명백히 고려할 필요가 있다.

 

점진적 리팩터링

• 프로그램의 요구사항은 계속해서 변경되기 때문에, 리팩터링하는 상황을 정말 많이 마주칠 것이다. 이럴 때마다 컴파일 에러가 발생하거나, 기껏 작성해 놓은 테스트 코드가 깨진다면 리팩터링에 대한 자신감이 떨어지고, 무수히 많은 오류에 노출될 것이다.
• 점진적 리팩터링은 한 번에 많은 것을 고치지 않고, 순차적으로 접근하여 기존의 테스트 코드가 깨지거나, 컴파일 에러가 발생하는 상황을 최소화하는 리팩터링 방식이다.
• 코드를 수정해야 하는 여러 상황이 있을 것이다.
  • 함수명 수정
  • 함수 파라미터( or 반환) 변경 / 추가 / 제거
  • 함수의 클래스 이동
• 점진적 리팩터링을 하는 여러 방법이 있겠지만, 자주 사용하는 방식은 아래와 같다.
  1. 변경하고자 하는 함수를 오버로딩하거나 함수명 끝에 숫자를 붙여 새로운 함수를 만든다.
  2. 새롭게 만든 함수에 수정하고자 하는 기능을 작성한다.
  3. 기존 함수를 사용하던 코드를 새로운 함수로 대체하여 컴파일 에러가 발생하지 않는지, 테스트 코드가 깨지지 않는지 확인한다.
  4. 새로운 함수에 문제가 없으며, 더 이상 기존 함수가 필요하지 않다면 제거한다.

 

함수형 프로그래밍

• 함수형 프로그래밍은 자료처리를 수학적 함수의 계산으로 취급하는 프로그래밍 패러다임이다.
• 무엇(What)을 수행할 것인지에 집중하기 때문에, 구체적인 작업은 라이브러리에 의존한다.
• 함수형 프로그래밍을 나타내는 여러 키워드가 있다.
  • 불변(Immutable Data) - 값을 한 번 결정되면 더 이상 변경되지 않는다. 즉, Thread-safe하기 때문에 의도치 않는 오류를 방지할 수 있다.
    • Kotlin의 val 키워드는 불변이 아닌 final이다. 초기화만 다시 하지 못하는 것이지 객체 내부 값이 변경되면 이 또한 가변이다.
    • 어떠한 함수의 반환으로 매번 새로운 객체를 생성하여 반환하는 방어적 복사를 통해 불변을 지킬 수 있다.
  • 순수함수 - 입력에만 의존하며, 부수 효과를 일으키지 않는 함수를 의미한다. 함수형 프로그래밍의 수학적 함수의 계산에 핵심이 되는 개념이다.
  • 부수효과 - 어떠한 행위로 인해 프로그램에 영향을 주는 효과이다.
    • Console, File I/O
    • 예외가 발생하여 프로그램이 중단
    • 함수 외부의 값 변경
  • 일급 시민 객체
    • 함수를 변수에 저장할 수 있다.
    • 함수를 인자로 전달받을 수 있다.
    • 함수를 반환값으로 사용할 수 있다.
  • 참조 투명성 - 동일한 입력에 대해 항상 동일한 결과를 반환한다. 즉, 입력에 대한 처리를 투명하게 할 수 있어야 한다. 어떤 함수를 실행했을 때 입력으로 들어온 객체가 변경되어 Side-Effect가 발생하고, 다시 해당 객체에 대해 함수를 실행했을 때 다른 값이 반환된다면 참조 투명성을 지키지 못하고 있는 경우이다.