프레임워크란 무엇인가?

docs.scrimba.com

작은 웹 앱을 만들고 있다고 상상해보세요: 계정, 피드, 설정 페이지. 당신의 아이디어가 화면에 나타나기 전에, URL을 페이지로 변환하는 코드, 데이터베이스와 통신하는 코드, 비밀번호를 안전하게 보관하는 코드, 뭔가 변경될 때 화면을 다시 그리는 코드가 필요합니다. 이 중 어느 것도 당신의 앱의 아이디어가 아닙니다. 모든 앱이 필요로 하며, 대부분은 프로젝트마다 동일합니다.

이 모든 배관 작업을 직접 작성할 수 있으며, 사람들은 수년 동안 그렇게 했습니다. 그것은 느리고, 미묘한 버그가 숨어있는 곳이며, 모든 팀이 동일한 메커니즘의 약간 다르고 약간 깨진 버전을 끝내게 됩니다. 프레임워크는 누적된 답변입니다: 공유되는 배관 작업이 한 번 작성되고 수천 개의 프로젝트로 강화되었으며, 당신의 코드가 어디에 가는지 알려주는 구조와 함께 패키징됩니다. 당신은 당신의 프로젝트를 당신의 것으로 만드는 부분을 만들고; 프레임워크는 모든 프로젝트가 반복하는 부분을 처리합니다.

프레임워크는 웹 전용이 아닙니다. 프로그램이 만들어지는 모든 곳에 존재하며, 이 장은 모든 언어와 모든 분야에서 아이디어 자체에 관한 것입니다.

프레임워크가 무엇인가 (그리고 라이브러리가 무엇인가)

이 단어는 느슨하게 사용되므로, 코드상에서 실제로 중요한 구분은 다음과 같습니다:

// 라이브러리: 당신의 코드가 주도적이며, 필요할 때 라이브러리를 호출합니다.
const label = dateLibrary.format(order.createdAt, "MMM D");

// 프레임워크: 프레임워크가 주도적이며, 당신이 연결한 코드를 호출합니다.
export default function OrdersPage() {
  return listOfOrders();
}

첫 번째 줄은 당신이 조종하는 것입니다: 당신의 프로그램이 실행되고, 한 가지 작업을 위해 라이브러리를 빌려옵니다. 두 번째는 본질적으로 다릅니다. 당신은 절대 OrdersPage를 직접 호출하지 않습니다. 당신은 그것을 작성하고, 프레임워크가 기대하는 장소에 놓고, 프레임워크는 올바른 순간에, 방문자가 주문 페이지를 열 때 그것을 호출합니다.

이 반전에는 이름이 있습니다: 제어의 역전. 라이브러리를 사용하면, 당신의 코드가 프로그램의 흐름을 제어하고 도우미를 빌려옵니다. 프레임워크를 사용하면, 프레임워크가 흐름을 제어하고, 당신의 코드는 그것이 당신을 위해 남겨둔 공백을 채웁니다. 유용한 속담: 당신은 라이브러리를 호출합니다; 프레임워크는 당신을 호출합니다.

동일한 형태가 프로그래밍의 모든 모서리에 나타납니다. Django는 웹 요청을 받고 당신의 뷰 함수를 호출합니다. Flutter는 앱을 실행하고 당신의 위젯에 무엇을 그릴지 묻습니다. Unity는 게임 루프를 실행하고 매 프레임마다 당신의 스크립트를 호출합니다. pytest는 당신의 테스트 함수를 찾아 당신을 위해 실행합니다. 다양한 분야, 하나의 아이디어: 프레임워크가 엔진을 소유하고, 당신이 그것이 보유하도록 만들어진 부분을 공급합니다.

그림이 도움이 된다면: 라이브러리는 당신이 만드는 동안 당신 옆에 있는 도구 상자이고, 도구가 유용할 때마다 손을 뻗습니다. 프레임워크는 당신이 도착할 때 이미 서 있는 건물의 틀에 더 가깝습니다. 벽, 배선, 배관이 자리를 잡고 있으며, 당신의 작업은 건물을 당신의 것으로 만드는 방으로 들어갑니다. 둘 다 노력을 절약합니다; 차이점은 누가 건설의 형태를 결정하는가입니다.

구조에는 기대 사항이 따르며, 그것은 기능입니다. 대부분의 프레임워크는 관례보다 구성을 선호합니다: 프레임워크가 기대하는 장소에 파일을 놓고, 프레임워크가 기대하는 방식으로 이름을 지정하면, 설정 코드 없이 모든 것이 자동으로 연결됩니다. Rails가 이 문구를 유명하게 만들었으며, 대부분의 현대 프레임워크는 이의 어떤 버전이든 따릅니다. 보상은 프레임워크를 아는 모든 개발자가 그것으로 만든 모든 프로젝트를 열 수 있고 어디를 봐야 하는지 알 수 있다는 것입니다. 대가는 관례가 무언가 작동하기 전에 배우기 위한 또 다른 것이며, 그것에 맞서는 것은 거의 항상 그것을 따르는 것보다 더 고통스럽다는 것입니다.

