바퀴를 재발명하는 것이 왜 유용한가요?

얼마 전 고위직에 지원하는 JavaScript 개발자를 인터뷰했습니다. 인터뷰에 함께 참석한 동료는 후보자에게 HTTP 요청을 만들고, 실패할 경우 여러 번 재시도하는 함수를 작성해 달라고 요청했습니다.

그는 보드에 직접 코드를 썼기 때문에 대략적인 것을 그리는 것으로 충분할 것입니다. 만일 그가 문제가 무엇인지 잘 이해하고 있다는 점만 보여주었다면 우리는 상당히 만족했을 것입니다. 그러나 불행하게도 그는 성공적인 해결책을 찾지 못했습니다. 그런 다음 우리는 흥분해서 작업을 좀 더 쉽게 만들기로 결정하고 그에게 콜백이 있는 함수를 약속에 기반한 함수로 바꿔달라고 요청했습니다.

하지만 아쉽게도. 예, 그는 이전에 그러한 코드를 접한 적이 있는 것이 분명했습니다. 그는 그곳에서 모든 것이 어떻게 작동하는지 일반적인 용어로 알고있었습니다. 우리에게 필요한 것은 개념에 대한 이해를 보여주는 솔루션의 스케치뿐입니다. 그러나 후보자가 게시판에 작성한 코드는 완전 넌센스였다. 그는 JavaScript에 Promise가 무엇인지에 대해 매우 모호한 생각을 가지고 있었고 그것이 왜 필요한지 실제로 설명할 수 없었습니다. 후배라면 용서할 수 있겠지만, 그는 더 이상 선배의 자리에 어울리지 않았다. 이 개발자는 어떻게 복잡한 약속 체인의 버그를 수정하고 자신이 정확히 무엇을 했는지 다른 사람들에게 설명할 수 있을까요?

개발자는 기성 코드를 자명하다고 생각합니다.

개발 과정에서 우리는 재현 가능한 재료를 끊임없이 접하게 됩니다. 매번 다시 작성할 필요가 없도록 코드 조각을 전송합니다. 따라서 핵심 부분에 모든 주의를 집중함으로써 우리는 작업하는 완성된 코드를 자명한 것으로 봅니다. 즉, 모든 것이 제대로 작동할 것이라고 가정할 뿐입니다.

대개는 효과가 있지만 상황이 까다로울 때는 메커니즘을 이해하는 것이 도움이 됩니다.

따라서 우리의 수석 개발자 자리 후보자는 약속 객체가 자명하다고 생각했습니다. 아마도 다른 사람의 코드 어딘가에서 그런 일이 발생하면 어떻게 대처해야 할지 아이디어가 있었겠지만, 일반적인 원리를 이해하지 못했고 인터뷰 중에 스스로 반복할 수도 없었습니다. 아마도 그는 그 조각을 마음 속으로 기억했을 것입니다. 그렇게 어렵지는 않습니다.

return new Promise((resolve, reject) => {
  functionWithCallback((err, result) => {
   return err ? reject(err) : resolve(result);
  });
});

나도 그랬다. 그리고 아마도 우리 모두 어느 시점에서는 해본 적이 있을 것이다. 그들은 나중에 작업에 사용할 수 있도록 코드 조각을 암기하면서 모든 것이 어떻게 작동하는지에 대한 일반적인 아이디어만 가지고 있었습니다. 그러나 개발자가 개념을 진정으로 이해했다면 그는 아무것도 기억할 필요가 없을 것입니다. 그는 단지 그것을 수행하는 방법만 알 뿐이며 필요한 모든 것을 코드에서 쉽게 재현할 수 있을 것입니다.

뿌리로 돌아가라

아직 프론트엔드 프레임워크의 지배력이 확립되지 않았던 2012년에는 jQuery가 세상을 지배하고 있었는데, 저는 이 책을 읽었습니다. 자바 스크립트 닌자의 비밀, jQuery 창시자인 John Resig가 작성했습니다.

