서론

팀 단위로 개발을 하다보면 코드를 작성하여 개발을 하는 것 보다 훨씬 더 중요한 것이 있는데. 그것이 바로 나의 팀원들을 위한 코드를 작성해야한다. 그래야 나의 팀원에게 피해가 가지 작업속도가 배로 줄어든다. 하지만 이를 고려하는 것이란 정말 쉽지 않은 것이다.

예를 들어서 하나의 상황을 가정해보자.

A라는 사람과 B라는 사람이 협업을 하여 하나의 웹을 빌드한다고 가정해보겠다. 서로 상의하여 한명은 유틸리티나 실질적인 기능을 개발하고, 나머지 한명은 애니메이션과 메인 페이지의 구성을 한다고 가정하자.

A는 B가 쓴 코드를 보다가 도저히 이해를 할 수 없었다.

function hello(a, b){
	return a + b
}

바로 function hello를 보자 마자 이게 어디서 사용을 하는지 또 어떻게 사용하는지 하나도 감이 안온다. 코드를 작성하게 되었지만 자신만 알아보게 매개변수명을 분명하게 하지 않아서 어떤 값이 들어오고 나오는 정보도 없다. 그렇게 된다면 일일이 B에게 와서 이 함수는 어떤 것이며 이걸 사용해야 a + b 를 반환한다. 를 일일이 알려줘야 한다. 그렇게 된다면 정말 서로가 정말 피곤해 질 것 이다. 그렇기 때문에 최소한 함수의 명을 작명을 하여 어떤 기능을 하는 지 유추할 수 있게 해야하는 것이 바람직 할 것 이다.

function sumEach(a, b){
	return a + b
}

드디어 A의 피드백이 반영되어 함수명이 바뀌었다. 드디어 어떤 기능을 하는 지는 알게되었지만 A는 하나의 의문점이 더 생겼다. 바로 a + b에서 어떤 타입의 변수가 들어가야 올바르게 작동하게 될 것 인가 이다. 함수가 단순히 매개변수 숫자의 합을 반환 해서 그 용도를 알 수 있겠지만 만약 그 함수 안에 있는 로직이 굉장히 복잡하다면 a 에 숫자 혹은 문자 가 들어오는 것에 따라서 에러를 뱉을지 올바른 값을 뱉을지는 A가 내부의 함수의 로직을 뜯어보지 않는 이상은 알기 힘들 것이다. 이와 같은 상황을 방지 하기 위해서 사용하는 것이 바로 //주석 이다.

주석은 개발자가 개발을 할때 내가 무슨 내용을 기능 구현을 했고 또 어떤식으로 개발을 했는지를 알려주는 최소한의 정보이다. 주석을 너무 남발하게 된다면 코드가 길어지고 또 보기가 힘들어 지겠지만, 최소한의 정보를 담고 있다면 오히려 권장된다. 왜냐면 함수명만으로는 그 때 그 사람이 어떤 이유에서 무슨 기능을 개발했는지를 한번에 알아보기가 힘들기 때문이다. 이 주석에서 조금더 발달한 형태가 바로 JsDocs 되시겠다

Jsdocs

Jsdocs는 앞서 언급 했듯이 주석에서 조금 더 발전한 형태로 단순히 정보를 담는 것 에서 멈추지 않고 해당하는 파라미터의 타입 혹은 리턴 값을 상세히 적을 수 있는 도구이다.

어떻게 사용하는지 간단하게 알아보자.

JsDocs 참고한 내용

/**
 * @param {Number} a - Operand variable
 * @param {Number} b - Operand variable
 * @returns {Number} - Sum of a and b
 */
function sumEach(a, b) {
  return a + b;
}

위와 같이 @param {Type} VariableName - description 같이 사용할 수 있다. 어때요 정말 쉽죠? 이렇게 되면 에디터(VsCode, Webstorm 등)에서 다음과 같이 함수위에 마우스를 올렸을 때 최소한의 정보가 들어온다.

위와 같이 변수명이 무엇이며 또 어떤 값이 들어와야 하는 지 알려준다. 게다가 미약하게 타입을 검증 해주기까지 한다.

sumEach("1",2)

이렇게 정말 간단하게 타입을 지정도 가능하여 어느 정도 타입에러까지 방지 해줄수 있다. 게다가 위에서 설명한 @param 외에도 @version 을 사용하여 버젼을 위에 표시하여 무슨 버젼인지를 알려주고 @author 를 사용하여 누가 작성했는지를 표시하며 @deprecated 를 사용하면 해당하는 함수를 더 이상 사용하지 말라고 취소선 까지 그어준다. 이렇게 쉽고 간단하게 자바스크립에서 타입을 검증하는 것 까지 해보았다. 하지만 이런 의문이 들 것이다. 그냥 TS 쓰면 해결되는거 아님? 사실 맞다. 타입스크립트를 사용하면 된다.

Why not using TS?

사실 TS를 쓰면 좋긴 하다. 좋긴 한데 몇몇 사람들은 이 것을 굉장히 힘들어 하거나 싫어 하는 사람들도 꽤 있다. 예를 들어 이런 경우이다.

내가 만약 리액트에서 하나의 요소를 클릭 하는 것을 보여줄려면 Js에서는 이렇게 적는다.

export default function Main() {
  return <div onClick={(e) => console.log(e.target)}></div>;
}

하지만 TS를 적용시킬려면?

export default function Component() {
  const onClickHandel = (e: React.MouseEvent<HTMLElement>) => {};
  return <div onClick={onClickHandel}>1</div>;
}

이런식으로 일일이 내가 타입을 지정하고 또 입력을 해야하는 것이 굉장히 번거로울때가 있다. 이런식으로 TS 는 내 멍청한 실수를 보안해주고 분명 좋은 것이 많지만 내가 단순히 그냥 간단한 앱을 만들기 위함이라면? 굳이 사용을 할 필요는 없다. 라고 생각한다. 물론 협업이나 프로젝트의 규모가 커지면 커질수록 TS를 사용하여 프로젝트를 보호하는 것이 좋다고 생각한다.

Conclusion

정리하면 다음과 같다.

• Jsdocs: 에디터에서 사용할수 있는 부가 기능으로서 주석에서 그치지 않고 함수나 변수에서 더 자세한 정보를 담을 수 있는 기능
• TS 대신에 Jsdocs를 사용하는 이유: 타입스크립트는 어떤 면에서 굉장히 엄격하고 또 사용하는 방법이 까다롭기 때문에, 선호하지 않는 개발자가 은근히 많음.
• 하지만 프로젝트의 규모나 협업을 하는 사람들이 많다면 타입스크립트를 사용하는 것이 훨씬 더 좋긴 하다.

개발을 하다보면 각자 편하거나 좋아하는 도구나 언어 및 라이브러리 나 프레임워크가 있다. 이는 각자 개인의 선택이며 자신에게 맞는 도구를 찾거나 편하다고 느끼는 것을 사용하는 것이 제일 좋아보인다. 라고 필자는 생각한다.