• 출처 : https://medium.com/javascript-scene/10-interview-questions-every-javascript-developer-should-know-6fa6bdf5ad95
• 번역본

자바스크립트 앱 개발자에게 있어 중요한 두 가지 프로그래밍 패러다임에 대해 말해볼 수 있는가?

자바스크립트는 OOP(Object-Oriented Programming) 및 함수형 프로그래밍, 필수적/절차적 프로그래밍을 지원하는 다중 패러다임 언어이다.
자바스크립트는 프로토타입 상속으로서 OOP를 지원한다.

알아두면 좋은 것들:

프로토타입 상속 (프로토타입, OLOO)
함수형 프로그래밍 (클로저, 일급함수, 람다lambras)

주의할 점:

패러다임이 무엇인지 모르거나, 프로토타입이나 함수형 프로그래밍에 대한 언급이 없으면 안 됨.

더 공부해볼 것:

프로토타입OOP
함수형프로그래밍

함수형 프로그래밍이란 무엇인가?

함수형 프로그래밍은 수학적 함수를 조합하여 프로그래밍 하고, 데이터 상태의 공유나 변경을 피한다.
1958년에 나온 Lisp는 함수형 프로그래밍을 지원하는 최초의 언어 중 하나였으며, lambda 미적분에 큰 영향을 받았다. Lisp 과 Lisp 계열의 많은 언어들이 오늘날에도 보편적으로 사용되고 있다.
함수형 프로그래밍은 ‘자바스크립트의 두 가지 핵심적 요소’에서 필수적인 개념이다.
일반적으로 쓰이는 몇 가지 함수형 유틸이 es5 에 추가되었다.

알아두면 좋은 것들:

순수함수(Pure function) / 함수 순수성
사이드 이펙트 피하기
함수는 심플하게 구성하기
함수형 언어의 예 : Lisp, ML, Haskell, Erlang, Clojure, Elm, F Sharp, Ocaml, Scala 등등..
FP를 지원하는 기능에 대한 언급: 일급함수, 고차함수, argument/value로서의 함수

주의할 점:

순수함수와 사이드 이펙트에 대한 언급이 없으면 안 됨.
함수형 언어의 예시를 들 수 없으면 안 됨.
FP를 사용할 수 있는 자바스크립트의 형태를 모르면 안 됨.

더 공부해볼 것:

Dao 의 불변성

고전적인 상속과 프로토타입 상속의 차이점은 무엇인가?

클래스 상속: 인스턴스(청사진처럼 클래스를 묘사하는 것)를 상속하고 계층 관계를 구축한다. 이는 계층적 클래스 분류이다.
인스턴스는 일반적으로 생성자 함수를 통해 new 로 인스턴스화된다. 클래스 상속은 es6의 ‘class’를 사용할 수도 안 할수도 있다.
프로토타입 상속: 인스턴스는 다른 객체로부터 직접 상속받게 된다. 인스턴스는 일반적으로 팩토리 함수 또는 ‘Object.create()’를 통해 인스턴스화 된다. 인스턴스는 다양한 객체로 구성될 수 있기 때문에 선택 상속을 쉽게 할 수 있다.
자바스크립트에서 프로토타입 상속은 클래스상속보다 간단하고 유연하다.

알아두면 좋은 것들:

클래스: 밀접한 결합이나 계층 구조/분류를 만든다.
프로토타입 : 체인 상속, 프로토타입 위임, 함수 상속, 객체 구성에 대한 것.

주의할 점:

클래스 상속에 대한 프로토타입 상속과 컴포지션에 대한 선호도를 어필

함수형 프로그래밍과 객체지향 프로그래밍의 장점과 단점은 무엇인가?

• OOP의 장점 : 객체의 기본개념을 이해하기가 쉽고 메소드 콜의 의미를 해석하기가 쉽다. OOP는 선언형보다 명령형 스타일을 사용하는 경향이 있다. 이 형식은 컴퓨터가 따라야 할 방향과 똑같이 진행된다.
• OOP의 단점 : OOP는 공유된 상태에 의존적이다. 객체와 행위는 일반적으로 동일한 엔티티에 고정되어 있으며, 비결정적(non-deterministic) 순서로 임의의 수의 함수에서 무작위로 액세스할 수 있으므로 바람직하지 않은 동작이 발생할 수 있다. 경쟁 조건(race condition)같은 예가 그것이다.
• FP의 장점 : 함수형 패러다임을 이용해서, 상태 공유 또는 사이드 이펙트를 피할 수 있다. 이는 같은 리소스에 대해 경쟁하는 어러 함수 때문에 생길 수 있는 버그를 제거한다. point-free형(일명 암묵적 프로그래밍) 함수를 사용하면 OOP에 비해 함수를 훨씬 근본적으로 단순화하고 재구성 가능하게 만들 수 있어 재사용이 용이하다.

