프레임워크 선택 및 학습

docs.scrimba.com

지난 두 장에서는 프레임워크가 무엇인지와 어떤 것들이 있는지를 다루었습니다. 이번 장은 실무적인 부분입니다: 프레임워크를 사용할지, 어떤 것을 선택할지, 그리고 어떻게 학습할 것인지입니다. 순서가 중요합니다. 왜냐하면 첫 번째 질문이 가장 자주 건너뛰어지기 때문입니다.

정말로 프레임워크가 필요한가?

두 개의 프로젝트를 생각해봅시다. 첫 번째는 계정, 폼, 그리고 공유된 데이터에 반응하는 화면들이 있는 앱입니다. 직접 만드는 것은 프레임워크가 이미 완성한 정확한 기반을 다시 만드는 것을 의미하며, 순수 HTML/JavaScript 버전은 흩어진 형태의 반은 테스트된 자체 제작 프레임워크가 되어 아무도 유지하고 싶지 않을 것입니다. 이 경우 Django나 React를 사용하는 것이 다른 방법보다 옮겨야 할 부분을 줄이는 선택입니다.

두 번째는 랜딩 페이지, 콘텐츠 사이트, 작은 스크립트, 어딘가로 제출되는 폼입니다. 순수 HTML, CSS, 그리고 조금의 JavaScript가 이런 것들을 빌드 단계 없이, 의존성 업데이트 없이, 내년에 마이그레이션할 것 없이 커버합니다. 이런 페이지를 완전한 프레임워크로 감싸는 것은 도구만 이득을 보는 기계 장치를 추가합니다. 많은 숙련된 개발자는 순수 코드를 의도적으로 배포하며, 이는 초보자의 타협이 아니라 전문적인 답입니다.

엔지니어링에는 두 경우를 모두 다루는 오래되고 무딘 규칙이 있습니다: KISS, "Keep It Simple, Stupid". 그 비난은 디자이너가 아니라 디자인을 향합니다. 아이디어는 최고의 해결책이 일을 여전히 해내면서 가장 적은 기계 장치를 가진 것이라는 뜻입니다. 위의 두 프로젝트 모두 이를 따르고, 반대의 답에 도달합니다.

그래서 테스트는 각 프로젝트마다 새로 물어지는 한 가지 질문입니다: 유지해야 할 기계 장치가 가장 적은 옵션을 선택하세요. 기반이 제품을 압도할 때, 그것이 프레임워크입니다. 제품이 거의 전부일 때, 그것이 순수 코드입니다.

몇 가지 신호가 판단을 구체적으로 만듭니다. 프레임워크로 기울어지는 신호: 많은 화면이 실시간 데이터를 공유, 사용자 계정과 권한, 유효성 검증 및 저장되는 폼, 여러 사람이 같은 코드베이스에서 몇 년간 작업. 순수 코드로 기울어지는 신호: 대부분 콘텐츠, 적은 상호작용, 개월 단위로 측정되는 수명, 한두 명의 유지자, 또는 로드 속도가 전체 기능인 페이지. 그리고 프로젝트 규모는 시간이 지남에 따라 양쪽 방향으로 답을 바꿀 수 있으므로, 유용한 습관은 프로젝트가 모양을 바꿀 때마다 질문을 다시 묻는 것입니다.

이 결정은 두 가지 인식할 수 있는 방식으로 실패하며, 둘 다 질문을 건너뛰는 것에서 비롯됩니다. 첫 번째 실패는 프레임워크 모양의 랜딩 페이지입니다: 빌드 파이프라인, 의존성 트리, 그리고 네 개 화면의 콘텐츠에 붙은 결국의 마이그레이션. 여기서 도구에 쓴 모든 시간은 제품이 필요하지 않은 시간입니다. 두 번째는 우발적 프레임워크입니다: 자신의 라우터, 자신의 상태 저장소, 자신의 컴포넌트 시스템을 성장시킨 순수 코드베이스. 각각 한 번 작성되고, 절대 테스트되지 않으며, 한 사람이 이해합니다. 그 두 번째 프로젝트는 프레임워크 이점 없이 프레임워크 비용을 지불합니다. 둘 다 내부에서는 확신처럼 보입니다; 두 경우 모두의 고침은 프로젝트가 무엇이 되었는지를 바탕으로 재결정하는 같은 우아하지 않은 움직임입니다.

