개발

React와 Node.js 개발자를 위한 파일 네이밍의 모든 것

syaku 2024. 12. 5. 12:30
728x90
반응형

파일 네이밍 규칙 정리 및 가이드

네이밍 규칙을 정의하면 프로젝트의 일관성을 유지하고, 파일의 역할을 쉽게 이해할 수 있습니다. 아래는 React.js와 Node.js 각각의 파일 네이밍 방식, 예시 코드, 장단점, 그리고 주의사항에 대해 정리한 내용입니다.

1. React.js 파일 네이밍 규칙

파일 네이밍 방식:

  1. 컴포넌트: PascalCase
    컴포넌트 파일명은 컴포넌트 이름과 동일하게 PascalCase로 작성합니다. 예: UserName.tsx
  2. 훅(Hooks): camelCase
    파일명은 항상 use로 시작하며 camelCase를 사용합니다. 예: useUserName.ts

예시 코드:

UserName.tsx

import React from 'react';

const UserName: React.FC = () => {
  return <h1>User Name Component</h1>;
};

export default UserName;

useUserName.ts

import { useState } from 'react';

export const useUserName = () => {
  const [userName, setUserName] = useState<string>('John Doe');
  return { userName, setUserName };
};

2. Node.js 파일 네이밍 규칙

파일 네이밍 방식:

  • 케밥 케이스(kebab-case)를 사용하며, 파일명에는 역할과 목적을 명확히 나타내기 위해 .와 -를 조합합니다.
    • 컨트롤러: username.controller.ts
    • 설정 파일: data-source.config.ts, redis.config.ts

예시 코드:

username.controller.ts

import { Request, Response } from 'express';

export const getUserName = (req: Request, res: Response): void => {
  res.json({ userName: 'John Doe' });
};

data-source.config.ts

export const dataSourceConfig = {
  host: 'localhost',
  port: 5432,
  username: 'admin',
  password: 'securepassword',
};

redis.config.ts

export const redisConfig = {
  host: '127.0.0.1',
  port: 6379,
};

3. 테스트 케이스 파일 구조

테스트 파일은 프로젝트의 명확한 분리를 위해 /__tests__/ 디렉터리 하위에 배치합니다. 테스트 대상과 동일한 이름을 사용하고, 파일명은 .test.ts로 확장합니다.

디렉터리 구조:

src/
  controllers/
    username.controller.ts
  configs/
    data-source.config.ts
    redis.config.ts
__tests__/
  username.controller.test.ts
  data-source.config.test.ts

예시 테스트 코드:

username.controller.test.ts

import { getUserName } from '../src/controllers/username.controller';

describe('getUserName', () => {
  it('should return the user name', () => {
    const mockReq = {};
    const mockRes = { json: jest.fn() };
    getUserName(mockReq as any, mockRes as any);
    expect(mockRes.json).toHaveBeenCalledWith({ userName: 'John Doe' });
  });
});

장점과 단점

장점

  1. 일관성 유지: 역할별로 명확한 네이밍 규칙이 적용되면 파일의 역할을 한눈에 파악할 수 있습니다.
  2. 가독성 향상: PascalCase, camelCase, kebab-case 사용으로 역할에 따라 구분이 쉽습니다.
  3. 협업 효율성: 네이밍 규칙이 명확하면 코드 리뷰와 팀원 간 협업이 수월해집니다.
  4. 확장성: 기능 추가 시 기존 규칙을 그대로 따르기만 하면 되므로 확장에 용이합니다.

단점

  1. 긴 파일명: kebab-case와 구체적인 명명 방식으로 인해 파일명이 길어질 수 있습니다.
  2. 대소문자 이슈: Git에서 대소문자 변경이 제대로 반영되지 않는 문제가 발생할 수 있습니다.
  3. 팀원 학습 시간: 처음 규칙을 도입할 때 팀원들이 익숙해지는 데 시간이 걸릴 수 있습니다.

주의사항 및 문제 해결

1. Git 대소문자 인식 문제

Git은 파일 대소문자 변경을 기본적으로 감지하지 않습니다. 이는 PascalCase와 camelCase를 혼용할 때 문제가 될 수 있습니다.

해결 방법:

  • Git에서 대소문자 변경을 강제 적용:

    git config core.ignorecase false
git mv FileName.tsx filename.tsx
git mv filename.tsx FileName.tsx

  • 팀원들에게 위 설정을 공유하여 문제를 방지합니다.

2. 명명 충돌

비슷한 이름의 파일이 많아지면 경로 관리가 어려워질 수 있습니다.

해결 방법:

  • 도메인별로 하위 디렉터리를 생성하여 파일을 분리합니다.
  • 예: user.controller.ts, admin.controller.ts를 각각 user/와 admin/ 디렉터리에 배치.

3. 파일명 혼동

PascalCase와 kebab-case 규칙을 혼동하면 역할 구분이 모호해질 수 있습니다.

해결 방법:

  • 프로젝트 초기에 명명 규칙 문서를 작성하고 코드 리뷰 과정에서 엄격히 준수합니다.

4. 파일명 길이

kebab-case로 구성된 파일명이 길어져 불편할 수 있습니다.

해결 방법:

  • 불필요한 접미사(helper, utils 등)를 제거하거나 약어를 사용하여 간결하게 작성합니다.

정리

파일 네이밍 규칙은 프로젝트의 가독성과 유지보수성을 결정짓는 중요한 요소입니다. 명확한 가이드라인을 설정하고 이를 팀 내에서 지속적으로 공유 및 검토하세요. 이를 통해 생산성을 높이고 협업의 효율성을 극대화할 수 있습니다.

728x90
반응형