대부분의 코딩 과제는 퍼즐 해결 방법을 가르칩니다. LeetCode의 30일 JavaScript 학습 계획은 뭔가 다릅니다. 퍼즐 조각이 어떻게 벽돌로 바뀌고 실제 프로젝트를 구축할 수 있는지 보여줍니다.
이러한 구별이 중요합니다. 일반적인 알고리즘 문제를 해결할 때 추상적으로 생각하도록 마음을 훈련시키는 것입니다. 하지만 디바운싱된1 기능을 구현하거나 이벤트 이미터2를 구축하면 실제 소프트웨어가 어떻게 작동하는지 배우게 됩니다.
직접 도전을 하면서 이것을 발견했습니다. 이 경험은 난해한 문제를 해결하는 것보다는 고고학에 더 가깝습니다. 구체적이고 현대적인 JavaScript 개념을 밝혀내는 것입니다. 각 섹션에서는 JS의 최신 기능 중 또 다른 부분에 중점을 두었습니다.
이 학습 계획의 특이한 점은 JavaScript를 가르치지 않는다는 것입니다. 사실, JavaScript의 혜택을 받으려면 이미 JavaScript를 합리적으로 잘 알고 있어야 한다고 생각합니다. 대신에 가르치는 것은 실제 엔지니어링 문제를 해결하기 위해 JavaScript가 실제로 어떻게 사용되는지입니다.
메모라이즈3 챌린지를 고려해 보세요. 표면적으로는 함수 결과를 캐싱하는 것에 관한 것입니다. 하지만 실제로 배우고 있는 것은 React와 같은 라이브러리가 구성 요소 렌더링을 효율적으로 처리하기 위해 메모가 필요한 이유입니다. 아니면 Debounce1 문제를 생각해 보세요. 이는 단지 지연 구현에 관한 것이 아닙니다. 모든 최신 프런트엔드 프레임워크, 엘리베이터 및 기본적으로 대화형 UI가 있는 모든 시스템에 이 패턴이 필요한 이유를 직접 이해하는 데 도움이 됩니다.
언어 기본보다는 실용적인 패턴에 중점을 두는 것은 흥미로운 제약을 만들어냅니다. 혜택을 받으려면 두 가지 위치 중 하나에 있어야 합니다.
컴퓨터 공학을 배우는 것과 소프트웨어 공학을 실천하는 것 사이에는 이상한 일이 일어납니다. 이러한 전환은 수년 동안 체스 이론을 배우다가 완전히 다른 게임을 플레이하는 것과 같은 느낌입니다. 규칙은 계속 바뀌고 대부분의 동작은 어떤 책에도 나와 있지 않습니다.
CS에서는 이진 트리의 작동 방식을 배웁니다. 소프트웨어 엔지니어링에서는 응답 캐싱이 작동하지 않는 이유를 이해하기 위해 API를 디버깅하는 데 몇 시간을 소비합니다. 멀리서 보면 이 세계들 사이의 중첩이 실제보다 훨씬 더 크게 보일 수 있습니다. 거기에는 격차가 있으며, CS 졸업생이 경력을 시작할 때 종종 충격을 받을 수 있습니다. 불행하게도 대부분의 교육 자원은 이를 연결하는 데 실패했습니다. 순전히 이론적("퀵 정렬 작동 방식은 다음과 같습니다")이거나 순전히 실용적입니다("React 앱을 배포하는 방법은 다음과 같습니다").
이 JavaScript 학습 계획을 흥미롭게 만드는 것은 특별히 잘 설계되었다는 것이 아니라 이러한 세계를 연결한다는 것입니다. 메모 문제를 생각해 보세요: 2623. 메모3. CS 용어로 말하면 계산된 값을 캐싱하는 것입니다. 그러나 이를 구현하면 객체 참조, 함수 컨텍스트 및 메모리 관리와 관련된 JavaScript의 특성을 다루어야 합니다. 갑자기
단순히 알고리즘을 배우는 것이 아니라 Redis와 같은 것이 존재하는 이유를 이해하기 시작하는 것입니다.
이 스타일은 챌린지 내내 반복됩니다. Event Emitter2 구현은 단지 교과서적인 관찰자 패턴에 관한 것이 아닙니다. V8 엔진을 브라우저에서 꺼내어 그 주위에 Node.js를 구축하는 것이 실제로 의미가 있는 이유라고 볼 수 있습니다. . Promise Pool4은 데이터베이스에 연결 제한이 필요한 이유인 병렬 실행을 처리합니다.
이 학습 계획의 문제 순서는 무작위가 아닙니다. 현대 JavaScript의 정신적 모델을 계층별로 구축하고 있습니다.
폐쇄로 시작됩니다. 클로저가 가장 단순한 개념이기 때문이 아니라(악명 높을 정도로 혼란스럽기 때문) JavaScript가 상태를 관리하는 방법의 기초이기 때문입니다.
function createCounter(init) {
let count = init;
return function() {
return count++;
}
}
const counter1 = createCounter(10);
console.log(counter1()); // 10
console.log(counter1()); // 11
console.log(counter1()); // 12
// const counter1 = createCounter(10);
// when this^ line executes:
// - createCounter(10) creates a new execution context
// - local variable count is initialized to 10
// - a new function is created and returned
// - this returned function maintains access
// to the count variable in its outer scope
// - this entire bundle
// (function (the inner one) + its access to count)
// is what we call a closure
이 패턴은 JavaScript의 모든 상태 관리의 씨앗입니다. 이 카운터가 어떻게 작동하는지 이해하고 나면 React의 useState가 내부적으로 어떻게 작동하는지 이해하게 됩니다. ES6 이전 JavaScript에서 모듈 패턴이 등장한 이유를 파악했습니다.
그런 다음 계획은 기능 변환으로 이동합니다. 이는 함수 장식, 즉 함수가 다른 함수를 래핑하여 동작을 수정하는 방법을 가르칩니다. 이것은 단순한 기술적인 트릭이 아닙니다. Express 미들웨어가 작동하는 방식, React의 상위 구성요소가 작동하는 방식입니다.
TypeScript 데코레이터의 작동 방식도 알아보세요.
비동기 문제에 도달할 때쯤이면 Promise에 대해 배울 뿐만 아니라 JavaScript에 Promise가 왜 필요한지 알게 됩니다. Promise Pool4 문제는 혁신적이고 기발한 JS 개념을 가르치는 것이 아닙니다. 모든 데이터베이스 엔진에 연결 풀링이 존재하는 이유를 보여줍니다.
다음은 학습 계획 섹션을 실제 소프트웨어 엔지니어링 개념에 대략적으로 매핑한 것입니다.
이 학습 계획의 실제 가치를 보여주는 몇 가지 문제를 분석해 보겠습니다.
메모라이즈 챌린지를 고려해 보세요. 제가 좋아하는 점은 (제가 생각해낸) 최고의 솔루션이 있다는 사실입니다
매우 간단하여 마치 코드 자체가 자신이 수행하는 작업을 부드럽게 알려주는 것 같습니다(그래도 몇 가지 설명을 포함했습니다).
어쨌든 #2623이 쉬운 문제는 아닙니다. 이렇게 깔끔하게 만들려면 이전에 2번의 반복이 필요했습니다.
function createCounter(init) {
let count = init;
return function() {
return count++;
}
}
const counter1 = createCounter(10);
console.log(counter1()); // 10
console.log(counter1()); // 11
console.log(counter1()); // 12
// const counter1 = createCounter(10);
// when this^ line executes:
// - createCounter(10) creates a new execution context
// - local variable count is initialized to 10
// - a new function is created and returned
// - this returned function maintains access
// to the count variable in its outer scope
// - this entire bundle
// (function (the inner one) + its access to count)
// is what we call a closure
엘리베이터 안에 있는데 한 사람이 미친 듯이 '문 닫기' 버튼을 반복해서 누르고 있다고 상상해 보세요.
누르기 누르기 누르기 누르기 누르기
디바운싱 없음: 엘리베이터가 누를 때마다 문을 닫으려고 시도하므로 문 메커니즘이 비효율적으로 작동하고 파손될 가능성이 있습니다.
디바운싱 사용: 엘리베이터는 실제로 문을 닫으려고 하기 전에 사람이 특정 시간(0.5초라고 가정) 동안 누르기를 멈출 때까지 기다립니다. 이것이 훨씬 더 효율적입니다.
또 다른 시나리오는 다음과 같습니다.
사용자가 입력하면 결과를 가져오는 검색 기능을 구현한다고 상상해 보세요.
디바운싱 없음:
/**
* @param {Function} fn
* @return {Function}
*/
function memoize(fn) {
// Create a Map to store our results
const cache = new Map();
return function(...args) {
// Create a key from the arguments
const key = JSON.stringify(args);
// If we've seen these arguments before, return cached result
if (cache.has(key)) {
return cache.get(key);
}
// Otherwise, calculate result and store it
const result = fn.apply(this, args);
cache.set(key, result);
return result;
}
}
const memoizedFn = memoize((a, b) => {
console.log("computing...");
return a + b;
});
console.log(memoizedFn(2, 3)); // logs "computing..." and returns 5
console.log(memoizedFn(2, 3)); // just returns 5, no calculation
console.log(memoizedFn(3, 4)); // logs "computing..." and returns 7
// Explanantion:
// It's as if our code had access to an external database
// Cache creation
// const cache = new Map();
// - this^ uses a closure to maintain the cache between function calls
// - Map is perfect for key-value storage
// Key creation
// const key = JSON.stringify(args);
// - this^ converts arguments array into a string
// - [1,2] becomes "[1,2]"
// - we are now able to use the arguments as a Map key
// Cache check
// if (cache.has(key)) {
// return cache.get(key);
// }
// - if we've seen these arguments before, return cached result;
// no need to recalculate
이렇게 하면 10개의 API 호출이 발생합니다. 사용자가 여전히 입력 중이기 때문에 대부분은 쓸모가 없습니다.
디바운싱 포함(300ms 지연):
// typing "javascript" 'j' -> API call 'ja' -> API call 'jav' -> API call 'java' -> API call 'javas' -> API call 'javasc' -> API call 'javascr' -> API call 'javascri' -> API call 'javascrip' -> API call 'javascript' -> API call
디바운싱은 코드에 "이 기능을 실제로 실행하기 전에 사용자가 X 밀리초 동안 작업을 중지할 때까지 기다리세요."라고 말하는 것과 같습니다.
LeetCode #2627에 대한 솔루션은 다음과 같습니다.
// typing "javascript" 'j' 'ja' 'jav' 'java' 'javas' 'javasc' 'javascr' 'javascri' 'javascrip' 'javascript' -> API call (only one call, 300ms after user stops typing)
디바운싱에 대한 기타 일반적인 실제 사용 사례(검색창 제외):
이 기사의 전반적인 긍정적인 분위기로 볼 때 JS의 30일에 대한 나의 의견이 이제 명확해졌기를 바랍니다.
그러나 완벽한 교육 자료는 없으며 한계가 있는 경우 정직함이 중요합니다. 이 학습 계획에는 검토해 볼 만한 몇 가지 사각지대가 있습니다.
첫째, 학습 계획은 일정 수준의 사전 지식을 전제로 합니다.
아직 JavaScript에 익숙하지 않다면 일부 어려움이 너무 클 수 있습니다. 학습 계획에서 다른 기대를 했을 수도 있는 초보자에게는 실망스러울 수 있습니다.
둘째, 과제는 고립된 방식으로 제시됩니다.
이는 처음에는 이해가 되지만 계획을 진행하면서 깨닫게 되면 실망스러운 일이 될 수 있습니다. 실제 문제에서는 여러 패턴과 기술을 결합해야 하는 경우가 많습니다. 연구 계획은 여러 개념을 함께 사용해야 하는 보다 통합된 과제로부터 이점을 얻을 수 있습니다(예외: 계획 전체에서 클로저를 사용합니다). 이는 보너스 섹션(이미 프리미엄 사용자에게 예약되어 있음)에 잘 들어맞을 수 있습니다.
결국 이 챌린지 세트의 가장 큰 약점은 개념 설명에 있습니다. 경쟁 프로그래밍 출신,
나는 문제 설명에서 새로운 용어와 개념의 정의를 명확하게 하는 데 익숙합니다. 그러나 LeetCode의 설명은 불필요하게 복잡한 경우가 많습니다. 디바운싱된 기능에 대한 설명을 이해하는 것은 실제 솔루션을 구현하는 것보다 어렵습니다.
단점에도 불구하고 학습 계획은 현대 JavaScript를 이해하는 데 귀중한 리소스입니다.
이러한 패턴을 이해하는 것은 시작에 불과합니다.
실제 과제는 이를 프로덕션 코드에 적용할 시기와 방법을 인식하는 것입니다. 제가 야생에서 이러한 패턴을 접한 후 발견한 내용은 다음과 같습니다.
첫째, 이러한 패턴은 단독으로 나타나는 경우가 거의 없습니다. 실제 코드베이스는 과제를 탐색할 수 없는 방식으로 이를 결합합니다. 처음부터 구현된 검색 기능을 고려해보세요. 다음을 사용하여 자신을 발견할 수 있습니다.
이러한 모든 패턴은 상호 작용하여 단일 과제로는 준비할 수 없는 복잡성을 생성합니다. 그러나 각 부분을 직접 구현하면 전체 구현이 어떻게 작동해야 하는지에 대한 일반적인 아이디어를 얻을 수 있습니다.
직관적으로 얻을 수 있는 가장 귀중한 기술은 이러한 패턴을 구현하는 것이 아니라 다른 사람의 코드에서 패턴을 인식하는 것입니다.
이 학습 계획을 마친 후에 이러한 패턴을 인식할 수 있는 곳은 코딩 인터뷰뿐만이 아닙니다.
오픈 소스 코드, 동료의 끌어오기 요청에서 발견할 수 있으며 과거 프로젝트에서도 발견할 수 있습니다. 당신은 그것을 깨닫지도 못한 채 이전에 구현했을 수도 있습니다. 가장 중요한 것은 그들이 왜 그곳에 있는지 이해하게 될 것이라는 점입니다.
퍼즐 풀기에서 시작된 것이 현대 JavaScript 생태계에 대한 더 깊은 이해로 바뀌었습니다.
이 학습 계획이 부족한 부분을 채워줍니다. 이론적 지식과 실용적인 공학적 지혜를 연결하는 것입니다.
2627. 디바운스(약속 및 시간) ↩
2694. 이벤트 이미터(클래스) ↩
2623. 메모하기(함수 변환) ↩
2636. 약속 풀(보너스) ↩
위 내용은 LeetCode&#s Days of JavaScript가 실제로 채우는 격차의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
