> 안녕하세요. 현대오토에버 품질시스템팀의 최시운 책임입니다.
> 현대오토에버 품질시스템팀의 Frontend 개발자이며 생산성과 코드 품질에 관심이 많습니다.

해당 시리즈는 신입 개발자로 입사해서 팀의 개발 생산성에 기여하기 위해 고민했던 내용들과 기여했던 방법에 대해 다룹니다.

시리즈는 총 두 개의 글로 구성되어 있습니다.

1. **Code Snippet 개발을 통해 편의성과 일관성 높이기**
2. Eslint Plugin 개발을 통해 코드 레벨에서 컨벤션 오류 발견하기

이번 글에서는 'Code Snippet 개발을 통해 편의성과 일관성 높이기'라는 주제에 대해서 다루고자 합니다.

# 도입 배경

2023년 품질시스템팀은 차세대 글로벌 품질관리시스템의 프로젝트를 진행하기 위해 다양한 기술 검토와 도입, 그리고 이에 따른 컨벤션을 정립하는 과정을 거쳤습니다.
그리고 2024년에는 실제 차세대 개발을 진행하고 있습니다.
차세대 개발을 진행하면서 코드 품질의 일관성과 개발 생산성을 위해 많은 컨벤션을 작성하였고, 이를 준수하기 위해 많은 노력을 하고 있습니다.

하지만 새롭게 정의된 컨벤션을 사용하는 것에는 어려움이 있었습니다.
현재 품질시스템팀의 FE 컨벤션은 **약 15개의 페이지가 있으며** 이를 확인하기 위해서는 각 페이지에 들어가서 확인을 하는 과정을 거쳐야만 했습니다.
즉, 개발 과정에서 **반복적으로 컨벤션이 정의된 문서를 봐야 하는** 번거로운 작업이 추가되었고, 
**코드 리뷰 과정에서도 컨벤션이 문제가 되어 남겨지는 리뷰**가 많아 컨벤션을 지키고 이를 확인하기 위한 공수가 발생하였습니다.

> 👨‍🦱 : 컨벤션에 따르면 export const 형태의 내부 함수를 사용하는데 확인 부탁드립니다.
> 👧 : provider는 PascelCase가 맞지 않을지 질문드립니다!
> 👨‍🦱 : redux devtools도 넣어주세요.
> 👨‍🦱 : 주석에는 params와 return에 대한 설명도 추가가 되어야 합니다.
> *(위 사례는 실제로 받은 코드 리뷰 내용입니다.)*

이에 발생되는 불필요한 공수를 줄여 생산성에 기여하기 위해 두 가지 고민을 하였습니다.

1. 컨벤션 문서를 최소한으로 볼 수 있는 방법
2. 코드 레벨에서 컨벤션 오류를 확인할 수 있는 방법

이러한 고민 끝에 'Code Snippet'과 'Eslint Plugin'을 만들기로 하고 개발을 진행하였습니다.

먼저 이번 글에서 다룰 내용인 **Code Snippet**(이하 스니펫)은 '작은 조각'이라는 의미입니다.
코드를 특정 'prefix'를 입력하는 것을 통해 재사용 할 수 있고, 이를 통해 반복적인 작업을 줄일 수 있습니다.
스니펫을 통해 얻고자 했던 기대효과는
첫번째, **컨벤션 문서를 최소한으로 볼 수 있는 방법**과
두번째, **사용하고자 하는 기능을 손쉽게 이용할 수 있는 방법**이었습니다.

# Code Snippet을 사용하여 컨벤션 문서 조회 횟수 줄이기

품질시스템팀의 FE 컨벤션에는 많은 것들이 있지만 기본적으로 아래와 같은 공통 규칙들이 존재합니다.

1. 사전에 정의된 용도에 따라 함수 선언(Function Declaration)과 화살표 함수(Arrow Function)을 구분하기
2. 함수에는 함수를 설명할 수 있는 주석 작성하기
3. 파일명은 kebab-case로 작성하고 함수의 용도(컴포넌트, 기능)에 따라 이름을 올바르게 변경(PascalCase, camelCase)하기

## 1\. 사전에 정의된 용도에 따라 함수 선언과 화살표 함수를 구분하기

품질시스템팀에서는 두 가지 방식으로 function을 선언합니다. 바로 함수 선언과 화살표 함수를 사용하는 방식인데요, 
팀에서는 가독성을 높이기 위해 기능에 따라 선언 방식을 컨벤션으로 지정해두었습니다.
그리고 스니펫에서는 이를 'prefix'를 기준으로 구분하여 달리 선언하는 방식으로 구분 지었습니다.