이 책은 독자에게 처음부터 자신만의 jQuery를 만드는 방법을 가르치고 라이브러리를 만들게 된 사고 과정에 대한 고유한 통찰력을 제공합니다. 최근 몇 년 동안 jQuery는 예전의 인기를 잃었지만, 나는 여전히 이 책을 적극 추천합니다. 그녀에 대해 가장 인상 깊었던 점은 이 모든 것을 나 스스로도 생각할 수 있다는 끈질긴 느낌이었습니다. 저자가 설명하는 단계는 너무 논리적이고 명확해 보였기 때문에 실제로만 접근하면 jQuery를 쉽게 만들 수 있다는 생각이 진지하게 시작되었습니다.

물론 실제로는 이런 일도 할 수 없었을 것입니다. 참을 수 없을 정도로 어렵다고 판단했을 것입니다. 내 자신의 솔루션은 작동하기에는 너무 단순하고 순진해 보이며 포기할 것입니다. 나는 jQuery를 자명한 것으로 분류하고, 올바른 작동에서는 맹목적으로 믿어야 합니다. 그 후 나는 이 라이브러리의 메커니즘을 탐구하는 데 시간을 거의 낭비하지 않고 단순히 일종의 블랙박스로 사용할 것입니다.

하지만 이 책을 읽으면서 나는 다른 사람이 되었다. 나는 소스 코드를 읽기 시작했고 많은 솔루션의 구현이 실제로 매우 투명하고 명백하다는 것을 발견했습니다. 아니, 물론 이런 일을 스스로 생각하는 것은 다른 이야기입니다. 하지만 다른 사람의 코드를 연구하고 기존 솔루션을 재현하는 것은 우리 자신만의 무언가를 찾는 데 도움이 됩니다.

당신이 얻는 영감과 당신이 알아차리기 시작하는 패턴은 당신을 개발자로서 변화시킬 것입니다. 당신은 끊임없이 사용하고 마법의 유물로 생각하는 데 익숙한 멋진 라이브러리가 마법에 전혀 작동하지 않고 단순히 문제를 간결하고 수완있게 해결한다는 것을 알게 될 것입니다.

때로는 코드를 자세히 살펴보고 단계별로 분석해야 하지만 이것이 작고 일관된 단계로 이동하면서 작성자의 경로를 솔루션으로 반복할 수 있는 방법입니다. 이를 통해 코딩 프로세스에 대해 더 깊이 알아볼 수 있고 자신만의 솔루션을 찾는 데 더 많은 자신감을 가질 수 있습니다.

제가 처음 Promise 작업을 시작했을 때 그것은 마치 순수한 마법처럼 느껴졌습니다. 그러다가 그것들이 동일한 콜백을 기반으로 한다는 사실을 알게 되었고, 내 프로그래밍 세계는 완전히 뒤집어졌습니다. 그래서 콜백으로부터 우리를 구하는 것이 목적인 패턴 자체가 콜백을 사용하여 구현됩니까?!

이것은 내가 다른 눈으로 문제를 보는 데 도움이 되었고 이것이 내 앞에 있는 난해한 코드 조각이 아니며, 내 인생에서 결코 이해하지 못할 엄청나게 복잡한 코드가 아니라는 것을 깨닫는 데 도움이 되었습니다. 그저 호기심과 깊은 몰입만 하면 문제 없이 이해할 수 있는 패턴들이다. 이것이 바로 사람들이 코딩을 배우고 개발자로 성장하는 방법입니다.

이 바퀴를 재발명하세요

그러니 계속해서 바퀴를 재발명하세요. 자신만의 데이터 바인딩 코드를 작성하고, 자체적으로 Promise를 만들거나, 자신만의 상태 관리 솔루션을 만드세요.
아무도 이 모든 것을 사용하지 않을 것이라는 점은 중요하지 않습니다. 하지만 이제 여러분은 이를 수행하는 방법을 알고 있습니다. 그리고 나중에 자신의 프로젝트에서 그러한 개발을 사용할 기회가 있다면 그것은 일반적으로 좋습니다. 당신은 그것을 개발하고 다른 것을 배울 수 있을 것입니다.

여기서 중요한 점은 코드를 프로덕션 환경으로 보내는 것이 아니라 새로운 것을 배우는 것입니다. 기존 솔루션의 구현을 직접 작성하는 것은 최고의 프로그래머로부터 배우고 기술을 연마할 수 있는 좋은 방법입니다.

출처 : habr.com