API란?

API의 정의와 인터페이스의 정의를 위키백과에서 살펴보도록 하겠습니다.

• API(Application Programming Interface)의 약자입니다.
• API는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.

Interface 란?

• 인터페이스(interface)는 컴퓨터 시스템끼리 정보를 교한하는 공유 경계를 의미한다, 터치 스크린과 같은 일부 컴퓨터 하드웨어 장치들은 인터페이스를 통해 데이터를 송수신 할 수 있으며, 마우스나 마이크론 폰가 같은 장치들은 오직 시스템에 데이터를 전송만 하는 인터페이스를 제공한다.

간단하게 이야기하자면 인터페이스는 사물과 사물 또는 사물과 사람사이에서 상호간의 소통을 위해 만들어진 매개체나 규약이라고 생각하면 됩니다.

결국 API는 어떤 프로그램에서 데이터를 주고 받기 위한 방법입니다.

예를들어 League Of Legend라는 게임의 api를 예로들어 설명하겠습니다.

(요즘 LOL.. 다들 아시죠?)

LOL은 따로 Developer 사이트가 존재합니다.

이러한 라이엇 디벨로퍼 사이트에서 어떠한 방식으로 데이터를 제공하는지, 어떻게 요청해야하는지에 대한 규격들을 

API라고 하는것입니다.

공부하는도중 갑작스레 궁금증이 생겼습니다.

css 가상요소인 after 이나 before은 :after / :before 도 적용되고

::after / ::before도 적용이 됩니다.

그러나 가상클래스인 nth-child앞에 (:)이 아닌 (::)을 작성하면 적용이 되지 않았습니다.

그러면 가상요소와 가상클래스를 어떻게 구분짓고 올바르게 사용할 수 있을까요?

일단 HTML에 존재하는 요소를 선택하면 가상 클래스,

HTML에 존재하지 않지만 가상을 요소를 생성하여 선택하는것이 가상 요소 선택자라고 보시면 될 것 같습니다.

여기

를 클릭하여 선택자들을 확인 할 수 있습니다.

위 링크안에서, 

::after / ::before / ::first-line / ::first-letter 이 가상 요소

나머지는 전부 가상 클래스 였습니다.

1. 스크립트 언어의 정의

Script 언어는 연극 용어인 Script에서 유래되었습니다.

우리는 프로그래밍에서 'script'의 역할을 생각해보면 왜 연극 용어에서 가지고 왔는지

이해할 수 있습니다.

프로그래밍에서의 스크립트 언어는 기존에 이미 존재하는 소프트웨어를 제어하기 위한

용도로 쓰이는 언어입니다.

연극에서 스크립트가 배우가 어떻게 행동할지, 어떻게 말을 할지 등을 지시해 놓은 것처럼,

스크립트 언어도 응용 소프트웨어를 제어하는 컴퓨터 프로그래밍 언어입니다.

연극의 스크립트를 보고 싶으시다면 클릭해 주세요.

2. JavaScript?

자바스크립트(JavaScript)는 객체 기반의 스크립트 언어입니다.

(※ 객체 : 메모리에 할당된 것으로 프로그램에서 사용되는 데이터 / 변수, 함수, 메서드 등이 될 수 있습니다.)

우리는 HTML로 웹의 내용을 작성하고, CSS로 작성한 웹의 내용을 꾸며주고, 그리고 JS(자바스크립트)로 

웹의 동작을 구현합니다.

3. JavaScript 특징

1. 자바스크립트는 타입을 명시할 필요가 없는 인터프리터 언어입니다.
2. 자바스크립트는 객체 지향형 프로그래밍과 함수형 프로그래밍을 모두 표현할 수 있습니다.

    3-1 인터프리터?

• 인터프리터(interpreter)는 소스코드를 바로 실행하는 컴퓨터 프로그램, 환경을 말합니다.
• 원시 코드를 기계어로 번역하는 컴파일러와 대비됩니다.

프로그램 언어를 해석하고 실행시키는 대표적인 방법으로는

컴파일(Compile)과 인터 프릿(Interpret) 방식이 있습니다.

실행 과정으로 알아보겠습니다.

1. 프레임워크