```json
//snippets.code-snippets
{
    "example-component": {
	"prefix": "comp",
	"body": [
            "export default function ${1: 컴포넌트 이름을 작성해주세요.}() {",
            "",
            " return ${2}",
            "}"
        ],
	"description": "예제 컴포넌트 컨벤션"
    },
    "example-function": {
	"prefix": "func",
	"body": [
            "const ${1: 함수 이름을 작성해주세요.} = (${2: param을 작성해주세요.}) => {",
            " return ${3: 리턴값을 작성해주세요.};",
            "}",
        ],
	"description": "예제 함수 컨벤션",
    }
}
```

*(위 예시는 실제 코드와 유사하게 재작성한 내용입니다.)*

위 스니펫은 prefix를 통해 불러오는 코드를 구분하고 있습니다.
각각 'comp'와 'func'로 팀에서 정의된 컨벤션에 맞추어 컴포넌트와 동작하는 함수를 구분합니다.

각각 컴포넌트는 `export default function foo() {}`의 형태로,
동작하는 함수의 경우에는 `const foo = () => {}`의 형태로 제공하여 개발자가 무엇을 만들고자 하는지를 prefix로 입력하게 하여 이에 맞춘 컨벤션을 제공합니다.
또한 각각 `${number}`를 통해 입력 순서를 제공하여 최대한 컨벤션이 어긋나는 일이 없게 작성하였습니다.

이를 통해 개발자는 작성하고자 하는 코드의 prefix를 입력하여 템플릿을 제공받아 **컨벤션이 저장된 문서를 별도로 확인하지 않아**도 됩니다.

## 2\. 함수에는 함수를 설명할 수 있는 주석 작성하기

품질시스템팀에는 다른 개발자와의 원활한 소통 및 코드 이해를 돕기 위해 기능이 있는 함수에는 주석을 작성하는 컨벤션이 있습니다.
그러나 주석은 급하게 개발을 진행하다 보면 잊히는 경우가 있고, 각 구성원마다 주석을 다는 스타일이 다르기 때문에 통일되지 않은 주석이 많아지는 경우가 있습니다.

이에, 기능이 있는 함수를 불러오는 스니펫에 주석을 입력하는 템플릿을 추가하여 주석이 누락되거나, 일관되지 않은 주석이 달리는 경우를 방지하였습니다.

```
//snippets.code-snippets
{
    "example-function": {
	"prefix": "func",
	"body": [
            "/**",
            " * ${4:함수의 설명을 작성해주세요.}",
            " * @param ${5:param의 설명을 작성해주세요.}",
            " * @returns ${6: return 값을 설명해주세요.}",
            " */",
            "const ${1: 함수 이름을 작성해주세요.} = (${2: param을 작성해주세요.}) => {",
            " return ${3: 리턴값을 작성해주세요.};",
            "}",
        ],
	"description": "예제 함수 컨벤션",
    }
}
```

*(위 예시는 실제 코드와 유사하게 재작성한 내용입니다.)*

위와 같이 함수로 사용되는 스니펫에 주석을 추가하고 '함수의 설명', 'param에 대한 설명', 'return 값에 대한 설명'을 템플릿화 하여 추가하면서
**최대한 누락되지 않고 일관된 주석을 작성할 수 있게** 도왔습니다.

## 3\. 파일명은 kebab\-case로 작성하고 함수의 용도에 따라 이름을 올바르게 변경하기

팀 내에서는 파일명을 'kebab-case'로 작성하고 있습니다.
그리고 코드 내부에서는 컴포넌트의 경우 'PascalCase'를, 기능이 있는 함수에 대해서는 'camelCase'를 사용합니다. 
이때, 대부분의 함수명은 **파일명을 따라가며** **용도에 따라서 다른 표기법을 사용**합니다.

이를 위해서 위의 스니펫에 추가적인 기능을 추가합니다.

```json
//snippets.code-snippets
{
    "example-component": {
	"prefix": "comp",
	"body": [
            "export default function ${1:${TM_FILENAME_BASE/(.+)/${1:/pascalcase}/}}() {",
            "",
            " return ${2}",
            "}"
	],
	"description": "예제 컴포넌트 컨벤션"
    },

    "example-function": {
	"prefix": "func",
	"body": [
            "const ${1:${TM_FILENAME_BASE/(.+)/${1:/camelcase}/}} = (${2: param을 작성해주세요.}) => {",
            " return ${3: 리턴값을 작성해주세요.};",
            "}",
        ],
	"description": "예제 함수 컨벤션",
    }
}
```

