내가 생각해본 타입스크립트를 배워야 하는 이유

이 글은 사실

원숭이의 유레카 입니다.

 

아직 타입스크립트를 잘 모르지만

배워야하는 이유를 심각하게 체감했고,

그 이유를 공유하고자 제 생각을 글로 적어 남겨봅니다.

 

시작하겠읍니다.

 

타입스크립트와 자바스크립트의 역할

타입스크립트는 뭘까요?

타입스크립트는 자바스크립트의 정적 타입 체커입니다. 즉, 자바스크립트의 정적 검사(프로그램을 실행시키지 않으면서 코드의 오류를 검사) 검사자의 역할을 합니다. 자바스크립트가 워낙에 약타입에 자유분방한 언어라 배열에 문자열을 더해도 오케이, 문자열에 숫자를 더해도 오케이를 해버려서 자바스크립트로 복잡한 프로그램을 짠다면 후에 유지보수가 어려워질 수 있기에, 프로그래밍 초기 단계서부터 에러가 날 상황을 최대한 방지하고자 타입스크립트를 쓴다고 익히 알고 있습니다.

 

그러한 이유로 저는 결국에 해결책은 자바스크립트구나! 라고 생각했었습니다. 타입스크립트보다는 자바스크립트를 무조건 잘 알아야한다! 라며 타입스크립트를 많이 공부하지 않았었어요.

 

물론 자바스크립트가 가장 중요한 가치라는 생각은 변치 않았습니다. 하지만 이 생각이 타입스크립트를 열심히 공부하지 않아도 된다는 이유 또한 되지 않았습니다.

 

결론적으로... 타입스크립트를 잘 모르고 입사한 주니어로써, 타입스크립트에 대한 갈증이 심해졌습니다.

공부를 하다보니 타입스크립트는 단순히 자바스크립트의 타입만 바로 잡아주는 언어는 아니라고 생각이 들었기 때문입니다.

 

 

인터페이스의 존재와 추상화

인터페이스를 하나 정의 해보겠습니다.

interface person {
  name: '2DC';
  age: 31;
  bloging: true;
}

person 인터페이스에 따르면, person 인터페이스를 사용하는 객체들은 당연하게도 name과 age와 bloging이라는 프로퍼티만 가질 수 있습니다. 즉, 우리는 person이라는 객체를 이름과 나이와 블로그를 하는지 유무를 판단하는 대상으로 런타임 이전에 추상화를 시킬 수 있게 되었습니다.

 

객체 지향 프로그래밍에서 추상화는 가장 중요한 가치 중 하나라고 할 수 있는데요. 물론 우리는 자바스크립트에서 클래스 문법을 토대로 객체 지향 프로그래밍을 흉내낼 수 있습니다. 하지만 자바스크립트의 해괴한 + 자유로운 특성상 이를 구현하기는 쉽지 않았을 것 같습니다. 

 

이 때 타입스크립트가 비밀병기가 되어주었던 것 같습니다. 타입스크립트는 단순히 타입만 잡아주는게 아니라 인터페이스를 포함하여 제네릭, 상속 등 많은 부가적인 기능을 가지고 있습니다. 

아주 약한 깨달음으로, 타입스크립트를 통해 자바스크립트로 객체지향 프로그래밍을 구현하기 용이해졌다! 라고 할 수 있겠습니다. 그리고 확장된 기능 만큼 그 생태계 역시 방대해진 것 같습니다.

 

 

객체지향 프로그래밍과 디자인 패턴

저는 글을 쓰는 지금 당장은 객체지향 프로그래밍에 대해 사실 아무것도 모르고 그 존재만 안다고 할 수 있습니다.

하지만 과거에는 '객체지향? 그냥 그런게 있구나~' 하고 넘어갔다면 지금은 '아~! 공부를 해야하는 거구나!' 라고 느끼고 있는데요. 유지보수성의 중요성을 개발자가 되고 나서 알게 되었기 때문입니다. (...)

 

입사하고 일주일 정도 되었을까요?

기존 레거시 프로젝트의 코드에 몇 가지 기능 개발을 해본 경험이 있습니다.

그러나 그 ...그 소스코드에는 어떤 프로그래밍 규칙이랄게 없었습니다.

UI단에서 API를 직접 호출하고 데이터소스를 받아서 UI단에서 모든 로직을 직접 뿌려주는 형태였는데요.

어쩔수없이 UI 컴포넌트 한 파일에 코드가 7~800줄 가량 되는 코드가 있는 것을 수정해야 했습니다.

몇 줄 안되는 코드지만... 무섭고 힘들었습니다.

 

이러한 경험을 하고난 후, 프로그래밍을 작성할 때는 뭔가 패턴화되고 구조화된 설계가 필요하다고 생각 되었습니다.
유지보수라는 것이 현업에서 정말 어마어마하게 중요한 가치라는 것을 깨닫게 된 것 입니다.

 

그래서 (천천히~ 장기적으로~) 디자인패턴을 공부해야겠다고 마음을 먹었습니다.