제어의 역전은 당신이 프로그램을 읽고 디버깅하는 방식을 변경합니다. 일반 스크립트에서, 호출 스택은 당신의 코드에서 시작하고 그것의 모든 것이 당신의 것입니다. 프레임워크 내부에서, 스택은 프레임워크 내부 깊숙이 시작하고, 당신의 함수는 프레임워크가 호출하기로 선택한 항목으로 나타납니다: 훅, 핸들러, 라이프사이클 메서드. 오래된 농담은 정확하게 설명합니다: "우리에게 전화하지 마세요, 우리가 당신에게 전화할 것입니다." 실제로, 그것은 프레임워크를 배우는 것이 API 표면보다 타이밍, 당신의 어떤 함수가 호출되는지, 언제, 그리고 그것이 무엇을 기대하는지에 관한 것임을 의미합니다. 행동이 당신을 놀라게 할 때, 답변은 보통 그 타이밍에 있고, 프레임워크의 라이프사이클 문서는 열어두고 있을 가치 있는 지도입니다.

Juno프레임워크와 라이브러리 라이브러리는 도구 상자입니다: 당신의 프로그램이 쇼를 진행하고 필요할 때 도구를 집어듭니다. 프레임워크는 건물의 틀과 더 비슷합니다: 구조는 이미 위쪽에 있고, 당신은 당신의 방을 그것에 건축합니다. 그것을 클릭시킨 속담은 당신은 라이브러리를 호출하지만, 프레임워크는 당신을 호출한다는 것입니다.

Juno프레임워크와 라이브러리 당신은 라이브러리를 호출합니다; 프레임워크는 당신을 호출하고, 그 반전은 제어의 역전이라고 불립니다. 프레임워크는 관례와 쌍을 이룹니다: 프레임워크가 기대하는 곳에 코드를 놓으면 자동으로 연결됩니다. 관례에 맞서는 것보다 따르세요, 그것이 하나를 잘 사용하는 대부분의 기술입니다.

Juno프레임워크와 라이브러리 제어의 역전은 호출 스택이 프레임워크에서 시작하고 당신의 코드가 프레임워크가 호출하는 훅으로 나타난다는 의미입니다. 그래서 배울 실제 것은 타이밍입니다: 당신의 어떤 함수가 호출되고, 언제, 그리고 프레임워크가 무엇을 기대하는지입니다. 프레임워크 앱을 디버깅하는 것은 그것의 라이프사이클을 읽는 것이며, 그것이 마술처럼 느껴지는 것을 멈출수록 더 좋습니다.

프레임워크가 당신에게 가져다주는 것과 비용이 드는 것

프레임워크의 경우는 구체적입니다. 몇 주가 걸릴 문제들이 이미 해결되어 나타나고, 어려운 모서리를 먼저 부딪힌 사람들에 의해 해결됩니다: 비밀번호 처리, 양식 유효성 검사, 라우팅, 렌더링. 당신의 프로젝트는 새 팀원이 몇 분 안에 인식할 수 있는 구조를 얻습니다, 왜냐하면 그것은 그 프레임워크의 모든 다른 프로젝트와 동일한 구조이기 때문입니다. 그리고 당신은 생태계를 상속받습니다: 플러그인, 튜토리얼, 답변된 질문, 그리고 이미 그 주변을 알고 있는 사람들의 채용 풀.

비용은 똑같이 구체적이며, 동일한 직설적인 모습을 받을 자격이 있습니다. 프레임워크는 당신이 제어하지 않는 큰 의존성이며, 그것의 자체 버그, 그것의 자체 속도, 그리고 그것의 자체 의견을 가지고 있습니다. 첫 번째 페이지가 렌더링되기 전에 배우는 곡선이 있으며, 당신이 배우는 것 중 일부는 프레임워크에 대한 지식이지 프로그래밍에 대한 지식이 아닙니다. 당신의 코드는 그것의 형태에 구부러지고, 이것은 당신이 오래 머물수록 떠나기를 더 어렵게 만듭니다. 그리고 프레임워크는 움직입니다: 주요 버전이 나타나고, 패턴이 다시 생각되고, 최신 상태를 유지하는 것은 당신이 일반 코드로 가지지 않은 진행 중인 작업입니다.