*(위 예시는 실제 코드와 유사하게 재작성한 내용입니다.)*

해당 기능 역시 별도의 추가적인 설정 없이 Visual Studio Code의 기본적인 스니펫 구문으로 해결할 수 있었습니다.
`TM_FILENAME_BASE`와 `/camelcase`그리고 `/pascalcase`와 같은 구문을 사용하여 손쉽게 파일명을 컨벤션에 맞추어
자동으로 'camelCase'와 'PascalCase'로 변환하여 실수로 인해 네이밍 컨벤션이 어긋나는 상황을 방지하였습니다.

# 사용하고자 하는 기능 손쉽게 이용하기

팀에서는 프론트엔드 개발을 위해 다양한 라이브러리를 활용합니다.
사용 방식은 해당 라이브러리에 잘 정의가 되어 있지만 추가적인 기능 설정 및 사용을 위해서는 Documents를 열심히 확인해야 합니다.
또한 전역 상태 라이브러리에서 상태 변경 디버깅을 위해 'redux devtools'와 같이 추가적인 기능을 사용하기 위해서 반복적으로 코드를 작성하는 것은 잊어버리기도 쉽고 반복적인 작업입니다.

실제 환경에서는 'zustand', 'tanstack-query', 'storybook'과 같은 다양한 라이브러리 사용을 손쉽게 해주는 많은 스니펫이 있지만 이 글에서는 전역 상태 관리 라이브러리인 'zustand'를 예시로 다루겠습니다.
*(zustand에 대한 구체적인 내용은 이 글에서 별도로 다루지 않겠습니다.)*

## 복잡한 기본설정 한번에 하기

zustand를 사용하기 위해 팀 내에서 정해진 규칙은 다음과 같습니다.

1. 파일 이름 및 store 이름에 `use`를 앞에 붙이기
2. 'redux-devtools' 사용을 위해 `devtools()` 사용하기
3. interface를 사용해 store의 type 정의하기

이 규칙 중 특히 2번 규칙인 "'redux-devtools' 사용을 위해 `devtools()` 사용하기"의 경우 매번 설정하기 번거로운 문제도 있고 개발을 하는 과정에서 누락되기도 합니다.

이에 아래와 같이 스니펫을 설정하여 요구사항을 만족하는 템플릿을 제공하여 번거로운 작업과 누락을 줄이고자 했습니다.

```json
//snippets.code-snippets
{
    "example-store": {    
        "prefix": "exstore",    
        "body": [
            "interface ${2: store의 타입을 작성하세요.} {",
            "${3}",
            "}",
            "",
            "/**",      
            "* ${4:전역상태에 대한 설명을 적어주세요.}",      
            "*/",      
            "const use${1} = create<${2}>(",      
                "  devtools(",      
                "      (set) => ({",      
                "        ${5:store에 들어갈 내용을 입력하세요.}",      
                "      })",      
                "  ),",      
                ");",      
                "",      
            "export default use${1};"    
        ],    
        "description": "예제 zustand store 컨벤션"  
    }
}
```

*(위 예시는 실제 코드와 유사하게 재작성한 내용입니다.)*

## prefix 이름을 기반으로 사용하고자 하는 기능 사용하기

전역 상태는 브라우저의 메모리 상태나 컴포넌트의 라이프 사이클과 관련되어 새로고침이나 페이지 이동 시에 저장되지 않습니다.
이를 해결하기 위해서는 로컬 스토리지나 세션 스토리지를 활용하여 상태를 저장하는 방법이 있고, zustand에서는 `persist()`와 같은 기능을 사용하여 이를 수행합니다.

상태를 저장하는 경우는 기능을 구현하기 위해서 필요한 경우가 생길 수 있습니다. 그리고 이러한 기능 역시 'prefix'를 통해 기본 store 기능과 구분을 두었습니다.

```json
//snippets.code-snippets
{ 
    "example-persist-store": {    
        "prefix": "expstore",    
        "body": [
          "interface ${1:store의 타입을 작성하세요.} {",
          "",
          "}",
          "",
          "const use${2} = create(",
          "  devtools(",
          "    persist<${1}>(",
          "      (set) => ({",
          "        ${4:store에 들어갈 내용을 입력하세요.}",
          "      }),",
          "      { name: ${3:스토리지 이름을 입력하세요.}}",
          "    ),",
          "  ),",
          ");",
          "",
          "export default use${2};"
        ], 
        "description": "예제 zustand store 컨벤션"  
    }
}
```