FP는 또한 작업의 단계별 명령을 맞추는 대신 선언형과 의미구조 스타일을 선호하고 ‘무엇을 할 것인가’에 집중하는 경향이 강해서, 해야할 일에 집중하여 기본적인 기능이 ‘어떻게 처리될 것인가’를 알려준다.
이는 리팩토링과 성능 최적화에 엄청난 도움이 되며 전체 알고리즘을 코드 변경이 거의 없는 상태에서 보다 효율적으로 대체할 수 있다. 메모이제이션이나 엄격평가(eager evaluation) 대신 지연평가를 사용하는 예를 들수 있다.
순수함수를 사용하는 계산의 경우 리소스 충돌이나 레이스 컨디션 등을 우려하지 않고도 다중 프로세서나 분산 컨퓨팅 클러스터 전반적으로 쉽게 확장 가능합니다.

• FP의 단점 : Point-free 또는 대형 프로젝트 조합의 경우 FP의 과도한 사용은 결과코드가 더 추상적으로 지정되고, 간단하며 덜 구체적이기 때문에 가독성이 떨어지는 위험을 잠재적으로 가지고 있다.
  많은 사람들이 함수형 프로그래밍보다는 OOP 및 명령형 프로그래밍에 익숙하기 때문에 함수형 프로그래밍의 일반적인 사용법조차 새로운 팀원에게는 혼란스럽게 받아들여질 수 있다.
  FP는 OOP보다 학습 곡선이 가파르다. 왜냐하면 OOP의 광범위한 인기로 인해 OOP 언어나 학습자료는 훨씬 편안하게 공유될 수 있었지만, FP 언어는 훨씬 학문적이고 공식적인 경향이 있었다.
  FP 개념은 lambda 미적분, 대수학 및 범주 이론의 관용구나 표기법을 어떻게 사용하는지에 대해 논한다. 이 모든 것이 사전 지식을 필요로 한다.

알아두면 좋은 것들:

상태 공유와 관련된 문제에 대한 것들, 동일한 리소스에 대해 경쟁하는 다양한 것들, 기타 등등..
학습 곡선의 차이에 대한 인식
사이드 이펙트와 프로그램 유지 관리에 미치는 영향
고도의 함수 코드베이스이기 때문에 학습곡선이 높음
고도의 OOP 코드베이스가 동등한 FP 코드베이스와 비교했을 때 변화하기 쉽고 깨지기도 쉬움을 인식
불변성은 접근이 매우 쉽고 유연한 상태 히스토리를 제공하여 무한한 undo/redo, rewind/replay, 시간 이동 디버깅 등의 기능을 쉽게 추가할 수 있다. 불변성은 어느 패러다임에서든 가능하지만 공유된 상태가 많은 객체가 확산되는 것은 OOP의 구현을 복잡하게 한다.

주의할 점:

한 패러다임 또는 다른 패러다임의 단점을 열거할 수 없으면 안 된다. 어느 스타일로든 코딩해 본 경험이 있다면 제한사항 중 일부에 부딪혀 본 경험이 있을 것이다.

고전적인 상속을 선택하기 적절한 경우는?

답은, 적절한 경우는 거의 없다. 물론 싱글 레벨 이상에서 말고. 다중 레벨 클래스의 계층 구조는 안티패턴이다. 나는 이 도전을 몇 년간 이슈화 해 왔으며, 몇 가지 일반적인 오해 말고는 시원한 정답을 못 들었다.
종종 도전은 침묵을 마주해야 할 때가 있다.
함수는 때때로 유용하고 때로는 위험하며, 더 나은 선택이 있다면 늘 더 나은 선택을 사용하라: Douglas Crockford

알아두면 좋은 것들:

아주 가끔 혹은, 거의 쓰지 마라. 혹은 아예 쓰지 마라.
리액트 컴포넌트처럼 프레임워크 베이스에서의 클래스 같은 단일 레벨에서는 떄떄로 괜찮다.
클래스 상속에 비해 오브젝트 구성을 선호

더 공부해볼 것:

객체상속

언제가 프로토타입 상속이 적절한 경우인가?

몇 가지 유형의 프로토타입 상속이 있다.

