1.1 객체와 클래스
오늘은 JavaScript 프로그램이 어떻게 구성되는지 알아볼 거야. 그리고 제일 중요한 소식: JavaScript 프로그램은 클래스랑 객체로 구성돼. JavaScript는 객체 지향 언어라서 모든 게 다 객체야: 숫자, 문자열, 함수, 심지어 클래스까지도.
그러면 클래스가 뭐냐고?
비유를 하나 들어볼게. 작은 배를 만든다고 상상해봐. 먼저 설계도를 만들고, 그걸 공장에 보내면 공장에서 설계도를 바탕으로 배를 만들어 줄 거야. 아니, 한 대가 아니라 열 대도 만들 수 있어. 아니, 원하는 만큼! 하나의 설계도로 수십 대의 동일한 배가 만들어지는 게 중요한 포인트야.
JavaScript로 프로그래밍하는 것도 딱 똑같아.
설계도
프로그래머는 설계자랑 같은 거야. 설계자는 설계도를 그리고, JavaScript 프로그래머는 클래스를 작성하지. 그런 다음 설계도를 바탕으로 부품들이 만들어지고, 클래스를 바탕으로 객체들이 만들어지는 거야.
먼저 클래스(설계도)를 작성하고, 그 다음 프로그램 실행 중에 이 클래스들로부터 JavaScript가 객체를 생성하는 거야. 설계도로 배를 만드는 것처럼 말이야.
설계도는 하나지만, 배는 여러 대가 있을 수 있어. 배는 이름도 다르고, 실어 나르는 화물도 달라. 하지만 공통점도 많아: 다 배이고, 구조가 같고, 비슷한 일을 할 수 있다는 점.
또 다른 비유를 들어볼게...
개미굴
개미굴은 객체 간의 상호작용을 보여주는 좋은 예야. 가장 단순한 개미굴에도 세 가지 클래스의 개미들이 있어: 여왕 개미, 전사 개미, 그리고 일꾼 개미.
각 클래스의 개미 수는 다 달라. 여왕은 개미굴에 단 한 마리만 있고, 전사는 수십 마리, 일꾼 개미는 수백 마리야. 세 가지 클래스와 수백 개의 객체가 있는 거지. 그런데 개미들은 딱 정해진 규칙 안에서 다른 개미들과 상호작용하거나 다른 클래스의 개미들과 상호작용해.
이건 진짜 완벽한 예야. 일반적인 프로그램에서도 다 이런 방식으로 작동해. 메인 객체가 있고, 이 객체가 다른 클래스의 객체들을 생성해. 그리고 생성된 객체들이 서로 상호작용하거나 프로그램의 "외부 세계"와 상호작용하지. 각 객체의 동작은 엄격하게 프로그래밍돼 있어.
이 두 가지 예시는 사실 같은 이야기의 두 측면이야. 진실은 그 사이에 있어. 첫 번째 예시(설계도와 배 이야기)는 클래스와 그 클래스의 객체들 간의 관계를 보여줘. 비유가 기가 막혀. 두 번째 예시(개미굴)는 프로그램 실행 중 존재하는 객체들과 그 객체들이 작성된 클래스 간의 관계를 보여줘.
먼저 프로그램에 존재하는 모든 객체에 대한 클래스를 작성해야 하고, 그 다음에는 서로의 상호작용 방식을 서술해야 해. 복잡해 보이지만, 생각보다 쉽다니까.
JavaScript에서는 프로그램 실행 중 모든 엔티티가 객체고, 프로그램 작성은 다양한 객체 간의 상호작용 방식 기술로 요약돼. 객체들은 단순히 서로의 메서드를 호출하고 필요한 데이터를 전달해.
문서화
그런데 어떤 데이터를 메서드에 전달해야 할까? 이미 다 정리돼 있어.
보통 각 클래스에는 그게 왜 만들어졌는지 설명이 있어. 그리고 보통 메서드마다 그게 무슨 일을 하는지, 어떤 데이터를 전달해야 하는지 서술이 돼 있어.
클래스를 사용하려면 대략적으로 그게 무슨 일을 하는지 알아야 하고, 메서드마다 정확히 무슨 일을 하는지 알아야 해. 하지만 그게 어떻게 작동하는지는 몰라도 상관없어. 그야말로 마법 지팡이지.
파일 복사 코드를 한 번 보자:
const fs = require('fs');
// 파일 열기
const src = fs.createReadStream('source.txt');
const dst = fs.createWriteStream('destination.txt');
// source.txt 내용을 destination.txt로 복사
src.pipe(dst);
// 복사가 끝난 뒤에는 파일 닫기
src.on('end', () => {
src.close();
dst.close();
});
코드를 한 줄 한 줄 읽으면 대략적으로 무슨 일을 하는지 알 수 있어. 물론 경험과 연습이 필요한 부분이긴 해. 어느 정도 시간이 지나면 이 코드가 익숙하고 이해하기 쉬워질 거야.
1.2. 프로그램 설계
프로그램 설계는 하나의 예술이야. 간단하면서도 동시에 어려워. 간단한 이유는 엄격한 법칙이 없기 때문이야: 금지되지 않은 것은 모두 허용돼. 어려운 이유도 똑같아: 실행 방법이 너무 많기 때문에 최고의 방법을 찾기가 어려워.
프로그램 설계를 한다는 것은 책을 쓰는 것과 같아. 한편으로는 단순히 문자, 단어, 문장을 쓰는 것뿐이야. 다른 한편으로는 줄거리, 캐릭터, 내부 갈등, 대립, 서술 스타일, 긴장감 등이 중요하지.
가장 중요한 것은, 당신의 코드를 다른 개발자들을 위해 작성한다는 점이야.
모든 제품 개발은 변경 작업의 연속이야: 여기에 추가하고, 저기를 삭제하고, 다시 저곳을 변경하고. 이렇게 작은 반복 작업으로 거대한 프로젝트가 탄생해.
코드에 대한 주요 요구 사항은 다른 개발자들이 이해할 수 있어야 한다는 거야. 잘못되었지만 이해 가능한 코드는 수정할 수 있어. 완벽하지만 이해하기 어려운 코드는 개선할 수 없어. 그렇게 되면 결국 버려져야 할 거야.
그렇다면 좋은 코드와 이해하기 쉬운 코드는 어떻게 작성해야 할까?
세 가지를 하면 돼:
- 메서드 안에서 좋은 코드와 이해하기 쉬운 코드를 작성하기 — 가장 기본적인 부분
- 프로그램에서 필요한 엔터티를 결정하기
- 프로그램을 논리적 부분으로 적절히 나누기
이 개념들에는 무엇이 있을까?
메서드 내부에서 좋은 코드 작성하기
만약 당신이 기본적인 영어 실력을 가지고 있다면, 간혹 코드가 마치 영어 문장처럼 쉽게 읽히는 것을 인지했을 수도 있어:
class Cat extends Pet— 고양이 클래스는 반려동물 클래스를 확장합니다while (stream)— 스트림이 비어 있지 않을 동안 ...a < b ? a : b—a가b보다 작으면a를 반환, 그렇지 않으면b를 반환
이것은 의도된 방식으로 작성된 거야. JavaScript는 주석 없이도 이해할 수 있는 자체 문서화된 코드를 쉽게 작성할 수 있는 몇 가지 언어 중 하나야. JavaScript의 좋은 코드에서는 많은 메서드가 마치 영어 문장처럼 읽혀.
당신의 목표는 최대한 단순하고 간결하게 코드를 작성하는 거야. 코드 작성 중에 당신의 코드가 얼마나 읽기 쉬울지 항상 고민하면서 작성해 봐. 그러면 올바른 방향으로 나아갈 수 있어.
JavaScript에서는 읽기 쉬운 코드를 작성하는 것이 일반적이야. 가능하면 각각의 메서드가 화면에 완전히 들어올 수 있도록 작성하는 게 좋아(메서드 길이 — 20-30줄). 이는 JavaScript 커뮤니티 전반의 표준이야. 코드를 개선할 수 있다면, 개선해야 해.
좋은 코드를 배우는 최고의 방법은 끊임없는 연습이야. 많은 코드를 작성하고, 다른 사람의 코드를 공부하고, 경험 많은 동료들에게 코드 리뷰를 요청해봐. 그리고 “이 정도면 괜찮다”라고 말하는 순간, 당신의 발전이 멈출 수 있다는 것을 기억해.
프로그램에 필요한 엔터티를 결정하기
당신은 다른 개발자들이 이해할 수 있는 코드를 작성해야 해. 프로그램 설계 시 10명의 개발자 중 9명이 A, B, C 클래스를 만든다면, 당신도 A, B, C 클래스를 작성해야 해. 당신은 다른 사람들이 이해할 수 있는 코드를 작성해야 해.
뛰어나고 잘 작동하고 빠르지만 독창적인 코드는 나쁜 코드야.
당신은 다른 프로젝트를 공부해야 해: 이것은 IT 산업에서 수십 년 동안 축적된 모든 지혜를 습득하는 가장 좋은, 가장 빠르고, 가장 쉬운 방법이야.
그리고 참고로, React는 이미 훌륭하고 인기 있고 잘 문서화된 프로젝트 중 하나로 존재하고 있어. React로 시작해봐.
React의 클래스와 클래스 구조를 분석해. 왜 일부 메서드는 정적으로 선언되어 있고 그렇지 않은가? 왜 메서드의 매개변수가 특정 방식으로 설정되었는가? 왜 특정 메서드가 만들어졌는가? 왜 클래스들이 특정 방식으로 이름 지어졌고 특정 패키지에 위치해 있는가?
이 모든 질문에 대한 답을 이해하기 시작하면, 다른 사람들이 이해할 수 있는 코드를 작성할 수 있을 거야.
하지만 D3.js 메서드 내부 코드를 분석하지 않도록 주의하고 싶어. 많은 메서드의 코드는 작업 속도를 극대화하기 위해 다시 작성되었으며, 읽기 쉬운 상태는 아니야.
논리적으로 프로그램을 나누기
일반적으로 모든 프로그램은 부분이나 모듈로 나뉘어져 있어. 각 부분은 프로그램의 특정 측면을 담당하지.
컴퓨터에는 시스템 블록, 모니터, 키보드와 같은 독립적인 부분들이 있어. 그들의 상호작용은 표준화되어 있어: USB, HDMI 등. 만약 키보드에 커피를 쏟았다면, 키보드를 그냥 물로 씻고 말려서 다시 사용할 수 있어.
그러나 노트북은 모놀리식 아키텍처의 예야: 논리적 부분들이 있긴 하지만, 훨씬 더 강하게 통합되어 있어. Macbook Pro의 경우 키보드를 청소하려면 노트북의 반을 분해해야 할 수도 있어. 노트북에 커피를 쏟으면 새로운 노트북을 주문해야 할지도 몰라. 조심하자!
1.3 자신만의 클래스 만들기
프로그래밍을 배우고 있는 당신은 처음부터 시작해야 해 — 자신의 클래스를 만드는 것을 연습하면서.
이미 클래스를 만들어 본 적이 있을 수 있겠지만, 프로그램에서 필요한 클래스가 무엇인지, 그 클래스들이 어떻게 불려야 하는지, 어떤 메서드가 포함되어야 하는지, 그리고 서로 어떻게 상호작용해야 하는지에 대해 이해하는 법을 배워야 해.
엔터티 목록
어디서 시작해야 할지 모르겠다면, 처음부터 시작해.
프로그램 설계를 시작할 때, 메모장에 프로그램에 필요한 엔터티(객체) 목록을 작성할 수 있어. 그런 다음, 각 엔터티를 별도의 클래스로 프로그램으로 만들어.
예제
예를 들어, 체스를 만들고 싶다고 가정해보자. 체스판과 6가지 유형의 말들이 필요할 거야. 말들은 다르게 움직이고, 서로 다른 가치를 가지므로, 이것들은 각각 별도의 클래스여야 해. 그리고 무엇보다도 초반에 클래스가 많을수록 좋아.
두 개의 클래스를 작성해야 하는데 열 개를 작성했다면 이는 오히려 좋은 신호야. 그러나 열 개를 작성해야 할 때 두 개, 아니 하나만 작성하는 초보자를 자주 볼 수 있어. 그러니, 더 많은 클래스를 작성해, 프로그래머 여러분. 그리고 그것을 통해 모든 사람이 이해할 수 있는 코드를 작성할 수 있을 거야. 아마도 자신만 빼고 😛
체스
체스를 위한 클래스를 작성하기로 했다면, 이 클래스들은 어떻게 보일까?
체스판은 단순히 8x8 배열일까? 아니면 별도의 클래스를 만들어, 내부에 배열에 대한 참조를 유지하도록 하는 게 더 좋을까? 만약 그렇게 한다면, "체스판" 클래스에 유용한 메서드를 많이 추가할 수 있을 거야. 예를 들어, 특정 칸이 비어 있거나 점유 되어 있는지 확인하는 메서드 등.
일반적으로 초기에는 항상 이런 원칙을 따를 수 있어: 프로그램은 다양한 엔터티를 가지고 있으며, 각 엔터티에는 유형이 있어. 이 유형이 바로 클래스야.
GO TO FULL VERSION