둘 다 목록이 자신을 이기지 못합니다. 균형은 완전히 프로젝트에 달려 있으므로, 모든 프레임워크에 묻는 질문은 "이것이 이 프로젝트를 더 간단하게 만드는가?"입니다. 프레임워크는 당신의 프로젝트를 더 간단하게 만들어서 그 자리를 얻습니다. 그럴 때, 기꺼이 그것을 사용하세요. 그렇지 않을 때, 다음 두 장은 이것을 초기에 인식하는 것에 관한 것입니다.

생태계 효과는 플러스 측면의 과소평가된 항목입니다. 성숙한 프레임워크에서, 당신의 문제가 새로울 가능성은 거의 0에 가깝습니다: 인증, 파일 업로드, 이메일 전송, 배포, 누군가가 각각을 패키징하거나 문서화했습니다. 그것은 건설의 많은 일을 조립의 시간으로 변환합니다. 미러된 항목은 음의 측면에서는 이 유창함이 프레임워크에 정해진다는 것입니다: 당신이 아는 것 중 일부는 "Django가 어떻게 하는지"이지 "웹 서버가 어떻게 작동하는지"가 아닙니다. 각 편의성 아래의 일반적인 아이디어에 주목을 유지하세요, 그것이 이 문서가 무엇인지입니다.

두 가지 비용은 프로덕션에서만 나타납니다. 첫째, 추상화는 새어나갑니다: 프레임워크의 편리한 표면은 실제 기계를 숨기고, 마술이 잘못 행동하는 날에, 당신은 이제 작성하지 않은 추가 계층을 통해 기계를 디버깅하게 됩니다. 당신의 프레임워크가 아래에서 무엇을 하는지 이해하기 위해 예산을 책정하세요, 왜냐하면 결국 당신이 필요할 것이기 때문입니다. 둘째, 업그레이드 러닝머신은 실제 항목입니다: 큰 코드베이스의 주요 버전 마이그레이션은 몇 주를 흡수할 수 있으며, 건너뛰면 조용히 패치되지 않은 보안 문제로 변합니다. 둘 다를 움직이는 부분이 적고 마이그레이션할 것이 없지만 모든 해결된 문제를 다시 당신의 자신의 위험으로 해결하기 위해 다시 열어서 일반 코드의 대안과 함께 무게를 재세요. 그 트레이드는 프레임워크 선택 및 학습의 주제입니다.

Juno프레임워크가 사는 것과 비용 프레임워크는 당신에게 해결된 문제, 인식 가능한 구조, 그리고 도움의 전체 생태계를 전달합니다. 교환에서 당신은 큰 의존성, 배우는 곡선, 그리고 그것의 일하는 방식을 가져갑니다. 둘 다의 측면이 실제이므로, 당신의 특정 프로젝트를 더 간단하게 만드는지에 대한 질문을 가져가세요. 때로는 답이 행복한 예이고, 때로는 일반 코드가 더 차분한 길입니다!

Juno프레임워크가 사는 것과 비용 생태계는 트레이드의 과소평가된 절반입니다: 성숙한 프레임워크에서 거의 당신이 부딪히는 문제가 새로운 것입니다. 각 편의성 아래의 일반적인 아이디어를 계속 공지하세요, 그렇지 않으면 당신의 지식이 "이 프레임워크가 어떻게 하는지" 대신 그것이 어떻게 작동하는지가 됩니다. 프레임워크는 프로젝트를 더 간단하게 만들어야 합니다; 그것이 전체 테스트입니다.

Juno프레임워크가 사는 것과 비용 두 가지 비용은 나중에 청구합니다: 추상화는 새어나가므로, 어느 날 당신은 당신이 작성하지 않은 계층을 통해 프레임워크의 기계를 디버깅하고, 주요 버전 마이그레이션은 절대 영원히 건너뛸 수 없는 실제 작업입니다. 일반 코드의 자신의 가격과 함께 둘 다 앞서 가격을 책정하세요, 그것이 해결된 문제를 다시 해결하는 것입니다. 나는 둘 다의 송장을 지불했습니다; 둘 다 재미있지 않으며, 둘 다 교의의 이유가 아닙니다.

이곳이 다음에 가는 곳

아이디어가 제 자리에 있으면, 자연스러운 다음 질문은 실제로 거기에 무엇이 있는지입니다: 프레임워크의 종류는 웹에서 게임까지 주요 가족들을 둘러보고, 각각에서 가장 인기 있는 옵션입니다. 그 후, 프레임워크 선택 및 학습은 하나를 선택하고, 하나를 배우고, 언제 하나가 전혀 필요 없는지 아는 것에 대해 실용적으로 얻습니다. 위의 JavaScript 예제가 낯설게 느껴졌다면, JavaScript 트랙은 언어 자체를 다루고, 그것이 그것 위에 구축된 모든 프레임워크 전에 올바른 첫 번째 단계입니다.