위임 (즉, 프로토타입 체인)
Conceatenative (즉, mixin. ‘Object.assign()’)
Functional (함수형 프로그래밍과 혼동하지 말 것. 프라이빗 상태/ 캡슐화를 위한 클로저를 만드는 데 사용된다)
프로토타입 상속의 각 유형이 각각의 유스케이스를 가지고 있지만, 그것들은 모두 그와 동등한 유용한 조합 능력을 가지고 있다.
그것들은 has-a 나 uses-a, can-do 관계를 형성한다. 이는 클래스 상속으로 이루어지는 is-a 관계보다 더 유용할 수 있다.

알아두면 좋은 것들:

모듈 또는 함수형 프로그래밍이 확실한 솔루션을 제공하지 않는 상황
여러 소스에서 오브젝트를 생성해야 하는 경우
당신이 상속을 필요로 하는 모든 상황

주의할 점:

프로토 타입을 사용해야 하는 경우에 대한 지식이 없으면 안 된다.
mixin 이나 ‘Object.assign()’에 대한 개념이 없으면 안 된다

더 공부해볼 것:

프로토타입

클래스 상속보다 객체 구성을 선호한다는 것은 무엇을 의미하는가?

코드 재사용은 클래스에서 상속받고 객체 분류를 만드는 대신에 작은 단위의 함수를 new 객체로 모으는 방식으로 수행되는 것이 좋다.
즉, is-a 관계 대신 can-do, has-a 또는 uses-a 관례를 사용하라.

알아두면 좋은 것들:

클래스 하이어라키 구조를 피하라.
다루기 힘든 클래스 이슈는 피하라.
엄격한 분류를 피하라 (is-a 관계를 강제하는 것은 새로운 유스케이스의 경우에도 결국 틀린 것이다)
고릴라와 바나나 문제 (당신은 바나나를 원했지만, 당신이 얻은 것은 바나나를 들고 있는 고릴라와 전체 정글이었다)
코드를 좀더 유연하게 짜라.

주의할 점:

위의 문제를 언급하지 못하면 안 된다.
컴포지션과 클래스 상속 또 컴포지션의 장점간의 차이점을 명확하게 설명하지 못하면 안 된다.

양방향 데이터 바인딩 및 단방향 데이터 흐름은 무엇이며, 무엇이 다른가?

양방향 데이터 바인딩은 UI 필드가 모델 데이터에 동적으로 바인딩되는 것을 의미하며, UI 필드가 변경되면 모델 데이터가 함께 변경되며 그 반대의 경우도 마찬가지다.
단방향 데이터는 모델이 단일 소스임을 의미한다. UI의 변경 사항은 사용자의 의도를 모델에 알리는 메시지를 트리거한다(또는 React에서의 store). 모델만이 앱의 상태를 변경할 수 있다. 데이터가 늘 한 방향으로 흐르기 때문에 결과를 이해하기 쉽다.
단방향 데이터 흐름이 결정론적인 반면, 양방향 바인딩은 사이드 이펙트를 일으켜 더 따라가기 힘들고 이해하기 어렵다.

알아두면 좋은 것들:

리액트는 단방향 데이터 플로우의 새로운 표준사례이며, 리액트에 대한 언급을 하는 것은 아주 좋은 신호이다. Cycle.js는 단방향 데이터 흐름의 또 다른 대중적인 구현 방법이다.
Angular는 양방향 바인딩을 사용하는 인기있는 프레임워크이다.

주의할 점:

둘중 어느 것을 의미하는지에 대한 이해가 있어야 한다. 그 차이를 명확하게 설명해야 한다.

더 공부해볼 것 : 유투브 바로가기

모놀리식 vs 마이크로서비스식 설계의 장단점은 무엇인가?

모놀리식 아키텍처는 앱이 동일한 메모리 공간과 리소스를 공유하면서 함께 돌아가도록 설계된 코드 단위로 작성되었다는 것을 의미한다.
마이크로서비스 아키텍처는 앱이 자체적인 메모리 공간 안에서 실행되고 잠재적으로도 다양한 개별 시스템에서 독립적으로 확장될 수 있는 더 작고 독립적인 앱으로 구성되었다는 것을 의미한다.

• 모놀리식의 장점: 모놀리식 아키텍처의 가장 큰 장점은 일반적으로 로깅, 속도 제한, DOS 보호 같은 보안기능 등과 같은 많은 앱에서 크로스커팅 관심사(cross-cutting concern)가 많이 발생한다는 것이다.
  모든 것이 동일한 앱을 통해 실행될 때, 크로스커팅 관심사에 구성 요소를 조합하기가 쉽다.
  공유 메모리 액세스는 프로세스간 통신 (IPC) 보다 빠르기 때문에 성능상의 이점이 있다.

