PHPStorm으로 라라벨 개발을 하던중에 만들어보고싶은 플러그인이 생겨서 관련 문서를 찾아보는데 나중에도 보게끔 정리를 해보려 한다.
플러그인은 IntelliJ IDEA(커뮤니티 에디션도 OK)를 사용하여 자바에서 개발된다.
위 문서를 번역한 내용이다.(파파고로 돌리고 이상한부분만 수정했다🌝)
IntelliJ IDEA 플러그인 개발
- IntelliJ Platform SDK : 플러그인, 사용자 지정 언어 지원 또는 사용자 지정 IDE 구축을 통해 IntelliJ Platform을 확장하기 위한 개발 키트
=> IntelliJ Platform SDK 로 플러그인을 개발하는 것 같고 아래와 같이 코딩 지침을 따르면 플러그인 승인이 더 수월하다고 말하는 듯 하다.
IntelliJ 플랫폼 코딩 지침
IntelliJ Platform에 기여하려는 코드(패치 또는 플러그인으로)를 작성하는 경우, 아래 지침을 따르면 JetBrains 개발 팀이 변경 사항을 검토하고 승인하는 것이 더 쉬워진다.
- 최신 소스 코드 추적
패치를 제출하는 경우 Git 저장소에서 최신 버전의 코드를 기반으로 패치를 빌드하는 것이 좋다. 가장 쉬운 방법은 JetBrains Git 저장소를 복제하고 Git에서 작업을 추적하며 "git format-patch" 명령을 사용하여 패치를 생성하는 것이다.
- 일반설계원칙
일반적인 Java 아키텍처 원칙을 따르도록 한다.
- 테스트
기능 테스트는 IntelliJ IDEA의 기존 기능 대부분을 다룬다. 테스트에서 수정 중인 영역을 포함하는 경우 테스트를 실행하고 변경 사항으로 인해 새로운 테스트 오류가 발생하지 않는지 확인해야 한다. 또한 수정한 버그나 추가한 새로운 기능을 다루는 새로운 기능 테스트를 제공하는 것이 좋다.
- 코드 포맷
일반적으로 코드 포맷에 대해 상당히 느슨하지만 적어도 다음 규칙을 준수해야 한다.
- 소스 파일의 공백 들여쓰기 2개
- 인스턴스 변수에 대한 접두사와 클래스 변수에 대한 접두사
- 새 소스 코드 파일에는 Apache 2 라이센스와 기여자 이름이 포함된 저작권 문이 포함돼야 한다.
코드 포맷 지침을 따르는 가장 쉬운 방법은 IntelliJ IDEA Community Edition 프로젝트 디렉터리에 포함된 공유 코드 스타일을 사용하여 코드 제출을 다시 포맷하는 것이다.
-
검사
IntelliJ IDEA Community Edition 프로젝트에는 공유 검사 프로필이 포함되어 있다. 제출하는 코드에 해당 검사 프로필에 구성된 검사에서 강조 표시된 경고가 포함되지 않도록 하는 것이 좋다. -
JavaDoc 주석
코드가 새 Open을 추가하는 경우API 인터페이스, 클래스, 메서드 또는 확장 지점. API의 매개 변수 및 용도를 설명하는 JavaDoc 주석을 제공해야 한다. 코드의 다른 부분에 대해 JavaDoc 또는 기타 설명을 제공하는 것은 좋은 것이지만 반드시 필요한 것은 아니다. -
커밋
변경사항을 검토할 때 불필요한 작업을 방지하려면 다음 지침을 따른다.
- 패치 또는 풀 요청을 제출하기 전에 변경 사항을 모두 검토하며 변경한 모든 코드가 의미있는 것인지 확인한다.
- 미완성 작업을 패치에 포함하지 않는다.
- TODO 내용이 포함되어 있지 않은지 확인한다.
- 추가한 코드가 필요하지 않은 경우 패치를 제출하기 전에 코드를 삭제해야 한다.
- 포맷, "노란색 코드"(경고) 또는 코드 스타일에 영향을 미치는 변경사항은 버그를 수정하거나 기능을 구현하는 실제 변경 사항과 함께 포함하지 않는다. 빈약한 코드로 검토 과정이 복잡해질 수 있다.
- 단일 패치 또는 풀 요청 내에서 여러 문제를 해결하지 않는다.
- 수정 자체에 필수적인 경우가 아니라면 구성 파일(runConfiguration/IDEA.xml, codeStyleSettings.xml, misc.xml 등)에 변경 내용을 커밋하지 않는다.
- 수정에 필요한 경우를 제외하고 클래스를 이동하거나 이름을 바꾸지 않는다.
- 이상적인 pull 요청은 버그를 수정하거나 기능을 구현하는 데 필요한 모든 것을 포함하는 하나의 커밋을 포함할 수 있지만 다른 것은 없다. "일찍 커밋, 자주 커밋"은 로컬 커밋에만 완벽하게 적용되지만, 그러한 "공개 커밋"은 검토하기 어렵다(검토자는 진행 중인 작업을 검토하는 데 더 많은 시간을 할애하여 커밋하거나 커밋 메시지에 저장된 모든 변경 사항을 한 번에 검토해야 한다).
- 가장 좋은 방법은 일찍 커밋하는 것이지만 모든 커밋을 설명하는 커밋 메시지와 함께 하나로 압축하는 것입니다.
- 때로는 하나의 문제에 대해 몇 가지 커밋도 허용되지만, 이러한 커밋은 각각 문제를 해결하기 위한 자체적인 "단계"여야 한다.