자바스크립트 프레임워크에 대해 알아보기 위해서는 일단 프레임워크가 어떤 것인지를 알아야 합니다.

프레임워크는 복잡한 코드나 내용을 간단하게 해 주며 미리 규격화, 모듈화 되어있는 도구를 말합니다.

조금 더 쉽게 설명을 드리 자면 FrameWork는 Frame + Work로 볼 수 있습니다.

Frame = 틀 , Work = 일하다.

프레임워크는 짜인 틀 안에서, 또는 틀을 가지고 일한다 라는 느낌으로 생각해보시면 될 것 같습니다.

예를 들어 설명드리겠습니다.

우리에게는 장난감 퍼즐이 있다고 가정하겠습니다.

우리는 각각의 퍼즐들을 가지고 알맞게 조립하면서 결과물을 만들어 내야 할 것입니다.

또한 이 퍼즐을 완성하기 위해서는 각각 퍼즐이 가지고 있는 모양이나 구멍에 규약을 지키면서 만들어 가야 합니다.

이러한 개념을 우리는 프로그래밍에 관련지어 생각해 보도록 하겠습니다.

프레임워크는

어떠한 프로그램을 쉽게 만들기 위한 요소와 룰을 제공하는 프로그램으로 이야기할 수 있습니다.

2. 자바스크립트 프레임워크

자바스크립트가 처음 개발돼 고난 뒤 사람들은 웹의 동작을 구현해주는 자바스크립트에 열광했습니다.

그러나 자바스크립트의 유연함 때문인지 코드가 조금씩 복잡해지기 시작했고 이는 유지보수에 악영향을 미쳤습니다.

그렇게 자바스크립트의 인기가 식어가던 도중 이 문제점을 해결해주는 프레임워크들이 하나둘씩 생기기 시작했습니다. 2019년도를 기준으로 한 Front-end Frameworks 순위입니다.

2018년도와는 다르게 Svelte가 Angular를 제치고 3위로 올랐습니다. 

2018년도까지는 JS프레임워크 3 대장이 Vue, React, Angular 였는데 이제는 4 대장이 되려는 걸까요..?

Vue.js

Vue.js는 MVVM 패턴의 뷰 모델에 해당하는 화면단 프레임워크입니다.

MVVM

MVVM패턴은 Model - View - ViewModel패턴의 약자입니다.
Model - View - ViewModel로 구조화하여 개발하는 방식으로 유지보수가 편리합니다.

View(뷰) : 사용자가 보는 UI 부분입니다.
ViewModel(뷰 모델) : View를 표현하기 위해 만든 Model입니다. 돔 리스너와 데이터 바인딩을 제공합니다.
Model(모델): 애플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분입니다.

돔 리스너 

돔이 변경되면 즉각적으로 반응하여 특정 로직을 수행합니다.

일단 DOM이 변경되면 DOM리스너가 감지한 뒤, 모델에 접근하여 데이터를 바인딩하고 그것을
뷰에 출력하게 됩니다.

데이터 바인딩과 화면 단위를 component 형태로 제공하며, 관련 API를 지원하는 데에 궁극적인 목표가 있습니다.

Angular에서 지원하는 양방향 데이터 바인딩을 동일하게 제공합니다.

컴포넌트끼리의 통신의 기본은 React의 단방향 데이터 흐름을 사용합니다.

다른 프레임워크와 비교했을 때, 가볍고 빠르며 문법이 단순하고 간결하여 누구나 쉽게 접근이 가능합니다.

Svelte

Svelte는 다른 프레임워크와는 매우 다릅니다.

Svelte는 프레임워크라기보다는 빌드 시에 모든 것을 구축하는 컴파일러와 같습니다.

React와 Vue와 마찬가지로, 데이터가 변경될 때 화면을 갱신하는 응용프로그램을 개발자가 작성할 수 있습니다. 그러나 가장 큰 차이점은 프레임워크가 브라우저에서 실행되는 것이 아닌, 컴파일 시에 실행됩니다.

컴파일러는 개발자가 만든 구성요소에서 DOM을 직접 제어하는 명령형 코드로 변환합니다.

