초보자를 위한 인터뷰 질문 요약
출처 초보자를 위한 인터뷰 질문
사용 언어 자바
좋은 코드란?
세간에 알려진 좋은 코드
- 읽기 쉬운
- 중복 없는
- 테스트하기 편한
객체 지향 프로그래밍 OOP
기존의 컴퓨터 중심적 패러다임이 아닌 인간이 중심이 되는 프로그래밍 패러다임이다
현실 세계의 사물들을 객체로 해석하고 필요한 특징들을 추출해 프로그래밍 하는 것 - 추상화
재사용성이 높고 동작원리를 몰라도 사용 가능해지기 때문에 생산성도 높아진다
객체 단위로 코드가 나눠져 디버깅과 유지보수에 유리하다
객체간 정보교환에 메시지를 써서 오버헤드가 많이 발생하지만 하드웨어의 발전으로 보완됨
단점은 객체가 예측할 수 없는 상태(변수)를 가지기 때문에 내부에서 버그를 발생시키는 것
객체 지향적 설계 원칙
기본적으로 SOLID 원칙을 따른다
SRP(Single Responsibility Principle) :단일 책임 원칙- 클래스는 단 하나의 책임을 가져야 하며 클래스를 변경하는 이유는 단 하나의 이유이어야 한다.
OCP(Open-Closed Principle) :개방-폐쇄 원칙- 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.
LSP(Liskov Substitution Principle) :리스코프 치환 원칙- 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상동작해야 한다.
ISP(Interface Segregation Principle) :인터페이스 분리 원칙- 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
DIP(Dependency Inversion Principle) :의존 역전 원칙- 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.
RESTful API
REpresentational State Transfer한 API
- REST의 기본원칙을 성실히 지킨 서비스 디자인
HTTP Method로 자원을 처리하는 자원(Resource)중심의 API 설계
Resource Oriented Architecture
REST의 6가지 원칙
- Uniform Interface
- Stateless
- Caching
- Client-Server
- Hierarchical System
- Code on demand
RESTful한 API 디자인의 의미
- 리소스와 행위를 명시적, 직관적으로 분리
- 리소스(URI)가 가리키는 것은 명사로 표현되어야 한다
- 행위는 HTTP Method로 표현하며, 목적을 분명하게 나눠 사용한다
- Message는 Header와 Body를 명확하게 분리해 사용한다
- Entity에 대한 내용은 Body에 담는다
- App 서버행동의 판단근거(컨트롤 정보)는 Header에 담는다
- (API 버전 정보, 응답 받을 MIME 타입 등)
- Header와 Body는 http Header와 http Body로 분할가능
- http Body에 들어가는 json으로도 분리가능
- API 버전을 관리한다
- 환경은 항상 변하므로 API의 signature가 변경될 수 있음을 유의
- 특정 API 변경시 하위호환성을 보장해야함
- 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다
- 브라우저, 서버의 송신 형태를 json, from-data 중 택1 통일
- 다른 말로 표현하자면 URI가 플랫폼 중립적이어야 한다
RESTful API 디자인의 장점
- Open API를 제공하기 쉽다
- 멀티플랫폼 지원 및 연동이 용이함
- 원하는 타입으로 데이터를 주고 받을 수 있다
- 기본 웹 인프라(HTTP)를 그대로 사용할 수 있다
RESTful API 디자인의 단점
- 사용할 수 있는 메소드가 4개 뿐
- 분산환경에는 부적합
- HTTP 통신 모델에만 지원
TDD
Test-Driven Development란
매우 짧은 개발 사이클의 반복에 의존하는 소프트웨어 개발 프로세스
- 요구되는 새 기능에 대한 자동화된 테스트케이스를 작성
- 해당 테스트를 통과하는 가장 간단한 코드를 작성
- 상황에 맞게 리팩토링하는 과정을 거치는 것
테스트 추가
TDD에서 새 기능을 추가하려면 테스트를 먼저 작성한다
그러려면 해당 기능의 요구사항과 명세를 확실하게 이해해야 한다
이는 코드 작성 전에 요구사항에 집중할 수 있도록 도와준다
모든 테스트를 실행해 새 기능을 검증
새 기능을 추가하면 이전 기능이 제대로 작동하지 않을 수 있다
더 위험한 경우는 개발자가 이를 미처 인지하지 못하는 경우다
이를 방지하기 위해 테스트 코드를 작성하는 것이고
새 기능과 기존 기능들을 동시에 확인할 수 있게된다
Refactor Code
테스트 기반으로 진행해 리팩토링 속도도 빨라지고 퀄리티도 향상된다
보다 객체지향적이고 확장이 용이한 코드,
재설계의 시간을 단축시킬 수 있는 코드,
디버깅 시간이 단축되는 코드가 TDD 와 함께 탄생한다
어차피 제대로 작동하는지 판단해야하는 시점이 온다
그 판단을 자동화해주면서, 코드 작성에 도움을 주는 것이 TDD이다
의문점들
- Q. 코드 생산성에 문제가 있지는 않나?
- 비즈니스 로직, 코드 디자인도 시간이 많이 걸리는데,
테스트 코드까지 작성하기란 여간 벅찬 일이 아니다
퀄리티보다 생산성이 더 요구된다면 TDD는 큰 걸림돌이 될 수 있다
- 비즈니스 로직, 코드 디자인도 시간이 많이 걸리는데,
- Q. 테스트 코드를 작성하기가 쉬운가?
- 진입 장벽이 존재한다
어떠한 부분을 어떻게 테스트해야할 지,
어떤 테스트 프레임워크가 우리의 서비스와 맞는지 등
많은 시간과 학습이 필요하고 개발은 팀 단위이기 때문에
팀원 전체가 익숙해져야 비로소 빛을 발하게 된다
- 진입 장벽이 존재한다
- Q. 모든 상황에 대해서 테스트 코드를 작성할 수 있는가? 작성해야 하는가?
- 생각지도 못한 예외 케이스가 존재할 수 있다
테스트가 반드시 필요한 부분에서 작성에 어려움이 발생한다면?
이러한 상황에서 주객이 전도되는 상황이 발생할 수 있다
테스트를 위해 코드구조의 변경을 고려하는 고민이 생긴다
실제 구현 코드보다 방대해진 코드를 관리하는 것도 쉽지않다
- 생각지도 못한 예외 케이스가 존재할 수 있다
모든 코드에 대해서 테스트 코드를 작성할 수 없으며 작성할 필요도 없다.
또한 테스트 코드를 작성한다고 해서 버그가 발생하지 않는 것도 아니다.
애초에 TDD 는 100% coverage 와 100% 무결성을 주장하지 않았다.
함수형 프로그래밍
immutable vs mutable
immutable 객체는 객체가 가진 값을 변경할 수 없으며,
변경시 새로운 객체를 생성해 변경된 값을 주입해 반환해야한다
first-citizen
함수형 프로그래밍 패러다임을 따르는 언어의 함수는 일급 객체로 간주된다
일급 객체
- 변수나 데이터 구조 안에 함수를 담을 수 있어
함수의 파라미터나 반환값으로 사용할 수 있다 - 할당에 사용된 이름과 관계없이 고유한 구별이 가능하다
- 함수를 리터럴로 바로 정의할 수 있다
반응형 프로그래밍 Reactive Programming
함수형 프로그래밍 패러다임을 활용하는 것을 말한다
선언형 프로그래밍(declarative programming)이라고도 불리며,
명령형 프로그래밍(imperative programming)의 반대말이다
반응형 프로그래밍은 기본적으로 모든 것을 스트림(stream)으로 본다
스트림이란 값들의 집합으로 볼 수 있으며
제공되는 함수형 메소드를 통해 데이터를 immutable 하게 관리할 수 있다
댓글남기기