Java에서 클래스를 개발 중으로 플래그 지정하는 방법

인턴쉽 프로젝트를 진행 중이지만 모든 것을 마치려면 떠나야합니다.

프로덕션 용도로 충분히 안정적이지 않은 1 개의 클래스가 있습니다. 다른 사람들이 실수로 프로덕션에서 사용하지 않도록이 클래스를 표시 / 플래그 지정하고 싶습니다. 이미 Javadoc에 통지를했지만 충분하지 않습니다. 일부 컴파일러 오류 또는 경고가 더 좋습니다.

코드는 다음과 같이 구성됩니다.

[Package] | company.foo.bar.myproject
          |-- Class1.java
          |-- Class2.java
          |-- Class3.java <--(not stable)

공용 메소드에서 해당 클래스를 호출하는 단일 팩토리 클래스가 있으면 메소드를 class3로 설정할 수 있습니다 private. 그러나 API는 그런 식으로 노출되지 않습니다. 예를 들어 사용자는 해당 클래스를 직접 사용 new Class1();하지만 최상위 클래스를 비공개로 만들 수는 없습니다. 이 상황을 다루는 가장 좋은 방법은 무엇입니까?

왜 모든 불안정한 클래스를 버전 제어 시스템의 다른 분기로 검사하지 않습니까?

클래스에 올바르게 주석을 달았다면 불완전한 기능의 비트를 "더 이상 사용되지 않음"으로 표시하거나 메소드의 장을 주석 처리하고를 넣을 수 throw new UnsupportedOperationException();있습니다.

Java에 .NET의 NotImplementedException과 같은 것이 있습니까?를 참조하십시오 . 자세한 내용은.

나는 그러한 컴파일러 경고를 모른다.

귀하의 상황에서 아마도 @Deprecated주석을 사용할 것입니다 . 메소드 호출을 건너 뛰므로 다른 사람들에게 무언가가 일어나고 있음이 분명합니다. 그들이 무슨 일이 일어 났는지 볼 때, 그들은 '생산 준비 안 됨'에 대한 당신의 의견을보고 AHA에 갈 것입니다.

나는 같은 코드를 표시하는 표준 방법이 생각하지 않는다 WIP, Incomplete그런, 또는 뭔가.

이름이 지정된 새 예외 ClassUnstableException를 만든 다음 Class3이를 사용해서는 안되는 방법을 설명하는 메시지와 함께 생성자 에서 발생시킬 수 있습니다 . 런타임에만 경고하기 때문에 이것은 나쁘다.

어떤 방식으로 클래스를 컴파일 할 수 없게 만든 다음 컴파일러를 트립하는 코드 섹션에 메모를 추가하여 누군가가 코드를 수정하려고하면 해당 클래스를 사용하지 않아야하는 이유에 대한 설명을 희망적으로 볼 수 있습니다 . 일부 IDE에있는 일부 반자동 "이 문제 수정"도구를 사용하면 작동하지 않을 수 있습니다. 빌드를 깨뜨릴 수 있기 때문에 나쁘다.

당신은라는 주석을 만들 수 있습니다 WIP(가장 가까운 이후는 생각할 수 Deprecated있지만, 정말 같은 일을 의미하지 않는다) 및 클래스에 주석을 사용하십시오. 이것은 아마도 더 많은 작업 일 것이므로 주석을 지원하는 것은 무엇입니까?

마지막으로 주석에 넣을 수는 있지만 사람들이 실제로 읽은 경우에만 작동 합니다.

편집하다:

:이 관련이있을 수 의도적으로 사용자 정의 자바 컴파일러 경고 메시지를 야기하는 방법?

왜 처음에 있습니까?

불안정한 코드를 메인 라인에 체크인 했습니까? 왜?

불안정한 코드는 트렁크 / 메인 / 마스터 또는 주요 트렁크 이름으로 체크인해서는 안됩니다. 이것은 위험이 높은 것으로 간주되며 대신 메인으로 체크인하기보다는 작업 한 자체 지점에서 격리되어야합니다.

