Dart 튜토리얼 31편: 코드 품질과 분석(dart analyze·lints·analyzer plugins·diagnostics)

Why#

NOTE

IDE에서 보이는 경고/에러를 “커맨드라인에서도” 같은 기준으로 확인할 수 있어야, CI에서도 같은 결과를 보장할 수 있습니다.
그래서 dart analyze를 기본 검사로 고정하는 것이 유리합니다.

What#

NOTE

dart analyze는 IDE에서 하는 것과 같은 정적 분석(static analysis)⁷을 커맨드라인에서 수행합니다.

How#

TIP

프로젝트 루트에서 분석을 실행합니다.

1
$ dart analyze

하위 디렉터리 또는 단일 파일만 대상으로 할 수도 있습니다.

1
$ dart analyze bin

Watch out#

WARNING

실패 기준을 조정하는 옵션이 있습니다.
예를 들어 info 레벨 이슈도 실패로 처리하려면 --fatal-infos를 사용할 수 있습니다.

1
$ dart analyze --fatal-infos

결론: dart analyze를 기본 검사로 고정하면, IDE/CI에서 같은 기준으로 문제를 조기에 잡을 수 있습니다.

Why#

NOTE

규칙을 하나씩 고르기 시작하면, 팀마다 기준이 달라지고 서로 충돌하는 규칙을 섞을 수도 있습니다.
그래서 검증된 “규칙 세트”로 시작하는 편이 안전합니다.

What#

NOTE

lints(린트) 규칙은 코드에서 가능한 문제를 찾는 규칙 모음입니다.
규칙 세트로 lints 패키지의 core/recommended와, Flutter용 flutter_lints가 소개됩니다.
또한 일부 규칙은 Experimental/Deprecated/Removed 같은 상태를 가질 수 있다는 안내가 있습니다.

How#

TIP

처음에는 규칙 세트를 적용하고, 그 다음 “프로젝트에 맞는 규칙”만 추가/제거하는 방식으로 진행합니다.
또한 일부 규칙은 quick fix(자동 수정)를 제공할 수 있고, 그때는 dart fix⁸로 자동 적용할 수 있다는 흐름이 제시됩니다.

Watch out#

WARNING

lints는 false positive가 있을 수 있고, 규칙끼리 “철학이 다를 수 있다”는 주의가 있습니다.
즉, 규칙의 목적이 충돌한다면 프로젝트 기준(패키지/앱/Flutter)을 먼저 정해야 합니다.

결론: lints는 세트로 시작하면 기준이 빠르게 정리되고, 이후 필요한 규칙만 선택적으로 관리할 수 있습니다.

Why#

NOTE

기본 lints만으로는 프로젝트 특유의 규칙(예: 특정 패턴 금지, 특정 API 사용 강제)을 표현하기 어렵습니다.
그럴 때 플러그인으로 규칙을 확장할 수 있습니다.

What#

NOTE

analyzer plugins는 dart analyze와 IDE 분석 서버에 “커스텀 진단(경고/린트) + quick fix + assists”를 추가할 수 있는 확장입니다.
analysis_options.yaml⁹의 plugins: 섹션에서 활성화할 수 있습니다.

How#

TIP

버전 제약으로 플러그인을 추가하는 예시가 제시됩니다.

1
plugins:
2
  my_plugin: ^1.0.0

로컬 개발 중인 플러그인을 경로로 연결하는 예시도 제시됩니다.

1
plugins:
2
  my_plugin:
3
    path: /path/to/my_plugin

플러그인이 제공하는 진단 중 특정 규칙만 켜고/끄는 설정도 가능합니다.

1
plugins:
2
  my_plugin:
3
    path: /path/to/my_plugin
4
    diagnostics:
5
      rule_1: true
6
      rule_2: true
7
      rule_3: false

Watch out#

WARNING

플러그인 진단은 ignore 주석으로 무시할 수 있고, 특정 플러그인 진단을 가리키려면 plugin_name/code 형태로 접두사를 붙이는 방식이 제시됩니다.

1
// ignore: some_plugin/some_code

1
// ignore_for_file: some_plugin/some_code

결론: analyzer plugins를 쓰면 프로젝트 전용 규칙까지 정적 분석 단계에서 강제할 수 있습니다.

Why#

NOTE

분석 도구가 내는 메시지는 “문제 요약”일 뿐입니다.
무엇을 바꿔야 하는지 빠르게 찾으려면 진단 코드 기준으로 의미를 확인하는 습관이 필요합니다.

What#

NOTE

diagnostics 인덱스는 analyzer가 내는 진단 메시지들을 모아두고, 각 메시지의 의미와 해결 방향을 찾을 수 있게 구성되어 있습니다.

How#

TIP

분석 결과에서 진단 코드(또는 메시지 제목)를 복사해 diagnostics 인덱스에서 찾아봅니다.
팀에서는 자주 나오는 진단 코드를 “규칙/리뷰 체크리스트”로 정리해두면 반복이 줄어듭니다.

Watch out#

WARNING

진단은 언어/SDK 버전이 바뀌면서 새로 생기거나 의미가 달라질 수 있습니다.
따라서 “같은 코드인데 갑자기 경고가 늘었다”면, 분석기/SDK 업데이트 영향을 먼저 확인해야 합니다.

결론: diagnostics 인덱스를 기준으로 메시지를 해석하면, 문제 해결 속도가 안정적으로 빨라집니다.