*(위 예시는 실제 코드와 유사하게 재작성한 내용입니다.)*
*(해당 예시는 localStorage만을 사용하는 예시로, 저장될 Storage를 정의하고 싶다면 `storage: ${number}`옵션을 추가하여 사용할 수 있습니다.)*

위의 예시처럼 기존 `exstore`라는 'prefix'에서 'persist'를 의미하는 'p'를 더하여 `expstore`과 같은 'prefix'를 통해 간단하게 기능을 사용할 수 있게 하였습니다.
더불어 저장될 storage의 이름을 필수로 적을 수 있게 스니펫에 추가하여 이 역시 누락되지 않게 했습니다.

# 함께 만들어가기

이 글에서는 현재 사용할 수 있는 팀 내 스니펫에 비해 적은 내용을 다루고 있습니다.
여기서 소개된 내용은 초기 제가 처음 개발을 시작하고 배포했던 4가지 기능입니다.
하지만 지금은 총 8번의 버전 배포와 20개가 넘는 기능을 가지고 있습니다.
4가지 기능으로 시작한 스니펫이 20개가 넘기 까지는 팀원 분들이 많은 참여가 있었습니다.

> 👨‍🦱 : 리액트 쿼리 관련된 스니펫도 있나요?
> 👨‍🦱 : 귀찮은건 스토리코드 세팅이 제일 귀찮은데 추가해주시나요?
> 👧 : 엄청 편한데 입력하는 순서를 더 좋게 할 수 있을거 같아요.

위와 같이 열심히 사용해 주시고 후기를 직접적으로 받으면서 더 나은 개선점과 추가할 기능들을 찾을 수 있었고 절망적인 작명 센스로 인한 이상한 prefix를 센스있는 단어들로 수정할 수 있었습니다.

그 밖에도 아래와 같은 팀원 분들의 칭찬 덕분에 더 즐겁게 개발할 수 있었습니다.

> 👨‍🦱 : 오 이거 엄청좋은데요 ㅋㅋㅋㅋㅋㅋ
> 👨‍🦱 : ~~역시 레전드 개발자~~

이렇게 처음에는 작고 간단한 완성 기능만이 있었지만
지금은 함께 만들어나간 덕분에 다양한 기능들이 추가되고 더 편리한 스니펫이 될 수 있었습니다.
이러한 과정 덕분에 저 역시도 애정을 가지고 다양한 시도와 기능을 추가하며 지속적인 업데이트를 할 수 있었습니다.

# 마무리 하며

사실 생산성에 기여했다는 거창한 제목처럼 저 역시도 '생산성'이라는 큰 키워드에 대해서 너무 큰 개념이라고 생각했고, 단어에 무턱 겁을 먹지 않았나 생각합니다.
이번 글에서 다루는 내용이 그렇게 어렵고 무거운 주제가 아닌 만큼 무엇에 기여한다는 것은 생각보다 어렵지 않은 일이라는 것을 깨달을 수 있던 프로젝트였습니다.
어떠한 큰 기능이 아닌, 간단한 기능이라도 팀의 비효율적인 작업을 줄이고 편의성에 기여한다면 이는 생산성에 기여한 것이 아닌가라는 생각을 합니다.

혹시나 반복되는 작업에 지치셨다면, 혹은 컨벤션을 자주 틀린다면 조금의 시간 투자를 통해 스니펫 만들어보시는 거 어떠신가요?

다음 글에서는 스니펫 개발 이후에 코드 레벨에서 문제를 발견하기 위해 개발했던 'eslint-plugin'을 주제로
**Eslint Plugin 개발을 통해 코드 레벨에서 컨벤션 오류 발견하기**를 주제로 글을 작성할 예정입니다.
지금까지 읽어주셔서 감사하며, 다음 글도 많은 관심 부탁드려요!

# 참고자료

* https://github.com/microsoft/vscode-vsce
* https://code.visualstudio.com/docs/editor/userdefinedsnippets
* https://gist.github.com/cmstead/7ad64539d13dfdb5a2591bc3be3c8eeb

6개월차 신입 개발자가 Snippet을 개발하여 팀 생산성에 기여한 내용에 대해서 다룹니다. 개발 과정에서의 고민 과정과 적용 사례, 그리고 느낀점에 대해서 다룹니다.