Advanced SCM Branching Strategies 를 읽어 보시기 바랍니다 . 특히, 개발 역할과 고위험 개발로 간주되는 사항에 대해 설명하는 내용에주의하십시오.

일반적으로 위험이 높은 각 프로젝트마다 별도의 지점을 사용하는 것이 좋습니다. 고위험 프로젝트는 대규모, 많은 인원, 익숙하지 않은 주제, 고도의 기술 주제, 매우 긴 일정, 불확실한 납기일, 불완전하거나 변동이 심한 요구 사항 및 지리적으로 분산 된 프로젝트 팀이 특징입니다. 마찬가지로 각 릴리스에서 저 위험 개발을위한 단일 지점을 지정하는 것이 좋습니다. [WING98]을 포함한 여러 출처에서이 목적으로 메인 라인을 사용하는 것이 좋습니다. 이 조치를 취하기 전에 메인 라인에 대해 위에서 논의한 요소를 고려하십시오. 메인 라인을 통해 조정하는 제품군의 여러 구성원이 있더라도 저 위험 개발은 메인 라인과 다른 정책을 가질 수 있습니다.

사람들이 불안정하거나 사용하지 않는 코드를 메인 라인에 체크인하게하면이 코드를 유지하려는 노력에 대한 향후 개발 노력을 혼동하게됩니다. 지금부터 끝까지 모든 담당자의 복제본과 복제본에는 누군가가 "죽은 대구"라고 말하고 삭제할 때까지이를 포함합니다.

"글쎄, 지점에 있으면 잊어 버린다"는 말이 있지만 사실 일 수도 있지만 메인 라인에서 죽은 (불안정한) 코드를 잊어 버리면 향후 개발이 모두 제거 될 때까지 혼란스럽게되므로 여러 번 더 나빠집니다. 그때는 더 잊혀졌습니다. "/ fooProject / branches / WeisBigIdea"(또는 이와 동등한 것)라는 이름이 좋은 브랜치는 볼 수 있고 앞으로 작업하기가 더 쉽습니다. 특히 작동하는 경우 특히 그렇습니다.

@Deprecated

첫 번째는 @Deprecated주석입니다. 이것은 javadoc을 넘어 컴파일러 경고를 뱉어냅니다. 다음과 같이 설명 javac된 -deprecation플래그를 제공합니다 .

더 이상 사용되지 않는 멤버 또는 클래스의 각 사용 또는 재정의에 대한 설명을 표시하십시오. 이 없으면 -deprecation, javac더 이상 사용되지 않는 멤버 또는 클래스를 사용하거나 재정의하는 소스 파일의 요약을 표시합니다. -deprecation은 축약 형입니다 -Xlint:deprecation.

언급 한 바와 같이, 이것은 표준 컴파일러 경고 이상의 것입니다.

많은 IDE에서 더 이상 사용되지 않는 메소드와 값이 취소 선으로 표시됩니다.

foo.bar();

그리고 다음과 같은 출력을 생성합니다.

$ javac -Xlint:all Foo.java Bar.java
Bar.java:2: warning: [deprecation] Foo in unnamed package has been deprecated
interface Bar extends Foo { }
                      ^

빌드 구조에 따라 빌드가 중단되었다는 경고가 표시 될 수 있습니다. 이 것 에만 수업 중 하나가 (이 단지에 컴파일되지 않은 경우) 사용 된 경우 빌드를 휴식.

@CustomAnnotation

이에 대한 많은 접근 방식이 있습니다. 예를 들어, 경량 javac @Warning 주석은 해당 주석이있는 것을 사용할 때 컴파일 타임에 경고를 발생시키는 주석 프로세서를 제공합니다 ( 맞춤 주석 프로세서에 대한 netbeans 자습서 이므로 장면).

