📚 좋은 코드란 무엇인가

• 읽기 쉬운 코드 ???
• 중복이 없는 코드 ???
• 테스트가 용이한 코드 ???

💡 좋지 않은 코드가 적은 코드!!!

📖 좋지 않은 코드

1) 쓰이지 않는 코드 : 어디선가 쓰일 수 있다는 불안감 때문에 삭제하지 못하는 코드
2) 응급처치를 한 코드 : 다른 로직을 추가해야 하지만 수정으로 인한 side effect가 두려워 함수 내부에 억지로 처리해놓은 코드

📖 좋지 않은 코드를 줄이는 방법

1) 코드 간의 의존성을 파악하여 의존성이 잘 드러나는 추상화
2) 일관성 있어 가독성이 좋은 코드 (Naming, Directory 등)
3) 적절히 확장 가능한 설계

📚 OOP (Obejct Oriented Programming)

• 인간 중심적 프로그래밍 패러다임
• 현실세계를 프로그래밍으로 구현하는 것

💡 현실 세계의 사물들을 객체로 인식하여 그 객체로부터 애플리케이션에 필요한 특징들을 구현하는 방식으로 프로그래밍하는 것

📖 장점

1) 코드의 재사용성 증가 : 자주 사용되는 로직을 라이브러리로 만들어 재사용 가능하고, 신뢰성 확보 가능
2) 라이브러리를 각종 예외상황에 맞게 잘 만들어두면 개발자의 사소한 실수로 인한 에러를 컴파일 단계에서 잡아낼 수 있기 때문에 버그 발생이 감소
3) 개발자는 내부에서 어떻게 동작하는지 몰라도 라이브러리가 제공하는 기능들을 사용할 수 있기 때문에 생산성 향상
4) 객체 단위로 코드가 나뉘어 작성되기 때문에 디버깅이 쉽고 유지보수에 용이
5) 데이터 모델링을 할 때 객체와 매핑하기 쉬워 요구사항을 명확하게 파악 가능

📖 단점

1) 객체 간의 정보 교환이 모두 메시지 교환을 통해 일어나므로 실행 시스템에 많은 overhead가 발생

하드웨어의 발전으로 많이 보완되었다!

2) 객체가 변수를 통해 예측할 수 없는 상태를 갖게되어 애플리케이션 내부에서 버그를 발생시킬 수 있다.

함수형 프로그래밍 패러다임 등장

🌟 객체 지향적 설계 원칙

1. SRP (Single Responsibility Principle) : 단일 책임 원칙

클래스는 단 하나의 책임을 가져야 하며 클래스를 변경하는 이유는 단 하나의 이유여야 한다.

2. OCP (Open-Closed Principle) : 개방-폐쇄 원칙

확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.

3. LSP (Liskov Substitution Principle) : 리스코프 치환 원칙

상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

4. ISP (Interface Segregation Principle) : 인터페이스 분리 원칙

인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.

5. DIP (Dependency Inversion Principle) : 의존 역전 원칙

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.

📚 RESTful API

📖 REST (Representational State Transfer)

◾ 🌟 Uniform Interface (유니폼 인터페이스)

• 하나의 URL로는 한 개의 데이터만 가져와야 한다.
• URL만 보고 어떤 정보가 들어올 것인지 예측이 가능하다.

◾ Stateless (무상태성)

• 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다.
• 세션이나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 처리한다.
• 서비스의 자유도가 높아지고 구현이 단순해진다.
• 클라이언트는 요청만으로 자원을 받을 수 있도록 요청에 필요한 모든 정보들을 담아 메시지를 보내야 한다.

◾ Cacheable (캐시 가능)

• HTTP라는 기존 웹표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능을 적용할 수 있어야 한다.
• 요청을 통해 보내는 자원(이미지 등)들의 캐싱이 가능해야 한다.

◾ Client-Server (클라이언트-서버 구조)

• 클라이언트와 서버의 역할이 확실히 구분되기 때문에 개발이 명확해지고 의존성이 줄어든다.
• Client : 요청(Request)
• Server : 응답(Response), API 제공