• 모놀리식의 단점: 모놀리식 앱은 앱이 발전함에 따라 밀접하게 결합되고 얽히게 되는 경향이 있다. 독립적인 확장이나 코드 유지보수를 위해 서비스를 분리하기가 어려워진다.
  모놀리식 아키텍처는 특정 서비스나 콘트롤러를 볼 때 명확치 않은 종속성이나 사이드 이펙트가 있기 때문에 이해가 훨씬 어렵다.

• 마이크로서비스의 장점: 마이크로서비스 아키텍처는 보통 더 잘 구성되어 있다. 각 마이크로서비스는 각자 특정한 기능이 있으며 다른 구성요소의 작업에는 신경쓰지 않는다. 분리된 서비스는 다른 앱(예를 들어 웹 클라이언트와 퍼블릭 API를 둘 다 제공할 때)
  의 목적을 충족시키기 위해 재구성하는 것이 더 원활해진다.

• 마이크로서비스의 단점: 새롭게 마이크로서비스 아키텍처를 구축할때 설계 시점에 예상치 못한 많은 문제를 발견하게 될 수 있다. 모놀리식 앱은 별 노력 없이도 이런 크로스 커팅 문제를 처리할 수 있는 share magic helper 또는 미들웨어를 구축할 수 있다.
  결국, 모놀리식 아키텍처조차도 크로스커팅 이슈를 위해 외부 서비스 레이어를 통해 트래픽을 라우팅하는 경향이 있지만 단일 아키텍처를 사용하면 프로젝트가 훨씬 안정될 때까지 해당작업의 비용을 지연시킬 수 있다.
  마이크로서비스는 자체 가상 머신이나 컨테이너에 자주 배포되므로 VM 논쟁이 확산되고 있다.

알아두면 좋은 것들:

초기비용이 높은데도 불구하고 모놀리식 앱 대신 마이크로서비스에 대한 긍정적인 태도가 확산됨. 마이크로서비스는 장기적으로 성능이 향상되고 확장되는 경향이 있다.
마이크로서비스와 모놀리식 앱에 대한 경험. 코드레벨에서 서비스가 서로 독립적이 되도록 앱을 구성해야 하지만 처음에는 모놀리식 앱이 함꼐 번들링하기 쉽다. 마이크로서비스의 간접비용은 비용이 실질적으로 들 때까지 지연될 수 있다.

주의할 점:

모놀리식과 마이크로서비스 아키텍처의 차이를 모르면 안 된다.
마이크로서비스의 추가 오버헤드에 대해 비현실적이거나 비실용적으로 인식하고 있으면 안 된다.
마이크로서비스를 위한 IPC및 네트워크 통신으로 인한 추가 오버해드를 인식하지 못하면 안 된다.
독립적으로 확장 가능한 마이크로서비스의 이점을 과소평가하면 안 된다.

비동기식 프로그래밍이란 무엇이며, 자바스크립트에서 왜 중요한가?

동기식 프로그래밍이란 조건부나 함수 호출을 제외하고 코드가 위에서부터 순차적으로 실행되며 네트워크 요청이나 디스크 I/O 와 같이 장기적으로 실행되는 작업을 차단하는 것을 말한다.
비동기 프로그래밍이란 엔진이 이벤트 루프에서 실행됨을 의미한다. 차단이 필요할 때 요청이 시작되고 코드는 결과를 차단하지 않고 계속 실행된다. 응답이 준비되면 인터럽트가 발생하여 이벤트 처리기가 실행되고,
제어 플로우가 지속된다. 이런 식으로 단일 프로그램 스레드는 동시에 많은 작업을 처리할 수 있다.
사용자 인터페이스는 기본적으로 비동기식이며, 사용자 입력을 기다리는 대부분의 시간을 이벤트 루프를 중단하고 이벤트 핸들러를 트리거하는 데 소비한다.
노드는 기본적으로 비동기식이다. 즉 서버가 동일한 방식으로 작동하고, 네트워크 요청을 위한 루프에서 대기하며 첫 번째가 처리되는 동안 들어오는 요청을 더 받아들일 수 있다.
이것은 자바스크립트에서 중요하다. 비동기식 프로그래밍은 사용자 인터페이스 코드에 매우 자연스레 어울리며 서버의 성능에 매우 유용하기 때문이다.

알아두면 좋은 것들:

블락킹의 의미와 성능에 미치는 영향에 대한 이해
이벤트 처리에 대한 이해와 UI코드에 이것이 왜 중요한지에 대한 이해.

주의할 점:

비동기식 또는 동기식이라는 용어에 익숙해야 한다.
성능관련 이슈나 비동기 코드와 UI 코드간의 관계를 명확히 밝힐 수 없으면 안 된다.