오라클 은 Java 메타 데이터 최대한 활용, 2 부 : 사용자 정의 주석@Unfinished 에서 주석에 사용자 정의 주석을 사용하는 예를 설명합니다 .

AnnotationProcessor를 사용하면 컴파일 타임에 임의의 코드를 실행할 수 있습니다. 당신이 원하는 것을 결정하는 것은 당신에게 달려 있습니다. 경고, 무언가가 사용되면 빌드를 중단하십시오. 웹에는 이러한 종류의 코드를 작성하는 방법에 대한 많은 자습서가 있습니다. 컴파일 할 때 오류가 발생하는지 (이것은 성 가시고 삭제 될 수 있습니다) 또는 사용 된 경우 (조금 더 복잡합니다).

이 모든 것은 실제로 주석 프로세서를 사용하도록 빌드를 변경 함을 의미합니다.

당신은 할 수 소개 컴파일시 주석 처리를 하지만, 이것은 자신의 컴파일 과정을 조정하기 위해 팀의 모든 구성원을 적용 할 것입니다.

그러나 전체 프로세스가 약간 혼란 스럽습니다. 버전 제어 시스템에서 분기를 작성하여 불안정한 API를 명확하게 분리해야합니다. 그것이 실제로 코드베이스의 나머지 부분에 있어야하고 불안정한 것으로 문서화되었지만 그럼에도 불구하고 문제는 실제로 기술적 인 것이 아니라 조직과 커뮤니케이션에 있습니다. 예, 주석 처리와 같은 기술 검증을 도입 할 수는 있지만 문제가 해결되지는 않습니다. 다른 수준으로 옮기십시오.

따라서 권장 사항은 다음과 같습니다. 코드 분기를 다른 분기에 배치하여 코드베이스를 분리 할 수없는 경우 사람들에게 이야기 하고 API를 사용하지 않아야 하는 이유 를 설명 하십시오.

불완전한 모든 클래스를 "NOTCOMPLETE"와 같은 이름의 하위 패키지로 옮길 수 있습니까? 그것은 약간의 해킹이지만 충분히 보일 수 있습니다.

(모두 동일한 패키지에 있지 않은 경우 패키지 구조를 다시 만들 수 있습니다.)

코드 에서이 작업을 수행하는 좋은 방법이 있는지 모르겠습니다. 한발 물러서십시오 :

전체 프로젝트의 사본 두 개 (클래스가있는 파일과없는 파일)를 만듭니다. 클래스가없는 버전을 안정적인 코드베이스로, 프로덕션 릴리스 준비가 완료되고, 클래스가있는 버전은 향후 릴리스의 개발로 표시하십시오. 이 클래스가 프로덕션 품질로 간주되기 전에 수행해야 할 사항을 문서화하십시오.

이상적으로는 선택한 소스 제어 솔루션에서 분기를 사용하여이 작업을 수행해야합니다. 그런 브랜치 전략을 사용하지 않은 것처럼 들리므로 속임수를 사용해야 할 수도 있습니다. 새 클래스를 조심스럽게 제거하고 클래스가없는 버전을 체크인 한 후 회귀 테스트를 수행하십시오. 만족 스러우면 개정판에 태그를 지정하고 태그에서 개발 분기를 만든 다음 개발 분기에 클래스를 다시 추가 할 수 있습니다.

나는 클래스 추상을 만들고 적절하게 주석을 달기를 선택했다. 그런 식으로 코드는 여전히 참조 용이지만 인스턴스화하려고하는 사람에게는 행운이있다. :)

컴파일러가 해결할 수없는 종속성을 만드는 것은 어떻습니까? 다음을 추가하십시오.

이 가져 오기를 수행하지 마십시오.

상단에. 사용자는 컴파일 할 수 없습니다.

클래스를 테스트하려면 해당 이름으로 패키지 / 클래스를 만들거나 "experimental.danger"와 같은 더 간단한 클래스를 사용하면 새 코드를 테스트 할 수 있습니다.