단편 소설. 누군가 내가 참여한 프로젝트에서 다른 DLL의 다른 클래스 멤버에 액세스하기 위해 리플렉션을 사용하기로 결정했습니다. 왜? 게으름. 파일을 체크인하기 전에 모든 Resharper 경고를 제거하는 좋은 (나쁜?) 습관이 있습니다. 어느 날, 내가 속한 수업에서 아무데도 사용되지 않는 개인 회원을 보았습니다. 그래서 shift + delete를 클릭하고 멤버가 없어졌습니다. 두 달 후, 우리의 생산 사이트 중 한 곳의 쇼 스트 스토퍼. 문제가 리플렉션 코드가 개인 멤버를 찾지 못해서 코드를 래핑하는 것이 충분하지 못하다는 사실을 발견 한 지 1 주일이 걸렸습니다. 자동 테스트에 포함되지 않은 시나리오이기도합니다.리플렉션을 사용하여 개인 회원에 액세스
이러한 유스 케이스에 대한 규칙을 설정할 수있는 곳을 권장하는 코드 분석 도구는 무엇입니까?
감사
사물의 DLL 측에서이 테스트 할 수있는 방법이 없기 때문에 어떤 도구가 없습니다.
일부 메서드를 유지하는 이유는 공개이고 일부 메서드는 비공개이므로 DLL을 사용하는 사람들이 사용할 수있는 게시 된 계약서를 가질 수 있습니다. DLL에서 내부적으로 수행하는 작업은 아무도 알지 못하거나 발생하는 상황에 대해 신경을 쓰지 않아야하는 블랙 박스 여야합니다.
"테스트"하는 유일한 방법은 호출자 측에서 리플렉션을 사용하는 모든 기능에 대해 표준 단위 테스트를 작성하는 것입니다. 그런 다음 DLL의 출하 버전이 유닛 테스트를 수행 한 버전과 일치하는지 확인해야합니다.
반성을 사용하는 사람은 자신의 이유를 정당화하고, 그렇지 않은 경우에는 그가 제출 한 모든 코드가 집행되기 전에 더 철저히 검토하도록 요구하는 유예 기간을 거치게합니다. 이런 식으로 (리플렉션을 사용해서는 안됩니다. 리플렉션을 사용하여 코드를 테스트해야합니다. ) 그는 해고되어야합니다..
이것은 내가 지금까지 읽은 최고의 대답입니다. 그리고, 당신도 100 % 정확합니다. – Brian
방금 아이디어를 주셨습니다. 우리는 프로그래머가 .NET 리플렉션 API로 작업하는 것을 제한 할 수 있다고 생각합니다. 대신 리플렉션 코드 용 프록시 API를 만들고 프록시 API에서 사용되는 특정 호출에 따라 자동 생성 된 테스트를 구현할 수 있습니다. –
두 번째 질문은 주관적이며이 사이트의 주제와 관련이 없으므로 질문에서 제거하십시오. –
답변 : 프로덕션 코드에서 개인 멤버에 액세스하기 위해 리플렉션을 사용하는 바보를 해고하십시오. 그가 이미 해고 되었다면, 그의 잔디밭에서 똥을 내라. –
@JonathonReinhart - 흥미로운 제안입니다. 또한 OP 대신 다음과 같이 지시해야합니다. 사람들이 사적 방법을 사용하기 위해 리플렉션을 사용해야하는 주요 이유는 필요한 기능을 노출하는 API 공급자를 거부하는 것입니다. 그래서 DLL이 더 유용한 완전한 API를 제공하는 것을 피하기 위해서 ... –