◾ Layered or Hierarchical system (계층 시스템)

• 계층으로 구성이 가능해야 하며, 각 계층에 속한 구성 요소는 인접하지 않은 계층의 구성요소를 알 수 없다.
• 다중 계층으로 구성될 수 있어 보안, 로드 밸런싱, 암호화 계층을 추가해 구조가 유연하다.
• Proxy, 게이트웨이 등 네트워크 기반 중간 매체를 사용가능하다.

◾ Self-discriptiveness (자체 표현 구조)

• REST API 메시지만으로 쉽게 이해할 수 있는 자체 표현 구조로 이루어져야 한다.

🌟 RESTful API 디자인

1) 리소스와 행위를 명시적이고 직관적으로 분리한다.

• URI는 자원을 가리켜야 하며, 명사로 표현되어야 한다.
• 행위는 HTTP method로 표현한다. (GET: 조회, POST: 생성, PUT: 기존 entity 전체 수정, PATCH: 기존 entity 일부 수정, DELETE: 삭제

2) Message는 Header와 Body를 명확히 분리하여 사용한다.

• header: API 버전 정보, MIME 타입 등
• body: entity에 대한 내용 등

3) API 버전을 관리한다.

• 특정 API를 변경할 때에는 반드시 하위 호환성을 보장해야 한다.
• 환경은 항상 변하기 때문에 API의 signature가 변경될 수 있음에 유의해야 한다.

4) 서버와 클라이언트가 같은 방식으로 Message를 보내도록 해야 한다.

• URI가 플랫폼 중립적이어야 한다.
• Message의 형식이 일치해야 한다.

📖 RESTful API의 장점과 단점

장점

• Open API를 제공하기 쉽다.
• 멀티 플랫폼 지원 및 연동이 용이하다.
• 원하는 타입으로 데이터를 주고 받을 수 있다.
• 기존 웹 인프라(HTTP)를 사용하여 통신할 수 있다.

단점

• 메서드의 종류에 제한이 있다.
• 분산 환경에는 부적합하다.
• HTTP 통신 모델에 대해서만 지원한다.

📚 TDD (Test-Driven Development)

매우 짧은 개발 사이클의 반복에 의존하는 소프트웨어 개발 프로세스

요구되는 새로운 기능에 대한 자동화된 테스트케이스와 해당 테스트를 통과하는 가장 간단한 코드를 작성하여 상황에 맞게 리팩토링하는 과정을 거친다.

📖 좋은 테스트란?

1) Fast

테스트는 빠르게 동작하여 자주 돌릴 수 있어야 한다.

2) Independent

각각의 테스트는 독립적이며 서로 의존해서는 안된다.

3) Repeatable

어느 환경에서도 반복 가능해야 한다.

4) Self-Validataing

테스트의 결과는 성공 또는 실패(Boolean)로 자체적으로 검증 가능해야 한다.

5) Timely

테스트는 적시(테스트하려는 실제 코드를 구현하기 직전)에 구현해야 한다.

📖 장점

Add a Test

새로운 기능을 추가하기 전에 테스트를 하여 잘 작동하는지 빠르게 확인할 수 있다. 테스트를 작성하기 위해 개발자는 해당 기능의 요구사항과 명세를 분명히 이해하고 있어야 한다.

Run all tests and see if new one fails

새로운 기능을 추가하면 잘 작동하던 기능이 제대로 작동하지 않는 경우가 발생할 수 있다. 새로운 기능을 추가할 때 테스트 코드를 작성함으로써, 새로운 기능이 제대로 작동함과 동시에 기존의 기능들이 잘 작동하는지 테스트를 통해 확인할 수 있다.

Refactor code

코드의 양이 방대해지면 작은 코드로 나누는 리팩토링이 필요해진다. 이때 테스트 코드를 통해 나누어진 기능들이 잘 작동하는지 테스트 할 수 있어 리팩토링 속도가 빨라지고, 코드 퀄리티도 향상된다.

📖 의문점

코드 생산성 문제

테스트 코드를 작성하기에 시간이 촉박한 상황(코드 퀄리티보다 빠른 생산성이 요구되는 경우)에서는 TDD가 어려울 수 있다.