우리의 선배 프로그래머분들도 주니어때 저와 같은 고민을 하셨을 것이고, 여기에 따른 해답들이 디자인 패턴에 녹아있기 때문입니다. 그리고 우리들이 흔히들 말하는 디자인 패턴들은 객체지향 프로그래밍과 꽤나 연관이 깊은것 같습니다.

 

디자인패턴과 프론트엔드

요즘 프로그래밍에서 핫한 가치는 유지보수라고 합니다. 프론트엔드에서도 그 가치는 변하지 않을 것 같은데요.

프론트엔드의 핵심 가치가 UI, UX인 것도 맞지만, 그에 비례하게 비즈니스 로직의 유지보수성을 위해서도 큰 노력을 들어야 하는 것 같습니다.

 

이를 위해서 요즘 제가 공부하고 있는 디자인 패턴은 객체지향 5원칙 중 DIP(의존성 역전 원칙)에 이점이 있는
Repository 패턴인데요. 

 

구조는 아래 사진과 같습니다.

엥 이게모야

단순하게 설명 하자면

• 클라이언트 비즈니스 로직은 데이터를 필요로 할 때, 직접 백엔드를 호출하는 것이 아니라 Repository를 통해 백엔드에 데이터를 호출합니다.
• 백엔드는 Repository를 통해 데이터 호출 명령을 받고 DTO(Data Transfer Object: 우리가 호출하면 날아오는 데이터 덩어리들)을 Repository로 보냅니다.
• 이제 Repository는 백엔드로부터 받은 DTO를 클라이언트 비즈니스 로직에서 필요한 것으로 정제해서 비즈니스 로직으로 쏴줍니다.

여기서 얻을 수 있는 이점은

백엔드의 호출 조건이나 데이터가 바뀌었을 때, 또는 그 과정에 상응하는 컴포넌트에 변경이 있었을 때

우리는 클라이언트 비즈니스 로직(상위 모듈)을 바꿀 필요 없이 하위 모듈만 수정해주면 됩니다.

의존성 역전 원칙은 "하위 모듈에 변경이 있을 때 상위 모듈이 영향을 받으면 안된다." 라고 할 수 있는데 그 점에 완벽히 부합한다고 할 수 있겠습니다.

 

이것을 프론트엔드의 개념에서 생각해보겠습니다.

• 우리가 UI에 보여줘야 하는 데이터의 이름을 product라고 가정해보겠습니다.
• 화면에 렌더링할 product가 필요할 때, UI단에서 axios로 데이터를 받은 후,
  UI단에서 직접 result.data.productArray[0] 이런 형식으로 호출할게 아니라
• UI단은 추상화된 데이터로 product만 받고, 추상화된 product는 별도의 로직에서 구체화하면 어떨까요?
  예를들어 repository에서 백엔드에서 받은 데이터 덩어리를 product로 만들어 UI가 product만 받게 되는 형식입니다.

• 이 경우에 UI는 UI의 역할만 하면서 추상화된 데이터를 요구합니다.
  추상화된 데이터는 별도의 로직에서 구체화해줍니다.
• 데이터에 관련된 로직과 UI에 관련된 로직을 분리할 수 있습니다.
  혹여나 백엔드 데이터가 바뀌더라도 상위모듈(UI)의 수정 없이 특정 repository만 유지보수하면 됩니다.

위의 요건을 잘 지키면 유지보수가 굉장히 편리해질 것 같습니다.

그리고 여기서 가장 중요한 것은 뭐니뭐니해도 추상화입니다.

어떻게 추상화를 하느냐에 따라 프로그램의 설계 정도가 바뀔 것 같습니다.

(DIP에 관련된 라이브러리가 하나 있는데

공부를 더욱 열심히해서 나중에 블로그에 제대로 포스팅 해보겠습니다.)

---

결론 : 타입스크립트와 유지보수성

타입스크립트는 우리의 코드를 인터페이스(추상화)하는 것에 용이하게 동작하며 다양한 기능들을 가지고 있습니다.

타입스크립트의 존재로 인해 객체지향 프로그래밍에서 쓰이는 디자인 패턴들을 잘 가져다 쓸 수 있게 되는 것 같고,

이것이 프로그램의 유지보수성을 크게 증가시켜 줄 수 있는 것 같습니다.

 

즉, 타입스크립트는 타입만 잡아주는 언어가 아니라

우리의 세계관을 넓혀줄 수 있는 언어였던 것 같다... 가 제 결론입니다.

---

결론2: 잡담

하하 참 별거 없지요.

 

아무튼 위와 같은 이유를 들어서 공부하겠다고 마음 먹으면

좀 더 빡세고 세세하게 공부할 수 있지 않을까? 가 제 생각이었습니다.

 

어제 이펙티브 타입스크립트라는 책을 사게 되었는데요.

일단 말만 하지 말고 공부를 하는게 답인 것 같습니다.

 

회사 업무 잘 배워가면서, 하나하나 도입하며 성장하다보면

어느새 나도 꽤 괜찮은 개발자, 괜찮은 설계자가 되지 않을까 막연히 생각해봅니다.

 

우리 모두 파이팅입니다.

 

to.멋사