11 도구를 알아 두십시오
여러분은 배우는 과정에서 많은 것을 대충 훑고 넘어갑니다. 개발자 대상 마케팅에는 모든 것을 쉬워 보이게 만들려는 유인이 강하게 작용하기 때문입니다. X를 얼마나 빨리 할 수 있는지 보십시오! Y를 하는 데 코드가 얼마나 적게 드는지 보십시오! 실제로 효과가 있고, 여러분은 빠르게 생산성을 갖추는 이득을 얻었습니다.
하지만 머지않아 문제에 부딪힙니다. 배포하는 순간 여러분의 “Hello World”가 작동하지 않습니다(대부분의 튜토리얼은 배포 방법을 소홀히 다룹니다). 여러분의 코드는 보안에 취약합니다(보안을 챙기면 데모가 느려지기 때문입니다). 설정을 쳐다보기만 해도 망가져 버리니, 설정을 바꾸는 것이 두렵습니다.
여러분의 잘못은 아니지만, 부족한 부분을 메우는 것은 여러분의 손에 달려 있습니다. 튜토리얼/부트캠프는 여러분에게 유리한 출발점을 마련해 주었을 뿐이며, 이제 끝까지 완주하는 것은 여러분의 몫입니다.
서툰 장인은 연장을 탓합니다. 훌륭한 장인은 자신의 연장을 속속들이 압니다.
프런트엔드 개발자라면 Webpack을 배우십시오. Babel을 배우십시오. CSSWG와 TC39가 무슨 일을 하는지 알아 두십시오. 아예 JavaScript와 CSS를 처음부터 다시 배우십시오. Chrome DevTools를 프로파일러와 IDE로 쓸 수 있다는 사실을 알고 계셨습니까? bash를 배우십시오. git을 배우십시오. CI/CD를 배우십시오. node_modules를 열어 보십시오. 네, 양이 많습니다. 그리고 모든 것을 아는 사람은 없습니다. 그래도 시간을 들여 도구의 요령과 기법, 그리고 도구가 실패하는 방식을 익히십시오.
그만큼 중요한 것은 무엇을 놓쳐도 괜찮은지 알아내는 일입니다. 저에게도 제 목록이 있지만, 그것을 공유했다가는 많은 사람을 화나게 할 것입니다. 하지만 어떤 진로를 택하게 되든 매일 쓰게 될 것들이 있고, 중요해 보이지만 실제로는 있으면 좋은 정도에 불과한 것들도 있습니다. 그 차이를 알아내십시오. 기술은 1마일 높이로 쌓아 올린 카드로 만든 집이며, 추상화 위에 추상화가 얹혀 있습니다. 낮은 수준의 추상화는 높은 수준의 추상화보다 반감기가 깁니다. Kyle Simpson은 여러분이 일하는 곳보다 한 단계 아래의 추상화 수준을 배워야 한다고 말합니다.
11.1 FOMO를 피하십시오
가장 좋아하는 사상가가 ReasonML을 꼭 살펴보라고 합니다. JavaScript는 이제 끝난 것입니까? 도대체 사람들은 왜 그렇게까지 Redux를 없애고 싶어 합니까? CSS-in-JS는 정말 악마입니까? Vue가 GitHub 스타 수에서 React를 앞질렀습니다. Vue로 갈아타야 합니까? 글쎄요, GitHub 스타로 월급을 받습니까?
-여러분의- 빈틈을 채우십시오. 기술 서적을 처음부터 끝까지 읽으십시오. 100달러 미만의 비용과 며칠간의 집중만으로 어떤 분야든 세계 최고 수준의 전문 지식을 내려받을 수 있습니다.
여러분 자신과 여러분 고용주의 필요에 집중하십시오. 기술 분야에는 기회가 정말 많아서, 사실상 자신의 영역을 골라 그 안에서만 활동할 수 있고, 다른 모든 것에 대해서는 전혀 몰라도 되며, 그러면서도 여전히 훌륭하게 해낼 수 있습니다!
오해하지 마십시오. 저는 메타 게임을 즐기는 것을 매우 좋아합니다. 전략적인 실수를 저지를 수도 있지만, 그런 실수를 완전히 피하는 것 또한 불가능합니다. 그러니 애쓰지 마십시오. “충분히 좋은” 것에 집중하고, 문자 그대로 정확하기보다는 방향성 면에서 옳은 편이 훨씬 낫습니다(장 16). 목표는 정밀함이 아니라 정확함입니다. 옳으려고 최선을 다하되, 틀렸을 때는 걱정하지 마십시오.
11.2 도구 너머
도구를 안다는 것은 그 도구가 무엇인지 아는 것에 그치지 않습니다. 여러분의 요구가 도구가 설계될 때 전제한 규모와 속도를 넘어서면, 그 도구는 더 이상 여러분에게 제대로 도움이 되지 않을 것입니다. 그럴 때는 그 도구들의 바탕에 깔린 디자인 패턴을 알고, 새로운 도구를 찾아보거나 직접 만들 수 있는 능력이 매우 큰 도움이 될 것입니다.
왜와 누가라는 질문도 있습니다. 지금 우리가 따르는 패러다임은 누가 만들었습니까? 오늘날 그것은 누가 관리하고 있습니까? API는 왜 지금과 같은 모습입니까? 이전 버전에서 왜 바뀌었습니까? (모험심이 생긴다면: 그 도구는 내부적으로 어떻게 동작합니까?) 지적 호기심이 이끄는 대로 따라가고, 다른 누구도 굳이 하지 않는 조사로 부족한 경험을 채우십시오.
React를 예로 들어 지식 그래프를 탐색하는 방법을 보여 드리겠습니다. 많은 워크숍에서는 “고급 React”를 잘 알려지지 않은 훅 몇 가지를 사용하거나 Next.js 같은 프로덕션 메타프레임워크로 배포하는 것으로 묘사합니다. 하지만 이는 너무 많은 것을 빠뜨립니다.
- React의 초기 프로토타입은 어떤 모습이었습니까?
- React는 어떻게 Clojurescript 커뮤니티에서 처음으로 외부의 큰 호응을 얻게 되었습니까?
- React의 초기 설계와 지속적인 설계의 바탕이 되는 기본 원칙은 무엇입니까?
- React에 관한 통념 중 후회하는 것이나 흔히 오해받는 것은 무엇입니까?
- 어떤 API가 시도되었다가 실패했으며, 왜 성공하지 못했습니까?
- React에 기여하는 방법은 무엇이며, 새 기능은 어떻게 추가합니까?
- React의 주요 대안을 사용하는 사람들은 React의 트레이드오프와 단점에 대해 무엇이라고 말합니까?
- 평소 React로 하는 모든 일을 해내는 작은 React 클론을 만들 수 있다면, 여러분이 모르는 React가 하는 또 다른 일은 무엇입니까?
React 대신 여러분이 배우려는 어떤 기술이든 넣어 보십시오. 도구를 알기 위한 방법을 아는 것은 시대를 초월합니다. 도구를 제1원리부터 설명할 수 있어야 합니다(장 17)!
다른 학문 분야와 비교하면 이보다 연구하기 쉬운 주제는 없을 것입니다. 이 모든 것이 말 그대로 전부 온라인에 있고 git으로 버전 관리되고 있으며, 관련된 사람들도 모두 아직 살아 있어 쉽게 연락할 수 있습니다.
그리고 무언가를 채워 넣었을 때, 조사하다가 멋진 것을 발견했을 때, 그것을 글로 정리하십시오. 가능하면 공개적으로 하십시오!