정적 분석은 무엇입니까?
정적 분석은 무엇입니까?
정적 분석은 응용 프로그램을 실행하지 않고 소스 코드의 자동화 된 분석입니다.
프로그램 실행 중에 분석이 수행되면 동적 해석이라고 합니다.
정적 분석은 종종 다음을 감지하는 데 사용됩니다.
- 보안 취약점.
- 성능 문제.
- 표준을 준수하지 않습니다.
- 오래된 프로그래밍 구문 사용.
정적 분석 도구는 어떻게 작동합니까?
모든 정적 분석 도구에 공통적인 기본 개념은 소스 코드를 검색하여 일종의 경고 또는 정보와 관련된 특정 코딩 패턴을 식별하는 것입니다.
"JUnit 5 테스트 클래스는 '공개'가 될 필요가 없습니다"만큼 간단할 수 있습니다. 또는 "SQL 실행 문에서 사용되는 신뢰할 수 없는 문자열 입력"과 같은 식별하기 가 복잡한 것입니다.
정적 분석 도구는 이 기능을 구현하는 방법에 따라 다릅니다.
- 추상구트리(AST)를 만드는 소스 코드 구문 분석 기술
- 텍스트 정규 식 일치,
- 위의 조합.
텍스트의 정규 식 일치는 매우 유연하고 일치하는 규칙을 작성하기 쉽지만 많은 거짓 긍정으로 이어질 수 있으며 일치하는 규칙은 주변 코드 컨텍스트에 대해 무지합니다.
AST 일치는 소스 코드를 프로그램 코드로 취급하며 텍스트로 채워진 파일뿐만 아니라 보다 구체적이고 상황에 맞는 일치를 허용하며 코드에 대해 보고된 거짓 긍정 의 수를 줄일 수 있습니다.
연속 통합의 정적 분석
정적 분석은 CI(연속 통합) 프로세스 중에 수행되어 시간이 지남에 따라 코드 베이스에 대한 객관적인 보기를 수신하도록 검토할 수 있는 규정 준수 문제에 대한 보고서를 생성하는 경우가 많습니다.
어떤 사람들은 정적 분석 도구를 구성하여 코드의 특정 부분만 측정하고 규칙 하위 집합에 대해서만 보고하여 정적 분석을 코드 품질의 객관적인 척도로 사용합니다.
객관성은 시간이 지남에 따라 코드 평가에 따라 달라지지 않기 때문에 사용되는 규칙에 의해 제공됩니다. 분명히 사용되는 규칙과 구성의 조합은 주관적인 결정이며 다른 팀은 서로 다른 시간에 다른 규칙을 사용하기로 결정합니다.
CI에서 정적 분석을 수행하는 것은 유용하지만 프로그래머의 피드백을 지연시킬 수 있습니다. 프로그래머는 코딩할 때 피드백을 받지 않으며 나중에 정적 분석 도구를 통해 코드를 실행할 때 피드백을 받습니다. CI에서 정적 분석을 실행하는 또 다른 부작용은 결과를 무시하기가 쉽다는 것입니다.
팀이 정적 분석의 결과에 더 많은 주의를 기울이도록 하려면 일반적으로 메트릭이 트리거된 여러 규칙과 같은 메트릭을 초과하면 빌드 프로세스에서 임계값 메트릭을 구성하여 빌드에 실패하도록 구성할 수 있습니다.
IDE의 정적 분석
피드백을 더 빨리 받으려면 주문형 IDE에서 정적 분석 규칙을 실행하거나 코드가 변경될 때 주기적으로 실행되는 많은 IDE 플러그인이 있습니다.
그런 다음 프로그래머가 코드를 작성할 때 IDE에서 규칙 위반을 볼 수 있으며 규칙을 무시하기 어렵게 만들려면 편집기에서 밑줄이 표시된 코드로 렌더링하도록 위반을 구성할 수 있습니다.
나는 개인적으로 이것이 내 코딩을 개선하는 유용한 방법을 찾을 수 있습니다, 특히 정적 분석 도구에 의해 덮여 새로운 라이브러리로 작업 할 때. 그것은 거짓 긍정과 '시끄러운'수 있지만, 또는 규칙에 관심이 없습니다. 그러나 이는 특정 규칙을 무시하도록 정적 분석 도구를 구성하는 추가 단계를 사용하여 해결됩니다.
정적 분석 규칙에 따라 코드 수정
대부분의 정적 분석 도구를 사용하면 규칙 수정이 프로그래머에게 남아 있으므로 규칙 위반의 원인과 규칙을 수정하는 방법을 이해해야 합니다.
수정이 팀에 매우 자주 컨텍스트가 되고 사용된 기술과 합의된 코딩 스타일에 따라 위반을 해결할 수 있는 기능도 포함되는 정적 분석 도구도 거의 없습니다.
기본 규칙
정적 분석 도구에 기본 규칙이 있을 때 규칙의 품질에 대한 잘못된 신뢰가 발생할 수 있으며 프로그래머가 발생할 수 있는 모든 문제와 규칙이 적용되어야 하는 모든 상황을 다루고 있다고 믿게 됩니다. 경우에 따라 규칙을 적용해야 하는 상황은 미묘할 수 있으며 감지하기가 쉽지 않을 수 있습니다.
희망은 정적 분석 도구를 사용하고 규칙과 위반을 자세히 조사함으로써 프로그래머가 특정 도메인의 맥락에서 문제를 감지하고 피할 수있는 기술을 개발할 수 있기를 바랍니다.
도메인에 컨텍스트 규칙이 필요한 경우 정적 분석 도구에는 도메인 또는 라이브러리와 일치하는 규칙이 없을 수 있으며 도구구성 및 확장이 어려울 수 있습니다.
불만
이러한 '성가심'은 극복할 수 없습니다.
- 거짓 긍정
- 수정 사항 부족
- 규칙을 무시하는 구성
- 컨텍스트별 규칙 추가
그러나 정적 분석 도구를 사용하는 것이 매우 유용할 수 있기 때문에 처음에는 정적 분석 도구를 사용하지 않도록 변명으로 자주 사용됩니다.
- 주니어 개발자에게 더 나은 접근 방식을 강조표시
- 명확한 코딩 위반에 대한 빠른 피드백 확보
- 프로그래머가 이전에 발생하지 않은 모호한 문제 식별
- 프로그래머가 좋은 코딩 접근 방식을 채택했다는 것을 강화합니다(위반사항이 보고되지 않은 경우)
IDE 기반 정적 분석 도구
프로젝트의 개별 기여자로서 IDE 내에서 실행되는 정적 분석 도구를 사용하여 코드에 대한 빠른 피드백을 받는 것을 좋아합니다.
이렇게 하면 끌어오기 요청 검토 프로세스와 프로젝트가 가질 수 있는 CI 통합이 보완됩니다.
나는 나에게 우위를 줄 것이다 도구를 식별하고, 내 개별 워크 플로우를 개선하려고합니다.
도구가 IDE에서 실행되는 경우 동일한 기본 GUI 및 구성 접근 방식을 공유하는 경향이 있으므로 도구가 상호 교환방식으로 볼 수 있습니다.
도구는 겹치는 기능 이나 규칙 집합을 가질 수 있지만 최대한의 이점을 얻으려면 그들의 강점을 활용 하기 위해 여러 도구를 설치.
코딩이 아래에 나열될 때 적극적으로 사용하는 정적 분석 IDE 도구는 다음과 같습니다.
- 붙박이 IntelliJ 검사 - 일반적인 코딩 패턴
- 스팟 버그 - 일반적인 오류
- 수중 음파 탐지기 - 일반적인 사용 패턴
- 체크 스타일 - 일반적인 스타일 패턴
- Sensei 보낸 사람 Secure Code Warrior - 사용자 정의 규칙 생성
그들은 서로를 증강 하 고 보충 하기 위해 함께 잘 작동 하기 때문에 그들 모두를 사용.
인텔리제이 검사
IntelliJ를 사용하는 경우 이미 검사를 사용하고 있습니다.
다음은 IDE에 플래그가 지정된 정적 분석 규칙입니다. 그들 중 일부는 또한 문제를 해결하기 위해 코드를 다시 작성하는 QuickFix 옵션이 있습니다.
규칙은 켜고 끌 수 있으며 IDE에서 강조 표시하는 데 사용되는 오류 수준을 선택할 수 있습니다.
좋은 IntelliJ 검사가 많이 있습니다. 나는 이것을 쓰는 동안 그들을 읽었기 때문에 그것을 알고있다. IntelliJ 검사를 기본값으로 사용하고 구성하지 는 않았지만 이를 통해 읽어야 하는 검사에서 전체 값을 얻고 코딩 스타일과 관련된 검사를 식별하고 코드에서 이를 알 수 있도록 경고 수준을 구성합니다.
IntelliJ 검사의 가장 큰 장점은 IDE와 함께 무료로 제공되며 다음과 같은 근육 메모리를 구축하는 데 도움이 된다는 것입니다.
- 코드를 작성할 때 소스에서 경고 및 오류를 알아차리
- 규칙 위반을 알아보려면 플래그가 지정된 코드 위에 마우스를 마우스로 가져가십시오.
- alt+enter를 사용하여 문제에 대한 QuickFix를 적용합니다.
스팟버그
SpotBugs IntelliJ 플러그인은 정적 분석을 사용하여 코드의 버그에 대해 경고합니다.
SpotBugs는 IntelliJ 환경 설정에서 코드를 스캔하도록 구성할 수 있으며, 사용된 실제 규칙은 검출기 탭에서 찾을 수 있습니다.
코드를 작성하고 검토한 후 SpotBugs를 사용하는 경향이 있으며 '테스트 소스를 포함한 프로젝트 파일 분석'을 실행합니다.
이렇게 하면 버그, 데드 코드 및 명백한 최적화를 식별하는 데 도움이 됩니다. 또한 신고된 위반 사항 중 일부를 조사하여 무엇을 해야 할지 결정하도록 강요합니다.
SpotBugs는 문제를 찾을 수 있지만 문제를 해결하기 위한 QuickFix 작업을 제공하지는 않습니다.
SpotBugs는 구성하기 쉽고 IDE에서 상담하는 데 유용한 객관적인 두 번째 의견이 될 수 있습니다.
수나린트
수나린트 플러그인.
SonarLint는 IntelliJ 환경 설정에서 구성하여 코드의 유효성을 검사하는 규칙을 선택할 수 있습니다.
기본적으로 SonarLint는 실시간으로 실행되며 편집중인 현재 코드에 대한 문제를 표시합니다.
SonarLint는 빠른 수정 사항을 제공하지 않지만 위반 보고서와 관련된 문서는 일반적으로 명확하고 잘 문서화되어 있습니다.
나는 내가 자바의 최신 버전에서 알고 있던 새로운 자바 기능에 저를 경고하기 위해 과거에 유용 할 수 SonarLint를 발견했습니다.
체크스타일
CheckStyle 플러그인은 서식 및 코드 품질 규칙의 혼합을 제공합니다.
체크 스타일 플러그인은 '태양 검사'와 '구글 체크'와 함께 번들로 제공됩니다.
이러한 정의는 쉽게 온라인으로 찾을수 있습니다.
CheckStyle은 프로젝트가 자체 규칙 집합을 만드는 데 시간을 할애할 때 가장 많은 가치를 추가합니다. 그런 다음 IDE 플러그인을 구성하여 CI에 코드를 커밋하기 전에 해당 규칙 집합을 사용하도록 구성하고 프로그래머가 스캔을 수행할 수 있습니다.
CheckStyle은 CheckStyle 위반 횟수가 임계값을 초과할 때 CI 프로세스에 대한 빌드 실패 플러그인으로 매우 자주 사용됩니다.
Sensei
Sensei 코드를 일치시키고 QuickFixs를 만들기 위해 추상 구문 트리(AST)를 기반으로 정적 분석을 사용하면 문제가 있는 코드를 매우 구체적으로 식별할 수 있습니다.
AST를 사용하면 레시피와 연결된 QuickFixs가 코드에 새 클래스를 추가할 때와 같이 주변 코드를 이해할 수 있으며 해당 클래스에 대한 가져오기는 각 교체가 아닌 소스 파일에 한 번만 추가됩니다.
Sensei 존재하지 않거나 다른 도구에서 구성하기 어려운 사용자 지정 일치 규칙을 쉽게 빌드할 수 있도록 만들어졌습니다.
구성 파일을 수정하는 대신 GUI에서 모든 구성을 수행할 수 있습니다. 새로운 레시피를 만들 때 GUI를 사용하면 레시피가 일치하는 코드를 쉽게 확인할 수 있습니다. 그리고 QuickFixes를 정의할 때 코드의 전후 상태를 즉시 비교할 수 있습니다. 이를 통해 팀, 기술, 심지어 개별 프로그래머에 고유한 매우 맥락적인 레시피를 쉽게 만들 수 있습니다.
사용 Sensei 대부분의 정적 분석 도구와 같은 다른 정적 분석 도구와 함께 문제를 발견하지만 해결하지는 않습니다. 일반적인 사용 사례 Sensei 다른 도구의 일치하는 검색을 복제하는 것입니다. Sensei 빠른 수정으로 확장합니다. 이렇게 하면 적용된 사용자 지정 수정 프로그램이 프로젝트의 코딩 표준을 이미 충족한다는 이점이 있습니다.
나는 주기적으로 자신을 만드는 찾을 수 Sensei IntelliJ Intensions 세트에 이미 존재하는 조리법은 Intension 보고서가 내가 만든 컨텍스트와 잘 맞지 않거나 IntelliJ에서 제공하는 QuickFix가 사용하려는 코드 패턴과 일치하지 않기 때문입니다.
기존 도구를 완전히 교체하는 대신 보강합니다.
Sensei 정적 분석 도구에서 지원되지 않는 SQL 라이브러리를 사용하는 경우와 같은 공통 규칙의 컨텍스트 변형을 식별할 때도 매우 유용할 수 있지만 정적 분석 엔진의 일반적인 SQL 규칙은 여전히 적용되며 이러한 규칙의 라이브러리 별 변형을 만들 수 있습니다. Sensei .
Sensei 언급 된 정적 분석 도구와 같은 일반적인 조리법이 많이있는 상자에서 나오지 않으며, 그 강도는 특정 코딩 스타일과 사용 사례에 맞게 구성된 QuickFixs로 완성 된 새로운 레시피를 쉽게 만들 수 있도록하는 것입니다.
참고 : 우리는 일반적인 사용 사례를 커버하기 위해 조리법의 공개 저장소에 노력하고 있습니다, 당신은 여기에서 찾을 수 있습니다.
요약
저는 함께 작업하고 구성할 수 있으며 특정 컨텍스트를 충족하기 위해 확장하기 쉬운 도구를 선택하는 경향이 있습니다. 수년 동안 IDE에서 정적 분석 도구를 사용하여 문제를 식별하고 사용하는 프로그래밍 언어 및 라이브러리에 대해 자세히 알아보세요.
나는 조합에 언급 된 모든 도구를 사용합니다 :
- IntelliJ 의도는 종종 연결된 QuickFixs와 함께 일반적인 코드 문제를 상자에 플래그를 표시하는 데 도움이 됩니다.
- SpotBugs 내가 놓친 수 있습니다 간단한 버그를 찾아 성능 문제에 저를 경고.
- SonarLint는 내가 알지 못했던 Java 기능을 식별하고 코드를 모델링하는 추가 방법을 안내합니다.
- CheckStyle은 CI 중에 적용되는 합의된 코딩 스타일을 준수하는 데 도움이 됩니다.
- Sensei 정적 분석 도구에서 찾은 일반적인 시나리오를 보강하고 다른 도구에서 구성하기 어려운 특정 프로젝트 또는 기술 레시피를 만드는 QuickFixes를 만드는 데 도움이 됩니다.
---
설치하다 Sensei "환경 설정 \ 플러그인"(맥) 또는 "설정 \ 플러그인"(윈도우)를 사용하여 IntelliJ 내에서 다음 그냥 검색 " sensei 보안 코드".
예제 코드 및 일반적인 사용 사례에 대한 레시피의 저장소를 찾을 수 있습니다. Secure Code Warrior GitHub 계정, ' sensei - 블로그 예제 '프로젝트.
https://github.com/securecodewarrior/sensei-blog-examples
앨런 리처드슨
블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.
Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.
개발자 중심 보안에 대한 최신 연구 보기
광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.
정적 분석은 무엇입니까?
정적 분석은 무엇입니까?
정적 분석은 응용 프로그램을 실행하지 않고 소스 코드의 자동화 된 분석입니다.
프로그램 실행 중에 분석이 수행되면 동적 해석이라고 합니다.
정적 분석은 종종 다음을 감지하는 데 사용됩니다.
- 보안 취약점.
- 성능 문제.
- 표준을 준수하지 않습니다.
- 오래된 프로그래밍 구문 사용.
정적 분석 도구는 어떻게 작동합니까?
모든 정적 분석 도구에 공통적인 기본 개념은 소스 코드를 검색하여 일종의 경고 또는 정보와 관련된 특정 코딩 패턴을 식별하는 것입니다.
"JUnit 5 테스트 클래스는 '공개'가 될 필요가 없습니다"만큼 간단할 수 있습니다. 또는 "SQL 실행 문에서 사용되는 신뢰할 수 없는 문자열 입력"과 같은 식별하기 가 복잡한 것입니다.
정적 분석 도구는 이 기능을 구현하는 방법에 따라 다릅니다.
- 추상구트리(AST)를 만드는 소스 코드 구문 분석 기술
- 텍스트 정규 식 일치,
- 위의 조합.
텍스트의 정규 식 일치는 매우 유연하고 일치하는 규칙을 작성하기 쉽지만 많은 거짓 긍정으로 이어질 수 있으며 일치하는 규칙은 주변 코드 컨텍스트에 대해 무지합니다.
AST 일치는 소스 코드를 프로그램 코드로 취급하며 텍스트로 채워진 파일뿐만 아니라 보다 구체적이고 상황에 맞는 일치를 허용하며 코드에 대해 보고된 거짓 긍정 의 수를 줄일 수 있습니다.
연속 통합의 정적 분석
정적 분석은 CI(연속 통합) 프로세스 중에 수행되어 시간이 지남에 따라 코드 베이스에 대한 객관적인 보기를 수신하도록 검토할 수 있는 규정 준수 문제에 대한 보고서를 생성하는 경우가 많습니다.
어떤 사람들은 정적 분석 도구를 구성하여 코드의 특정 부분만 측정하고 규칙 하위 집합에 대해서만 보고하여 정적 분석을 코드 품질의 객관적인 척도로 사용합니다.
객관성은 시간이 지남에 따라 코드 평가에 따라 달라지지 않기 때문에 사용되는 규칙에 의해 제공됩니다. 분명히 사용되는 규칙과 구성의 조합은 주관적인 결정이며 다른 팀은 서로 다른 시간에 다른 규칙을 사용하기로 결정합니다.
CI에서 정적 분석을 수행하는 것은 유용하지만 프로그래머의 피드백을 지연시킬 수 있습니다. 프로그래머는 코딩할 때 피드백을 받지 않으며 나중에 정적 분석 도구를 통해 코드를 실행할 때 피드백을 받습니다. CI에서 정적 분석을 실행하는 또 다른 부작용은 결과를 무시하기가 쉽다는 것입니다.
팀이 정적 분석의 결과에 더 많은 주의를 기울이도록 하려면 일반적으로 메트릭이 트리거된 여러 규칙과 같은 메트릭을 초과하면 빌드 프로세스에서 임계값 메트릭을 구성하여 빌드에 실패하도록 구성할 수 있습니다.
IDE의 정적 분석
피드백을 더 빨리 받으려면 주문형 IDE에서 정적 분석 규칙을 실행하거나 코드가 변경될 때 주기적으로 실행되는 많은 IDE 플러그인이 있습니다.
그런 다음 프로그래머가 코드를 작성할 때 IDE에서 규칙 위반을 볼 수 있으며 규칙을 무시하기 어렵게 만들려면 편집기에서 밑줄이 표시된 코드로 렌더링하도록 위반을 구성할 수 있습니다.
나는 개인적으로 이것이 내 코딩을 개선하는 유용한 방법을 찾을 수 있습니다, 특히 정적 분석 도구에 의해 덮여 새로운 라이브러리로 작업 할 때. 그것은 거짓 긍정과 '시끄러운'수 있지만, 또는 규칙에 관심이 없습니다. 그러나 이는 특정 규칙을 무시하도록 정적 분석 도구를 구성하는 추가 단계를 사용하여 해결됩니다.
정적 분석 규칙에 따라 코드 수정
대부분의 정적 분석 도구를 사용하면 규칙 수정이 프로그래머에게 남아 있으므로 규칙 위반의 원인과 규칙을 수정하는 방법을 이해해야 합니다.
수정이 팀에 매우 자주 컨텍스트가 되고 사용된 기술과 합의된 코딩 스타일에 따라 위반을 해결할 수 있는 기능도 포함되는 정적 분석 도구도 거의 없습니다.
기본 규칙
정적 분석 도구에 기본 규칙이 있을 때 규칙의 품질에 대한 잘못된 신뢰가 발생할 수 있으며 프로그래머가 발생할 수 있는 모든 문제와 규칙이 적용되어야 하는 모든 상황을 다루고 있다고 믿게 됩니다. 경우에 따라 규칙을 적용해야 하는 상황은 미묘할 수 있으며 감지하기가 쉽지 않을 수 있습니다.
희망은 정적 분석 도구를 사용하고 규칙과 위반을 자세히 조사함으로써 프로그래머가 특정 도메인의 맥락에서 문제를 감지하고 피할 수있는 기술을 개발할 수 있기를 바랍니다.
도메인에 컨텍스트 규칙이 필요한 경우 정적 분석 도구에는 도메인 또는 라이브러리와 일치하는 규칙이 없을 수 있으며 도구구성 및 확장이 어려울 수 있습니다.
불만
이러한 '성가심'은 극복할 수 없습니다.
- 거짓 긍정
- 수정 사항 부족
- 규칙을 무시하는 구성
- 컨텍스트별 규칙 추가
그러나 정적 분석 도구를 사용하는 것이 매우 유용할 수 있기 때문에 처음에는 정적 분석 도구를 사용하지 않도록 변명으로 자주 사용됩니다.
- 주니어 개발자에게 더 나은 접근 방식을 강조표시
- 명확한 코딩 위반에 대한 빠른 피드백 확보
- 프로그래머가 이전에 발생하지 않은 모호한 문제 식별
- 프로그래머가 좋은 코딩 접근 방식을 채택했다는 것을 강화합니다(위반사항이 보고되지 않은 경우)
IDE 기반 정적 분석 도구
프로젝트의 개별 기여자로서 IDE 내에서 실행되는 정적 분석 도구를 사용하여 코드에 대한 빠른 피드백을 받는 것을 좋아합니다.
이렇게 하면 끌어오기 요청 검토 프로세스와 프로젝트가 가질 수 있는 CI 통합이 보완됩니다.
나는 나에게 우위를 줄 것이다 도구를 식별하고, 내 개별 워크 플로우를 개선하려고합니다.
도구가 IDE에서 실행되는 경우 동일한 기본 GUI 및 구성 접근 방식을 공유하는 경향이 있으므로 도구가 상호 교환방식으로 볼 수 있습니다.
도구는 겹치는 기능 이나 규칙 집합을 가질 수 있지만 최대한의 이점을 얻으려면 그들의 강점을 활용 하기 위해 여러 도구를 설치.
코딩이 아래에 나열될 때 적극적으로 사용하는 정적 분석 IDE 도구는 다음과 같습니다.
- 붙박이 IntelliJ 검사 - 일반적인 코딩 패턴
- 스팟 버그 - 일반적인 오류
- 수중 음파 탐지기 - 일반적인 사용 패턴
- 체크 스타일 - 일반적인 스타일 패턴
- Sensei 보낸 사람 Secure Code Warrior - 사용자 정의 규칙 생성
그들은 서로를 증강 하 고 보충 하기 위해 함께 잘 작동 하기 때문에 그들 모두를 사용.
인텔리제이 검사
IntelliJ를 사용하는 경우 이미 검사를 사용하고 있습니다.
다음은 IDE에 플래그가 지정된 정적 분석 규칙입니다. 그들 중 일부는 또한 문제를 해결하기 위해 코드를 다시 작성하는 QuickFix 옵션이 있습니다.
규칙은 켜고 끌 수 있으며 IDE에서 강조 표시하는 데 사용되는 오류 수준을 선택할 수 있습니다.
좋은 IntelliJ 검사가 많이 있습니다. 나는 이것을 쓰는 동안 그들을 읽었기 때문에 그것을 알고있다. IntelliJ 검사를 기본값으로 사용하고 구성하지 는 않았지만 이를 통해 읽어야 하는 검사에서 전체 값을 얻고 코딩 스타일과 관련된 검사를 식별하고 코드에서 이를 알 수 있도록 경고 수준을 구성합니다.
IntelliJ 검사의 가장 큰 장점은 IDE와 함께 무료로 제공되며 다음과 같은 근육 메모리를 구축하는 데 도움이 된다는 것입니다.
- 코드를 작성할 때 소스에서 경고 및 오류를 알아차리
- 규칙 위반을 알아보려면 플래그가 지정된 코드 위에 마우스를 마우스로 가져가십시오.
- alt+enter를 사용하여 문제에 대한 QuickFix를 적용합니다.
스팟버그
SpotBugs IntelliJ 플러그인은 정적 분석을 사용하여 코드의 버그에 대해 경고합니다.
SpotBugs는 IntelliJ 환경 설정에서 코드를 스캔하도록 구성할 수 있으며, 사용된 실제 규칙은 검출기 탭에서 찾을 수 있습니다.
코드를 작성하고 검토한 후 SpotBugs를 사용하는 경향이 있으며 '테스트 소스를 포함한 프로젝트 파일 분석'을 실행합니다.
이렇게 하면 버그, 데드 코드 및 명백한 최적화를 식별하는 데 도움이 됩니다. 또한 신고된 위반 사항 중 일부를 조사하여 무엇을 해야 할지 결정하도록 강요합니다.
SpotBugs는 문제를 찾을 수 있지만 문제를 해결하기 위한 QuickFix 작업을 제공하지는 않습니다.
SpotBugs는 구성하기 쉽고 IDE에서 상담하는 데 유용한 객관적인 두 번째 의견이 될 수 있습니다.
수나린트
수나린트 플러그인.
SonarLint는 IntelliJ 환경 설정에서 구성하여 코드의 유효성을 검사하는 규칙을 선택할 수 있습니다.
기본적으로 SonarLint는 실시간으로 실행되며 편집중인 현재 코드에 대한 문제를 표시합니다.
SonarLint는 빠른 수정 사항을 제공하지 않지만 위반 보고서와 관련된 문서는 일반적으로 명확하고 잘 문서화되어 있습니다.
나는 내가 자바의 최신 버전에서 알고 있던 새로운 자바 기능에 저를 경고하기 위해 과거에 유용 할 수 SonarLint를 발견했습니다.
체크스타일
CheckStyle 플러그인은 서식 및 코드 품질 규칙의 혼합을 제공합니다.
체크 스타일 플러그인은 '태양 검사'와 '구글 체크'와 함께 번들로 제공됩니다.
이러한 정의는 쉽게 온라인으로 찾을수 있습니다.
CheckStyle은 프로젝트가 자체 규칙 집합을 만드는 데 시간을 할애할 때 가장 많은 가치를 추가합니다. 그런 다음 IDE 플러그인을 구성하여 CI에 코드를 커밋하기 전에 해당 규칙 집합을 사용하도록 구성하고 프로그래머가 스캔을 수행할 수 있습니다.
CheckStyle은 CheckStyle 위반 횟수가 임계값을 초과할 때 CI 프로세스에 대한 빌드 실패 플러그인으로 매우 자주 사용됩니다.
Sensei
Sensei 코드를 일치시키고 QuickFixs를 만들기 위해 추상 구문 트리(AST)를 기반으로 정적 분석을 사용하면 문제가 있는 코드를 매우 구체적으로 식별할 수 있습니다.
AST를 사용하면 레시피와 연결된 QuickFixs가 코드에 새 클래스를 추가할 때와 같이 주변 코드를 이해할 수 있으며 해당 클래스에 대한 가져오기는 각 교체가 아닌 소스 파일에 한 번만 추가됩니다.
Sensei 존재하지 않거나 다른 도구에서 구성하기 어려운 사용자 지정 일치 규칙을 쉽게 빌드할 수 있도록 만들어졌습니다.
구성 파일을 수정하는 대신 GUI에서 모든 구성을 수행할 수 있습니다. 새로운 레시피를 만들 때 GUI를 사용하면 레시피가 일치하는 코드를 쉽게 확인할 수 있습니다. 그리고 QuickFixes를 정의할 때 코드의 전후 상태를 즉시 비교할 수 있습니다. 이를 통해 팀, 기술, 심지어 개별 프로그래머에 고유한 매우 맥락적인 레시피를 쉽게 만들 수 있습니다.
사용 Sensei 대부분의 정적 분석 도구와 같은 다른 정적 분석 도구와 함께 문제를 발견하지만 해결하지는 않습니다. 일반적인 사용 사례 Sensei 다른 도구의 일치하는 검색을 복제하는 것입니다. Sensei 빠른 수정으로 확장합니다. 이렇게 하면 적용된 사용자 지정 수정 프로그램이 프로젝트의 코딩 표준을 이미 충족한다는 이점이 있습니다.
나는 주기적으로 자신을 만드는 찾을 수 Sensei IntelliJ Intensions 세트에 이미 존재하는 조리법은 Intension 보고서가 내가 만든 컨텍스트와 잘 맞지 않거나 IntelliJ에서 제공하는 QuickFix가 사용하려는 코드 패턴과 일치하지 않기 때문입니다.
기존 도구를 완전히 교체하는 대신 보강합니다.
Sensei 정적 분석 도구에서 지원되지 않는 SQL 라이브러리를 사용하는 경우와 같은 공통 규칙의 컨텍스트 변형을 식별할 때도 매우 유용할 수 있지만 정적 분석 엔진의 일반적인 SQL 규칙은 여전히 적용되며 이러한 규칙의 라이브러리 별 변형을 만들 수 있습니다. Sensei .
Sensei 언급 된 정적 분석 도구와 같은 일반적인 조리법이 많이있는 상자에서 나오지 않으며, 그 강도는 특정 코딩 스타일과 사용 사례에 맞게 구성된 QuickFixs로 완성 된 새로운 레시피를 쉽게 만들 수 있도록하는 것입니다.
참고 : 우리는 일반적인 사용 사례를 커버하기 위해 조리법의 공개 저장소에 노력하고 있습니다, 당신은 여기에서 찾을 수 있습니다.
요약
저는 함께 작업하고 구성할 수 있으며 특정 컨텍스트를 충족하기 위해 확장하기 쉬운 도구를 선택하는 경향이 있습니다. 수년 동안 IDE에서 정적 분석 도구를 사용하여 문제를 식별하고 사용하는 프로그래밍 언어 및 라이브러리에 대해 자세히 알아보세요.
나는 조합에 언급 된 모든 도구를 사용합니다 :
- IntelliJ 의도는 종종 연결된 QuickFixs와 함께 일반적인 코드 문제를 상자에 플래그를 표시하는 데 도움이 됩니다.
- SpotBugs 내가 놓친 수 있습니다 간단한 버그를 찾아 성능 문제에 저를 경고.
- SonarLint는 내가 알지 못했던 Java 기능을 식별하고 코드를 모델링하는 추가 방법을 안내합니다.
- CheckStyle은 CI 중에 적용되는 합의된 코딩 스타일을 준수하는 데 도움이 됩니다.
- Sensei 정적 분석 도구에서 찾은 일반적인 시나리오를 보강하고 다른 도구에서 구성하기 어려운 특정 프로젝트 또는 기술 레시피를 만드는 QuickFixes를 만드는 데 도움이 됩니다.
---
설치하다 Sensei "환경 설정 \ 플러그인"(맥) 또는 "설정 \ 플러그인"(윈도우)를 사용하여 IntelliJ 내에서 다음 그냥 검색 " sensei 보안 코드".
예제 코드 및 일반적인 사용 사례에 대한 레시피의 저장소를 찾을 수 있습니다. Secure Code Warrior GitHub 계정, ' sensei - 블로그 예제 '프로젝트.
https://github.com/securecodewarrior/sensei-blog-examples