따라서 브라우저에 전달된 코드는 적어지고 효율적으로 변화며 빠르게 실행됩니다.

Svelte가 벌써 3대 장안에 들어간다고 하기는 시기상조이지만 2020년에는 어느 정도 따라올 가치가 있습니다.

버전 관리 시스템 개요

버전 관리 시스템은 (aka VCS) 문서나 설계도, 소스 코드등의 변경점을 관리해주는 소프트웨어 입니다.

소프트웨어를 개발할 때 변경점을 관리하는것은 매우 중요한 일입니다. 우리가 예전에 겪었을만한

졸업논문 작성할때도 그랬었죠.

이렇게 버전 관리 없이 문서를 저장할 경우, 어떤 파일이 정말 마지막으로 저장되었는지도

나중에는 알기 힘들고, 사고로 내용이 날아간 경우에도 복구할 수 없습니다.

우리는 이러한 일들을 해소하고자 버전관리를 해야합니다.

정리하자면 우리가 버전관리를 함으로써 얻을 수 있는것들은

• 프로젝트를 진행 중 과거의 어떤 시점으로 돌아갈 수 있게 하기 위함입니다.
• 특정 시점에 꼬리표를 달아 버전을 표시해주고, 동시에 여러 버전을 개발할 수 있게 해줍니다.
• 여러사람이 같은 프로젝트에 참여할 경우 같이 일하는 모든 사람들에게 수정사항을 쉽게 공유할 수 있습니다.
• 무언가가 잘못 되었을때, 복구를 돕기 위해서 사용할 수 있습니다.

버전 관리 시스템 종류

로컬 VCS

• 서버 없이 로컬 컴퓨터 내에서 버전을 관리할 수 있습니다.
• 매우 간단하게 사용할 수 있다.
• 로컬 컴퓨터 내에서 관리하기 때문에 협업에서 사용하기엔 힘듭니다.
• 실수로 디렉토리를 지우거나 컴퓨터 고장시에 파일들을 복구할 수 없습니다.

중앙집중식 VCS 

• 프로젝트를 진행하다 보면 다른 개발자와 함께 작업을 해야하는 경우가 있는데 이럴때 생기는 문제를 해결하기 위하여 중앙집중식 VCS가 개발되었습니다.
• 파일을 관리하는 서버에 최종본 한 개가 있으며, 사용자가 중앙서버에서 파일을 다운받아 사용합니다.
• 사용자 중 누가 무엇을 하고 있는지 알 수 있습니다.
• 서버가 다운될 경우 그동안 아무도 다른사람과 협업할 수 없고 사람들이 하는 일도 백업할 수 없습니다.
• 중앙 데이터베이스가 있는 하드디스크에 문제가 생기면 프로젝트의 모든 히스토리를 잃을 수 있습니다.
• 대표적으로 Subversion(SVN)이 있습니다.

분산 VCS 

• 파일을 저장하는 서버가 있는것은 중앙집중식 VCS와 동일하지만 수정을 위해 프로젝트 전체를 로컬에 다운 받은뒤 수정하게 됩니다.
• 서버가 다운되더라도 사용자들은 작업을 할 수 있고 프로젝트 전체를 로컬에 다운 받은 뒤 수정하기 때문에 서버가 날아가도 복구가 가능합니다.
• 수정할 때에도 소스코드를 수정하고 있는 사람이 1사람이기 때문에 충돌을 피해 수정이 가능합니다.
• 대표적으로 GIT이 있습니다.

버전 관리 시스템이 없다면?

만약 VCS, 즉 버전관리 시스템이 없다면 우리는 협업할 인원이 5명이라고 가정한다면,

5명중 누가 언제 얼만큼동안 소스코드를 작업할지 정하고 작업을 해야할 것 입니다.

5명중 1명이 작업하는동안 남은 4명은 다른 1명을 계속 기다려야하고

어찌어찌 어느정도 완성이되고 몇가지 수정사항이 있어 수정을 했는데 시스템오류가 난다면

누구의 잘못인지 찾기도 힘들뿐더러 시스템오류전에 저장했던 파일을 또 열심히 찾고...

엄청나게 시간을 허비했을 것 입니다.