코드 린팅

오늘은 ESLint를 코드베이스에 통합하는 작업을 했기 때문에 정말 좋은 날이었습니다! 나는 재미있는 코드 원숭이입니다. 나는 Linting, 사용자/기술/제품 문서화, 테스트, 접근성 및 보안과 같은 좋은 코딩 방법을 좋아합니다. 이러한 주제는 일반적으로 작업 코드 출시보다 우선순위가 낮습니다. 왜냐하면 코드는 제가 프로그래밍 열정으로 나열한 것 중 어느 것도 작동하지 않아도 작동할 수 있기 때문입니다. 그러나 이러한 모든 방법을 구현하면 코드가 깨지는 일이 거의 없으며 신뢰할 수 있는 코드가 됩니다. 처음부터 "안정적으로 작동하는 코드"를 만들어 보는 것은 어떨까요?

내가 린팅을 좋아하는 이유는 무엇일까?

린팅은 일반적인 오류를 조기에 발견하는 데 도움이 됩니다. Linting 규칙은 잘못된 코딩 관행을 식별할 수 있으므로 개발자는 이를 프로젝트에 도입하지 않습니다. Linting은 예를 들어 let이나 Shadow 변수 대신 const를 사용해야 하는 시기를 식별할 수 있습니다.

린팅으로 잘못된 코드를 방지하는 것은 잘못된 코드를 디버깅하는 데 많은 노력을 기울일 가치가 있습니다.

나의 도전

우리는 많은 개발자가 기여하는 기존 코드베이스를 갖고 있었습니다. ESLint를 설치하고 보고서를 실행한 후 코드에서 5,000개 이상의 Linting 위반이 발견되었습니다. NextJS, TypeScript, A11y 및 JavaScript와 함께 사용할 수 있는 최고의 린팅 규칙을 찾았습니다. 위반 사항이 너무 많았기 때문에 점진적으로 오류를 찾기로 결정했습니다. ESLint에는 자동 수정 기능이 있지만 기존 코드베이스에서 실행하지 말고 작동할 것으로 기대하지 마십시오. 아냐, 아냐, 젊은이는 없어. 반복해야 합니다!

중요한 규칙을 ❌ '오류'로 설정하고 나머지는 '경고' 또는 '해제'로 설정했습니다. 그런 다음 코드를 다시 배포하기 전에 수정해야 할 사항을 식별하기 위해 보고서를 다시 실행했습니다. 모든 오류를 수동으로 수정하고 코드를 빌드할 수 있게 되면 단위 테스트를 실행하여 여전히 모든 것을 통과하고 있는지 확인했습니다. 좋은 린팅은 코드를 깨뜨려서는 안 됩니다. 기껏해야 린팅은 개발자를 지원하기 위한 것입니다. 주니어 개발자가 더 나은 코드 작성 방법을 배울 수 있도록 도와주세요.

모든 오류를 식별하고 수정하거나 무시한 후에는 배포할 수 있으며 코드가 "오늘" 얻을 수 있는 것만큼 좋다는 것을 알 수 있습니다. 이제 코드베이스가 수정되었으므로 앞으로 "auto-magic-fix"를 사용할 수 있으며 Linting 오류를 수정할 확률이 50/50이라고 확신합니다.

나의 학습

ESLint가 좀 성장한 것 같아요! Linting 라이브러리가 아닌 코드 형식 지정 라이브러리에서 유지 관리해야 하는 일부 코드 형식 지정 규칙을 더 이상 지원하지 않습니다. ESLint는 v9부터 많은 기능을 더 이상 사용하지 않으며 전부는 아니더라도 대부분을 Stylistic으로 옮겼습니다!

저는 코드 형식 지정에 Prettier를 사용하고 Typescript는 Stylistic에서 플래그를 지원하므로 ESLint v8.53.0을 사용하여 ESLint의 우수한 코드 형식을 유지할 수 있습니다. 하지만 결국에는 9로 이사해야 하므로 이것은 단지 "막장"일 뿐입니다.

즐거운 코딩하세요!

위 내용은 코드 린팅의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!