Sensei 프로젝트 자체에는 시간이 지남에 따라 구축 된 자체 조리법 세트가 있습니다. 이 블로그 게시물은 시나리오 중 하나의 예입니다. Sensei 팀은 레시피를 만들었습니다. Guice의 잘못된 구성으로 인해 테스트 중에 런타임에 NullPointer예외가 보고되었습니다.

이는 코드가 구문적으로 올바른 많은 종속성 주입 시나리오에 일반화될 수 있지만 배선 구성이 올바르지 않아 오류가 미끄러집니다.

이것은 종종 우리가 기술을 배우고있을 때 발생하며, 우리는 물건을 연결하는 것을 잊어 버리는 단순한 실수를 계속합니다. 그러나 이것은 또한 경험이 풍부한 전문가에게 일어나기 때문에, 잘 ... 우리 모두는 실수를 하고, 모든 것을 커버할 단위 테스트가 없을 수도 있습니다.

잘못된 종속성 주입 배선에서 런타임 예외

아래 코드는 NullPointer예외로 런타임에 실패합니다.

‍

injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());

코드는 구문적으로 정확하지만 SystemOutModule 구성에서 요청을 놓쳤기 때문에 실패합니다.

‍

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
    }
}

인젝터를 사용하여 만든 리포터를 사용하려고 할 때 완전히 인스턴스화되지 않았으며 보고를 호출할 때 NullPointer예외를 받습니다.

코드 검토에서 이를 놓쳤거나 종속성 주입을 트리거하는 단위 테스트가 없었고 빌드로 미끄러질 수 있습니다.

‍

경고 표시

이 경우 경고 표지판이 있으며 CountReporter에는 @Inject 인가가 아닌 정적 필드가 있습니다. CountReporter 클래스 자체는 패키지 비공개입니다.

복잡한 코드 베이스에서 바인딩을 구성하는 모듈 클래스가 이 작업을 위해 동일한 패키지에 있어야 하기 때문에 코드가 올바르지 않다는 경고 신호일 수 있습니다.

‍

class CountReporter {
    @Inject
    private static ILineReporter reporter;

코드 검토에서 포착했을 수 있는 또 다른 오류는 SystemOutModule 구성 메서드에서 필드를 실제로 바인딩하는 것을 잊어버린 것입니다.

바인더().요청정적 주입(카운트 리포터.class);

우리가 요청을 작성했다면Static주입 코드를 작성한 다음 CountReporter를 사용하려고 할 때 생성 된 구문 오류가 간단한 오류에 대해 경고했을 것입니다.

> '기자. 카운트 리포터는 '기자'에 공개되지 않습니다. 외부 패키지에서 액세스할 수 없습니다.

‍

슬프게. 우리는 잊어 버렸고 코드에는 구문 경고 표시가 없었습니다.

어떻게 할 수 있을까요? Sensei 도움말?

우리는 아마 사용하지 않을 것입니다 Sensei 누락 된 요청을 데리러 모든 Guice 구성 배선이 그 방법을 사용해야하기 때문에Static주입, 우리는 모든 배선이이 사용 사례만큼 간단 할 것이라고 보장 할 수 없습니다.

우리는 Sensei 규칙은 코드가 처음부터 다하지 않다는 몇 가지 경고 표시를 찾아야 합니다.

이 경우 다음을 의미합니다.

• @Inject 인가된 필드가 있는 클래스 찾기
• 클래스가 공개되지 않은 경우입니다.

위의 경고 표시는 유선되지 않았을 것 같지 않다는 경고 신호였습니다.

레시피를 만들면 코딩 중에 경고 표지판이 일찍 발생하고 끌어오기 요청에 대한 의존도를 줄이거나 기술 부채를 해결하여 단위 테스트를 추가할 수 있습니다.

레시피를 만드는 방법?

완료하려는 작업은 다음과 입니다.

• 보호된 개인 클래스에 있는 @Inject 포함된 필드와 일치하는 레시피 만들기

이를 사용하는 모듈을 식별하고 누락된 배선 코드를 추가할 수 있는 충분한 경고를 제공할 수 있기를 바랍니다.

내 CountReporter 클래스에서, 나는 새로운 조리법을 만들기 위해 Alt +Enter를 사용하고 처음부터 시작합니다

이 이름을 지정하고 설명을 추가합니다.

이름: Guice: 주입된 필드 가 공개되지 않음
설명: 주입된 필드가 공개되지 않은 경우 코드가 연결되지 않을 수 있습니다.
수준: 경고

내가 쓰는 검색은 주입으로 추가되었지만 공개로 범위가되지 않은 필드가있는 클래스를 찾습니다.

검색:
밭:
와:
주석:
유형: "com.google.inject.주입"
안으로:
수업:
없이:
수정자: "공개"

수리하다

레시피의 QuickFix는 범위를 변경하여 주입된 클래스를 수정합니다. 그러나 내가 변경해야 하는 유일한 코드는 아닙니다.

사용 가능한 픽스:

- 이름 : "클래스를 공개로 변경합니다. 또한이 클래스에 주입을 요청하는 것을 기억"
작업:
- 체인지수정자:
가시성: "공개"
대상: "부모 클래스"

레시피가 트리거되면 코드에서 수행할 수동 단계가 남아 있어 개체를 완전히 인스턴스화하기 위해 Static주입을 포함하는 줄을 추가합니다.

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
        // instantiate via dependency injection
        binder().requestStaticInjection(CountReporter.class);
    }
}

나는 잠재적으로 이것을 집어 들기 위해 다른 조리법을 쓸 수 있었다. 정적 주입을 추가하는 것을 잊지 않는 한 나는 아마 내가 코딩 할 때 만든 반 정기적 인 오류가되었다.

‍

요약

우리가 공통의 루트 패턴으로 실수를 하는 것을 발견한다면, Sensei 문제를 감지하고 해결하는 것에 대한 지식을 명문화하는 데 도움이 될 수 있으며, 코드 검토를 통해 프로덕션으로 전환되지 않기를 바랍니다.

때로는 우리가 작성하는 조리법은 추론 패턴을 식별 즉, 그들을 일치시키는 것은 문제가 있다는 것을 보장하지 않지만 문제가있을 가능성이 높습니다.

또한, 우리가 작성하는 조리법과 QuickFixs, 완전히 포괄적 일 필요가 없습니다, 그들은 우리가 우리가 이상 복잡하지 않고 문제를 식별하고 해결하는 데 도움이 충분히 좋은해야합니다. 왜냐하면 그들은 지나치게 복잡해질 때 이해하기 가 더 어려워지고 유지보수가 더 어려워지기 때문입니다.

---

설치할 수 있습니다. Sensei "환경 설정 \ 플러그인"(맥) 또는 "설정 \ 플러그인"(윈도우)를 사용하여 IntelliJ 내에서 다음 그냥 검색 " sensei 보안 코드".

이 게시물의 소스 코드 및 레시피는 '에서 찾을 수 있습니다. sensei -블로그 예제의 리포지토리는 Secure Code Warrior GitHub 계정, 'guiceexamples' 모듈에서.

https://github.com/securecodewarrior/sensei-blog-examples

자세히 알아보기 Sensei