Juno프레임워크가 필요한가? 프로젝트당 한 가지 질문을 하세요: 어느 옵션이 만들고 유지할 것이 가장 적은가? 계정과 공유된 데이터가 있는 상호작용 앱의 경우 프레임워크가 보통 이깁니다. 콘텐츠 페이지나 작은 스크립트의 경우 순수 코드가 보통 이깁니다. 두 답변 모두 존경할 만하며, 순수 코드를 선택하는 것은 절대 다운그레이드가 아닙니다!

Juno프레임워크가 필요한가? 공유된 실시간 상태, 계정, 폼, 그리고 오래된 다중 사용자 수명은 프레임워크를 나타냅니다; 콘텐츠 중심, 수명이 짧거나, 속도가 중요한 페이지는 순수 코드를 나타냅니다. 원래 판단을 방어하는 대신 프로젝트가 모양을 바꿀 때마다 다시 물으십시오. 그리고 매번 프로젝트별로 하십시오.

Juno프레임워크가 필요한가? 두 가지 고전적인 실패를 주시하세요: 아무것도 위해 도구 비용을 지불하는 프레임워크 모양의 랜딩 페이지, 그리고 조용히 자신의 유지되지 않는 프레임워크를 성장시킨 순수 앱. 둘 다 그 선택이 결정되었다고 취급하는 것에서 옵니다. 나는 모든 프로젝트 변곡점에서 재결정하며, 그것이 나를 두 도랑 모두에서 한 번 이상 구했습니다.

어떤 것을 선택하는가

답이 그렇다면, 우아하지 않은 기준으로 선택하세요. 벤치마크와 기능 비교는 가장 유용하지 않은 입력입니다. 왜냐하면 같은 계열 내에서 유명한 옵션들은 모두 충분히 빠르고 모두 기능이 충분하기 때문입니다. 실제로 당신의 일상을 형성하는 것:

에코시스템과 커뮤니티: 성숙한 문서, 답해진 질문, 그리고 마주칠 문제들을 위한 패키지. 당신이 참여하는 팀과 코드베이스: 최고의 프레임워크는 보통 당신의 프로젝트가 이미 사용하는 것이며, 일관성이 팀 내에서 새로움을 이깁니다. 일자리 시장 (일을 위해 배우는 경우): 순전한 사용량 수치가 중요하며, 이는 많은 사람들이 React를 합리적인 첫 선택으로 만드는 큰 부분입니다. 그리고 당신이 알고 있는 언어: Python 개발자는 품질과 무관한 이유로 Rails보다 Django에 더 빨리 도달합니다.

마지막까지 순수 코드 옵션을 목록에 유지하세요. 비교 표가 채워지고 어느 후보도 단순성 테스트에서 "아무것도 아님"을 이기지 못하면, 그것이 당신에게 무언가를 말하는 답입니다.

후보를 더 자세히 살펴보기 위해, 한 시간의 직접 평가는 한 주일의 의견 읽기를 이깁니다: 공식 튜토리얼을 훑어보고 문서가 설명하는지 혹은 손짓하는지 판단하세요; 릴리스 이력을 확인하여 꾸준하고 조급하지 않은 속도가 있는지 보세요; "X 버전에서 Y로 마이그레이션"을 검색하고 그 가이드들이 오후처럼 읽히는지 아니면 한 시즌처럼 읽히는지 보세요; 그리고 당신이 물어볼 질문들이 이미 좋은 답을 가지고 있는지 살펴보세요. 프레임워크는 오래 지속되는 관계이며, 이것들이 양립성 확인입니다.