테스트 코드 작성 문제

어떠한 부분을 어떤 테스트 프레임워크를 사용하여 어떻게 테스트해야 하는지 등에 대한 학습이 필요하고 익숙해져야 한다.

모든 상황에 대한 테스트 코드 작성

기능에 대한 테스트 코드 작성에 어려움이 있거나 생각지 못한 예외 케이스가 존재하는 경우 애플리케이션 코드보다 테스트 코드에 대해 고민하게 될 수 있다. 모든 코드에 대해 테스트 코드를 작성할 수 없다. 테스트 코드가 모든 버그를 해결해줄 수는 없다.

📚 함수형 프로그래밍

Java8부터 함수형 프로그래밍 지원

📖 함수형 프로그래밍 특징

Immutable

함수형 프로그램은 기본적으로 한 번 값이 변수에 할당되고 나면 이후에 값이 변경되지 않기 때문에 부수효과(Side Effect)가 발생하지 않는다. 이러한 프로그램을 참조 투명성을 가진다고 말한다. 참조 투명성을 가지는 함수형 프로그래밍은 멀티 코어 프로세스에서 교착 상태에 빠지지 않는다는 장점이 있어 동시성 프로그래밍에서 강력한 프로그래밍 패러다임으로 작용한다.

First-class citizen

함수형 프로그래밍 패러다임을 따르고 있는 언어에서의 함수는 일급 객체로 간주된다.

일급 객체

• 변수나 데이터 구조에 할당될 수 있다.
• 함수의 파라미터로 전달 가능하다.
• 함수의 반환값으로 사용 가능하다.
• 할당된 이름과 관계없이 고유한 구별이 가능하다.
• 리터럴로 바로 정의 가능하다.

💡 함수를 일급객체로 다룰 수 있도록 해주는 Functional Interface(단 하나의 추상 메서드를 가지는 인터페이스)를 통해 코드의 재활용 단위가 클래스였던 것이 함수 단위로 바뀌면서 조금 더 유연한 개발이 가능해졌다!

📚 MVC 패턴

📖 MVC 패턴을 사용하는 이유

• 비즈니스 로직과 UI 로직을 분리하여 유지보수를 독립적으로 수행 가능
• Model과 View가 다른 컴포넌트들에 종속되지 않아 애플리케이션의 확장성, 유연성에 유리함
• 중복 코드의 문제점 X

M - Model (모델)

애플리케이션의 정보, 데이터를 나타내는 객체로, 비즈니스 로직을 구현하는 영역

• 모든 데이터를 가지고 있어야 한다.
• 뷰나 컨트롤러에 대한 어떤 정보도 없어야 한다.
• 모델의 상태가 변경되면 변경에 대해 컨트롤러와 뷰에게 이를 통지하는 방법을 구현해야 한다.

V - View (뷰)

사용자가 요청한 화면을 보여주기 위해 모델로부터 데이터를 얻어오는 영역

• 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
• 모델이나 컨트롤러와 같이 다른 구성요소에 대해 알 수 없다.
• 변경이 발생하면, 변경에 대해 통지하는 방법을 구현해야 한다.

C - Controller (컨트롤러)

클라이언트의 요청사항을 파악한 후 그 요청에 맞는 데이터를 Model에게 요청하고, 그 데이터를 View에 반영하여 사용자에게 전달

• 모델이나 뷰에 대해 알고 있어야 한다.
• 모델이나 뷰의 변경을 모니터링 해야 한다.

출처 : https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Development_common_sense
https://jbee.io/etc/what-is-good-code/
https://velog.io/@estell/REST-API-6%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99
https://meetup.toast.com/posts/92
https://mangkyu.tistory.com/182
https://tecoble.techcourse.co.kr/post/2021-09-30-java8-functional-programming/
https://medium.com/@jooyunghan/%ED%95%A8%EC%88%98%ED%98%95-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EC%86%8C%EA%B0%9C-5998a3d66377
https://cocoon1787.tistory.com/733
https://asfirstalways.tistory.com/180