두 가지 시니어 습관이 이를 완성합니다. 첫째, 잘 확립된 것에 베팅하세요: 수년간 널리 사용되어온 기술은 알려진 실패 방식, 채용 풀, 그리고 답을 가지고 있으며, "증명되고 약간 구식"이 "새롭고 흥미로운" 것보다 훨씬 더 오래 지속됩니다. 변동은 복합적 비용이고, 10년을 버틴 프레임워크는 이미 그것을 지불했습니다. 둘째, 빌드-대-채택을 컴포넌트 수준에서 실제 옵션으로 유지하세요: 때로는 프레임워크의 올바른 양은 라우팅 라이브러리 하나일 뿐이며, 한 가지 어려운 문제를 위해 채택되고 나머지는 순수로 유지됩니다. 프레임워크를 채택하는 것은 전부 아니면 무 또는이 아니며, 실제 어려운 부분을 푸는 가장 작은 의존성은 존경할 만한 아키텍처입니다.

Juno어떤 것을 선택하는가 실무적 기준으로 선택하세요: 당신의 팀이 이미 사용하는 것, 문서와 커뮤니티가 얼마나 좋은지, 일자리 시장이 원하는 것, 그리고 당신이 이미 알고 있는 언어. 같은 계열 내에서, 모든 유명한 옵션은 좋으므로 지분이 느껴지는 것보다 낮습니다. 당신의 기술은 어느 방향이든 이전될 것입니다.

Juno어떤 것을 선택하는가 후보에 한 시간의 집중한 시간을 주세요: 튜토리얼을 읽고, 릴리스 주기를 확인하고, 버전-마이그레이션 가이드를 읽으세요. 왜냐하면 그것이 당신이 등록하는 미래이기 때문입니다. 커뮤니티, 팀 적합성, 그리고 채용이 벤치마크를 매번 이깁니다. 그리고 목적적으로 "프레임워크 없음"을 단기 목록에 유지하세요.

Juno어떤 것을 선택하는가 잘 확립된 것에 베팅하세요: 10년을 버티는 것이 프레임워크가 게시할 수 있는 가장 많은 정보를 제공하는 벤치마크입니다. 그리고 채택이 이항 관계가 아니라는 것을 기억하세요; 때로는 한 가지 어려운 문제를 위한 작은 라이브러리 하나가 프레임워크의 올바른 양입니다. 목표는 배포되고 배포 가능한 상태를 유지하는 제품입니다.

어떤 프레임워크든 학습하는 방법

언어를 먼저 배우세요. 프레임워크는 어디서나 그 언어를 가정합니다: React 코드는 처음부터 끝까지 JavaScript이고, Django 앱의 모든 혼란스러운 줄은 아래에 Python입니다. 프레임워크로 건너뛴 학습자는 두 가지 수수께끼를 한 번에 디버깅하게 되며, 프레임워크의 동작과 언어의 구문, 어느 것이 어느 것인지 알 방법이 없습니다. React가 당신의 목표라면, JavaScript 트랙이 실제 첫 단계입니다; Django나 pytest의 경우, Python 트랙이 같은 역할을 합니다. 언어 먼저는 거기서 전부 이전되기 때문에 존재하는 가장 큰 지름길입니다.

그런 다음 작고 실제적인 것을 만드세요. 공식 튜토리얼에 기대면서 만드는 당신이 실제로 원하는 작은 프로젝트 하나는 보기와 읽기의 어떤 양보다 더 많이 가르칩니다. 왜냐하면 프레임워크의 모양은 당신의 손 아래에서만 의미가 되기 때문입니다. 첫 프로젝트를 의도적으로 적당하게 유지하세요: 그것의 전체 일은 당신을 프레임워크의 아이디어에 소개하는 것이고, 걸작은 나중에 올 수 있습니다.

그리고 진행하면서, 계속 프레임워크가 당신을 위해 무엇을 하는지 물으세요. 모든 편리한 기능은 뭔가 실제적인 것을 대신 서 있습니다: 라우트는 URL 파싱을 대신, 컴포넌트는 DOM 업데이트를, 모델은 SQL을. 당신은 처음부터 이 레이어들을 마스터할 필요는 없지만, 그것들이 존재한다는 것과 대략 프레임워크가 그것들을 무엇을 하는지를 아는 것이 프레임워크를 사용하는 것과 맹목적으로 의존하는 것을 분리합니다.

이 단계에서 흔한 함정은 튜토리얼 루프입니다: 맹목적인 프로젝트를 절대 시작하지 않으면서 과정 다음 과정을 완료하는 것. 튜토리얼은 생산적이고 빈 파일은 위험하게 느끼기 때문입니다. 의도적으로 그것을 깨세요. 한 공식 튜토리얼 후, 작은 실제 프로젝트를 시작하고 그것의 문제들이 당신이 찾는 것을 행하게 하세요; 실시간 문제를 손에 든 문서는 숙제로서 읽은 문서가 절대 그렇지 않은 방식으로 자리 잡습니다. 당신의 자신의 프로젝트에서 막히고 빠져나가는 것이 실제로 훈련되는 기술입니다.

두 가지 습관이 프레임워크 지식을 지속하게 만듭니다. 탈출 해치를 일찍 배우세요: 모든 프레임워크는 그것의 추상화 아래로 떨어지는 정식 방법을 가집니다 (ORM을 지나는 원본 SQL, 렌더러를 지나는 직접 DOM 접근), 그리고 그것들이 어디 있는지 알기는 그것들을 거의 사용하지 않더라도 기계의 경계를 말합니다. 그리고 HTTP, DOM, SQL, 언어 런타임인 프레임워크 아래의 플랫폼에 꾸준한 물의 흐름으로 투자하세요. 프레임워크는 현재 플랫폼이 어떻게 유지되는지이고; 플랫폼은 지속되는 것입니다. 플랫폼을 알았던 개발자들은 지난 20년의 모든 프레임워크 전환에 온전하게 건넜으며, 그것은 복사할 가치가 있는 추적 기록입니다.

Juno어떤 것을 학습하는가 항상 프레임워크 전에 언어를 배우세요: React 전에 JavaScript, Django 전에 Python. 그런 다음 공식 튜토리얼을 옆에 열어두고 한 개의 작은 실제 프로젝트를 만드세요. 작고 완료된 것이 크고 버려진 것을 이깁니다. 당신이 언어에 대해 배운 모든 것은 영원히 그것의 가치를 유지합니다!

Juno어떤 것을 학습하는가 의도적으로 튜토리얼 루프에서 탈출하세요: 한 공식 튜토리얼, 그런 다음 작은 맹목적 프로젝트는 그것의 문제들이 당신이 다음에 읽는 것을 결정하게 합니다. 실시간 문제와 함께 공부한 문서가 실제로 자리 잡습니다. 당신의 자신의 일에서 막히고 빠져나가는 것이 당신이 실제로 훈련하는 기술입니다.

Juno어떤 것을 학습하는가 탈출 해치를 일찍 찾으세요; 그것들이 기계의 참된 모서리를 표시합니다. 그리고 HTTP, DOM, SQL인 아래의 플랫폼에 대한 당신의 지식을 계속 공급하세요. 프레임워크는 회전하고 플랫폼은 머뭅니다. 플랫폼 사람들은 모든 프레임워크 전환을 살아남습니다; 나는 몇 개를 보았고 패턴은 아직 놓치지 않았습니다.

이것이 당신을 어디에 남기는가

그것이 모두입니다: 테스트로서의 단순성, 선택을 위한 우아하지 않은 기준, 학습을 위한 프레임워크 전에 언어. 특정 프레임워크가 다음에 나타날 때, 이 문서 또는 실제로 프레임워크의 종류는 그것을 배치할 지도이고, 프레임워크가 무엇인가는 아래의 정의입니다.