'효율적인 툴 사용'에 해당되는 글 16건
- 2009/11/12 Galileo - Google Code - Mylyn 연동하기
- 2009/10/21 Eclipse 단축키 (14)
- 2009/10/09 이클립스의 플러그인 소스 훔쳐보기 (Plug-in Spy))
- 2009/01/22 이클립스 플러그인 롤백(Rollback)
- 2008/10/24 나만의 maven archetype 만들기~
- 2008/10/24 Eclipse Memory Analyzer (MAT)
- 2008/08/01 [스크린 캐스팅] 튜토리얼 - 이클립스 유로파로 시간을 절약하는 열 가지 기법
- 2008/07/23 [스크린 캐스팅] 이클립스 유로파로 시간을 절약하는 열 가지 기법(사족) (10)
- 2008/04/16 이클립스 플러그인 - jAutodoc (2)
- 2007/12/21 [추천]Eclipse Analyze 기능을 이용한 템플릿 기반 리팩터링.
이클립스 Galileo 3.5.1을 기반으로 하는 SSTS(SpringSource Tool Suite)에서 Mylyn으로 Google Code와 연동을 해봤습니다.
Galileo라고 별다른건 없고, Ganymede에서 설치하는 것과 동일하게 웹 템플릿을 설치해주면 됩니다.
그 다음으로 태스크 리파지토리 연결을 해야 하는데 여기서 조금 해맸습니다^^; Google Code는 쿼리를 직접 손으로 적어줘야 하는 극한의 확장성(불편함^^;)을 제공하고 있기 때문입니다.
정리하자면 각 컬럼 별로 다음과 같이 입력하시면 됩니다.
사실 기본값과 거의 차이가 없는데, 오히려 이런저런 아티클을 참조하다가 시간이 조금 더 걸렸습니다^^.
can은 목록으로 조회해오는 이슈의 상태를 의미합니다. can을 1로 설정하면 이미 close된 이슈도 함께 받아 옵니다.
Galileo라고 별다른건 없고, Ganymede에서 설치하는 것과 동일하게 웹 템플릿을 설치해주면 됩니다.
Update URL: http://download.eclipse.org/tools/mylyn/update/incubator
그 다음으로 태스크 리파지토리 연결을 해야 하는데 여기서 조금 해맸습니다^^; Google Code는 쿼리를 직접 손으로 적어줘야 하는 극한의 확장성(불편함^^;)을 제공하고 있기 때문입니다.
정리하자면 각 컬럼 별로 다음과 같이 입력하시면 됩니다.
Server: http://code.google.com/p/${projectName}/issues
Label: 적당히
User ID: Gmail ID
Password: Gmail Password
Task URL: ${serverUrl}/detail?id=
New Task URL: ${serverUrl}/entry
Query Request URL: ${serverUrl}/csv?can=1&colspec=ID+Status+Type+Owner+Summary
Query Pattern: "({Id}[0-9]+?)","({Status}.*?)","({Type}.*?)","({Owner}.*?)","({Description}.*?)"
Label: 적당히
User ID: Gmail ID
Password: Gmail Password
Task URL: ${serverUrl}/detail?id=
New Task URL: ${serverUrl}/entry
Query Request URL: ${serverUrl}/csv?can=1&colspec=ID+Status+Type+Owner+Summary
Query Pattern: "({Id}[0-9]+?)","({Status}.*?)","({Type}.*?)","({Owner}.*?)","({Description}.*?)"
사실 기본값과 거의 차이가 없는데, 오히려 이런저런 아티클을 참조하다가 시간이 조금 더 걸렸습니다^^.
can은 목록으로 조회해오는 이슈의 상태를 의미합니다. can을 1로 설정하면 이미 close된 이슈도 함께 받아 옵니다.
2008. 10. 20
자바 에디터에서는 ctrl+/ 나 ctrl+shift+/ 로 간단하게 주석처리 할 수 있지만 XML에서는 <!-- 를 입력한 다음 자동으로 등장하는 -->를 잘라내서 원하는 영역 마지막에 붙여 넣는 방법으로 사용했었습니다.
그러나 오늘 잘못된 키를 누르는 바람에 알게 됐습니다. XML에서는 이 단축키가 작동됩니다. 주석 처리 된 영역을 다시 지정하고, 다시 단축키를 누르면 주석이 사라지는 기능도 제공하니 편리하게 사용할 수 있습니다.
2008. 2. 12
단축키를 사용하는 이유는 마우스로 가는 손의 횟수를 줄여서 프로그램을 짜는 흐름을 잃지 않으려는데 큰 이유가 있습니다.
프로그램 작성 중(특히, 리팩터링) 빨간 줄이 나면 퀵 픽스를 사용하게 됩니다. 퀵 픽스 단축키는 가장 흔히 사용하는 단축키 중 하나인데, 문제는 빨간 줄이 쳐져 있는 곳으로 이동하기 위해서 다시 마우스에 손이 가게 된다는 것이죠.
빨간 줄(노란 줄 포함)로 이동할 수 있는 단축키가 있나 곰곰히 찾아보다 결국 발견해 냈습니다. 수정 작업이 보다 수월해지게 됐습니다.
2008. 1. 3
가장 큰 효과는 바디가 비어 있는 xml 엘리먼트를 empty 엘리먼트 태그로 변경해 줌. by 토비님.
2007 original.
한 때 AJN에서 Eclipse 단축키 달기 경쟁이 있었습니다^^
- 자주 사용하는 단축키.
ctrl+shift+c XML에서 선택 영역 주석 처리하기
자바 에디터에서는 ctrl+/ 나 ctrl+shift+/ 로 간단하게 주석처리 할 수 있지만 XML에서는 <!-- 를 입력한 다음 자동으로 등장하는 -->를 잘라내서 원하는 영역 마지막에 붙여 넣는 방법으로 사용했었습니다.
그러나 오늘 잘못된 키를 누르는 바람에 알게 됐습니다. XML에서는 이 단축키가 작동됩니다. 주석 처리 된 영역을 다시 지정하고, 다시 단축키를 누르면 주석이 사라지는 기능도 제공하니 편리하게 사용할 수 있습니다.
2008. 2. 12
ctrl + , or . 컴파일 에러 혹은 경고가 발생한 지점으로 이동
단축키를 사용하는 이유는 마우스로 가는 손의 횟수를 줄여서 프로그램을 짜는 흐름을 잃지 않으려는데 큰 이유가 있습니다.
프로그램 작성 중(특히, 리팩터링) 빨간 줄이 나면 퀵 픽스를 사용하게 됩니다. 퀵 픽스 단축키는 가장 흔히 사용하는 단축키 중 하나인데, 문제는 빨간 줄이 쳐져 있는 곳으로 이동하기 위해서 다시 마우스에 손이 가게 된다는 것이죠.
빨간 줄(노란 줄 포함)로 이동할 수 있는 단축키가 있나 곰곰히 찾아보다 결국 발견해 냈습니다. 수정 작업이 보다 수월해지게 됐습니다.
2008. 1. 3
xml파일에서 마우스 오른쪽 클릭 -> Cleanup Document... 선택 -> 원하는 옵션 체크 후 OK
가장 큰 효과는 바디가 비어 있는 xml 엘리먼트를 empty 엘리먼트 태그로 변경해 줌. by 토비님.
2007 original.
한 때 AJN에서 Eclipse 단축키 달기 경쟁이 있었습니다^^
- 자주 사용하는 단축키.
1. ctrl + z, y Undo, Redo
2. ctrl + 1 Quick Fix
3. ctrl + d block delete
4. alt + 좌/우 이전, 다음 작업 이동
5. ctrl + alt + 위/아래 Block copy
6. ctrl + / Comment/Uncomment
7. alt + shift + r Rename
8. alt + shift + s Source menu
9. alt + shift + t Refactoring menu
10. alt + shift + x + @ run mode
11. ctrl + space Code Assist
12. ctrl + F11 restart last launching
13. sysout +ctrl + space System.out.println() Macro
14. ctrl + Shift + UP/Down 이전, 다음 메소드로 이동
15. ctrl + M Full Screen View
16. ctrl + W 창 닫기
17. ctrl + PageUP/Down 창 좌우로 이동
18. alt + 위/아래 블록 채 이동
19. ctrl + shift + o Organize Import
20. ctrl + shitf + r Open Resource
21. alt + shitf + z Surround with menu
22. ctrl + e Quick Switch Editor
23. shift + ctrl + w 모든 창 닫기
24. alt + shift + w show In Menu
25. ctrl + F7 Next View(원하는 View 창 전환)
25-1. ctrl + F8 원하는 Perspective로 전환
26. alt + shift + m Extract Method
27. ctrl + h Search
28. shift + alt + j javadoc 달기
29. shift + ctrl + l 도움말
30. alt + shift + I inline
31. ctrl + shitf + t Open Type
32. ctrl + shift + x/y 대/소문자 변환
33. ctrl + 3 Quick Access
34. alt + shift + s synchronize with Repository (SVN만 됨. CVS는 미지원)
35. alt + shift + w show in
36. ctrl + o Quick Outline
37. ctrl + l go to line
38. ctrl + , or . 컴파일 에러 혹은 경고가 발생한 지점으로 이동
39. ctrl+shift+c ctrl+shift+c XML에서 선택 영역 주석 처리하기
2. ctrl + 1 Quick Fix
3. ctrl + d block delete
4. alt + 좌/우 이전, 다음 작업 이동
5. ctrl + alt + 위/아래 Block copy
6. ctrl + / Comment/Uncomment
7. alt + shift + r Rename
8. alt + shift + s Source menu
9. alt + shift + t Refactoring menu
10. alt + shift + x + @ run mode
11. ctrl + space Code Assist
12. ctrl + F11 restart last launching
13. sysout +ctrl + space System.out.println() Macro
14. ctrl + Shift + UP/Down 이전, 다음 메소드로 이동
15. ctrl + M Full Screen View
16. ctrl + W 창 닫기
17. ctrl + PageUP/Down 창 좌우로 이동
18. alt + 위/아래 블록 채 이동
19. ctrl + shift + o Organize Import
20. ctrl + shitf + r Open Resource
21. alt + shitf + z Surround with menu
22. ctrl + e Quick Switch Editor
23. shift + ctrl + w 모든 창 닫기
24. alt + shift + w show In Menu
25. ctrl + F7 Next View(원하는 View 창 전환)
25-1. ctrl + F8 원하는 Perspective로 전환
26. alt + shift + m Extract Method
27. ctrl + h Search
28. shift + alt + j javadoc 달기
29. shift + ctrl + l 도움말
30. alt + shift + I inline
31. ctrl + shitf + t Open Type
32. ctrl + shift + x/y 대/소문자 변환
33. ctrl + 3 Quick Access
34. alt + shift + s synchronize with Repository (SVN만 됨. CVS는 미지원)
35. alt + shift + w show in
36. ctrl + o Quick Outline
37. ctrl + l go to line
38. ctrl + , or . 컴파일 에러 혹은 경고가 발생한 지점으로 이동
39. ctrl+shift+c ctrl+shift+c XML에서 선택 영역 주석 처리하기
플러그인을 개발하다보면 이 기능이 어떻게 구현되어 있나 하는 궁금증을 갖을때가 많습니다.
얼마 되지는 않았지만, 플러그인을 만들다 보니 사실 기술적인 어려움 보다는 그 방대한 API에 기능을 찾아 다니는데 시간이 많이 들어가게 됩니다.
이럴때 유용하게 사용할 수 있는 기능이 있습니다.
바로 플러그인 스파이라는 기능입니다.
단축키로는 alt + shift + F1.
이 기능은 현재 활성화 되어 있는 플러그인과 관련된 클래스를 바로 보여줍니다.
역시 단축키를 써야 재맛입니다.
우리가 자주 사용하는 Getter & Setter 생성기의 구현이 어떻게 되어 있는지 궁금하시다면, Getter&Setter 생성기 화면을 띄우고, alt+shift+F1을 눌러보세요.
(보안에 걸리는 내용은 자체 삭제했습니다..)
GetterSetterTreeSelectionDialog 클래스를 클릭하면 바로 해당 클래스의 소스로 이동하게 됩니다. 관련된 기능은 네비게이션 해가면서 살펴볼 수 있습니다.
이미 좋은 기능이 구현된 부분이 많기 때문에, RI의 성격으로 이클립스의 많은 소스들을 살펴보면서 한 수 배울 수 있습니다.
얼마 되지는 않았지만, 플러그인을 만들다 보니 사실 기술적인 어려움 보다는 그 방대한 API에 기능을 찾아 다니는데 시간이 많이 들어가게 됩니다.
이럴때 유용하게 사용할 수 있는 기능이 있습니다.
바로 플러그인 스파이라는 기능입니다.
단축키로는 alt + shift + F1.
이 기능은 현재 활성화 되어 있는 플러그인과 관련된 클래스를 바로 보여줍니다.
역시 단축키를 써야 재맛입니다.
우리가 자주 사용하는 Getter & Setter 생성기의 구현이 어떻게 되어 있는지 궁금하시다면, Getter&Setter 생성기 화면을 띄우고, alt+shift+F1을 눌러보세요.
(보안에 걸리는 내용은 자체 삭제했습니다..)
GetterSetterTreeSelectionDialog 클래스를 클릭하면 바로 해당 클래스의 소스로 이동하게 됩니다. 관련된 기능은 네비게이션 해가면서 살펴볼 수 있습니다.
이미 좋은 기능이 구현된 부분이 많기 때문에, RI의 성격으로 이클립스의 많은 소스들을 살펴보면서 한 수 배울 수 있습니다.
m2e 플러그인 설치 후 갑자기 Java, JEE perspective와 관련 View 들이 메뉴에서 모두 사라져버렸습니다.@@
설치 전에 프로젝트의 스프링 설정 파일이 너무 많아서 Spring IDE가 hang이 걸려버리길래 강제로 죽이고 난 후 바로 설치해서 그런가 충돌이 났습니다.
이럴 때는 플러그인 설치 전 상태로 이클립스 플러그인 구성을 되돌려서 다시 설치를 시도해보면 되겠습니다. 'Help > Software Update > Revert Configuration'를 선택하면 됩니다.
되돌릴 수 있는 시점을 선택할 수 있으니 단순한 롤백이 아니긴 합니다. 다시 설치하니 정상적으로 적용되는군요^^.
설치 전에 프로젝트의 스프링 설정 파일이 너무 많아서 Spring IDE가 hang이 걸려버리길래 강제로 죽이고 난 후 바로 설치해서 그런가 충돌이 났습니다.
이럴 때는 플러그인 설치 전 상태로 이클립스 플러그인 구성을 되돌려서 다시 설치를 시도해보면 되겠습니다. 'Help > Software Update > Revert Configuration'를 선택하면 됩니다.
되돌릴 수 있는 시점을 선택할 수 있으니 단순한 롤백이 아니긴 합니다. 다시 설치하니 정상적으로 적용되는군요^^.
여러 문서가 있지만, 역시 Maven 공식 사이트에 있는 문서를 참조하는게 좋습니다. 저도 괜히 이것저것 보다가 헷갈리기만 했습니다.
문서대로 하면 크게 문제 없게 됩니다. 다만, 헷갈리는 점 몇 가지를 정리해보겠습니다.
1. pom.xml을 두 개를 작성하는 겁니다. 하나는 archetype에 대한 파일로 archetype 폴더의 root에 위치하면 됩니다. 두 번째 pom.xml은 만든 archetype을 통해서 프로젝트를 생성할 때 사용되는 파일입니다. 위치는 archetype-root/src/main/resources/archetype-resources/에 두면 됩니다.
2. archetype의 pom.xml에는 packaing 타입을 명시해주지 않아야 합니다. 문서에 보면 maven-plugin으로 명시되어 있는데 이렇게 하면 WARNING이 떨어 집니다.
3. archetype을 만들 때는 직접 프로젝트를 생성하는 것보다는 maven-archetype-archetype archetype을 사용해서 생성하는게 훨씬 편리합니다.
4. Maven 특유의 깊은 뎊스가 싫은 경우에는 애시당초 프로젝트 생성 시에 기본 디렉토리를 변경해주면 됩니다.
웹 APP면 웹 기본 디렉토리도 변경하면 됩니다.
maven 디렉토리에 대한 이야기는 Toby님의 글을 꼭 한 번 읽어보시길 바랍니다.
저는 스프링 App와 스프링 MVC, 스프링 Remoting 정도 만들어 봤습니다.
문서대로 하면 크게 문제 없게 됩니다. 다만, 헷갈리는 점 몇 가지를 정리해보겠습니다.
1. pom.xml을 두 개를 작성하는 겁니다. 하나는 archetype에 대한 파일로 archetype 폴더의 root에 위치하면 됩니다. 두 번째 pom.xml은 만든 archetype을 통해서 프로젝트를 생성할 때 사용되는 파일입니다. 위치는 archetype-root/src/main/resources/archetype-resources/에 두면 됩니다.
2. archetype의 pom.xml에는 packaing 타입을 명시해주지 않아야 합니다. 문서에 보면 maven-plugin으로 명시되어 있는데 이렇게 하면 WARNING이 떨어 집니다.
3. archetype을 만들 때는 직접 프로젝트를 생성하는 것보다는 maven-archetype-archetype archetype을 사용해서 생성하는게 훨씬 편리합니다.
4. Maven 특유의 깊은 뎊스가 싫은 경우에는 애시당초 프로젝트 생성 시에 기본 디렉토리를 변경해주면 됩니다.
<build>
<sourceDirectory>src</sourceDirectory>
<testSourceDirectory>test</testSourceDirectory>
<resources>
<resource>
<directory>resource</directory>
</resource>
</resources>
</build>
<sourceDirectory>src</sourceDirectory>
<testSourceDirectory>test</testSourceDirectory>
<resources>
<resource>
<directory>resource</directory>
</resource>
</resources>
</build>
웹 APP면 웹 기본 디렉토리도 변경하면 됩니다.
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1-alpha-2</version>
<configuration>
<warSourceDirectory>/webapp</warSourceDirectory>
</configuration>
</plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1-alpha-2</version>
<configuration>
<warSourceDirectory>/webapp</warSourceDirectory>
</configuration>
</plugin>
maven 디렉토리에 대한 이야기는 Toby님의 글을 꼭 한 번 읽어보시길 바랍니다.
저는 스프링 App와 스프링 MVC, 스프링 Remoting 정도 만들어 봤습니다.
힙 덤프를 분석해주는 이클립스 플러그인입니다.
상당히 다양한 뷰로 분석이 가능합니다. OQL(Object Query Language)라는 개념을 제공해서 쿼리를 사용해서 덤프 내의 정보를 조회할 수 있습니다.
TPTP의 힙 덤프 분석 버전이라고 할까요? 너무 많은 정보를 제공하는데, 문제는 여기서 어떤 방법으로 좋은 정보를 추려낼 수 있는지가 관건입니다.
활용법이나 기능들은 너무 많으니...관련 링크를 참조하시면 될 것 같습니다.
상당히 다양한 뷰로 분석이 가능합니다. OQL(Object Query Language)라는 개념을 제공해서 쿼리를 사용해서 덤프 내의 정보를 조회할 수 있습니다.
select * from java.lang.String이처럼 쿼리를 실행하면 덤프에 남아있는 String 인스턴스 정보 전체를 찾아 줍니다. 이 정보를 가지고 여러 가지 분석을 할 수 있습니다.
TPTP의 힙 덤프 분석 버전이라고 할까요? 너무 많은 정보를 제공하는데, 문제는 여기서 어떤 방법으로 좋은 정보를 추려낼 수 있는지가 관건입니다.
활용법이나 기능들은 너무 많으니...관련 링크를 참조하시면 될 것 같습니다.
얼마전에 IBM에 올린 스크린 캐스팅입니다. 퍼갈 수 있게도 되어 있네요^^; 디벨로퍼웍스의 거의 유일한 단점인 네비게이션의 불편으로 금방 찾기도 힘들어질 염려가 있어 퍼다둡니다.
이클립스 유로파로 시간을 절약하는 열 가지 기법(사족)
이클립스 유로파로 시간을 절약하는 열 가지 기법(사족)
IBM DeveloperWorks에서 스크린 캐스팅 튜토리얼을 시작했습니다. 월 1회 올라오는데, 첫 달에는 제가 하고, 다음달에는 기선형이 하게 됩니다. DeveloperWorks는 블로그 리뷰어 등 다양하고 좋으 시도를 많이 하는 것 같습니다^^.
대전 집에 내려오다보니 조용한 시간이 저녁 밖에 없어서 12시가 넘은 시각에 녹화를 했습니다.^^; 그래서 그런지 목소리가 조금 더 가라앉았네요.. 다음에는낮에 해서 좀 더 밝은 분위기로 해야할 것 같네요ㅕ..
처음이라 내용이 어렵지 않은 튜토리얼로 골랐는데, 그래도 시간이 부족해서 많은 부분을 빼고 진행했습니다.. 처음 계획은 30분이었는데, 아무리해도 30분에는 못 맞추겠더라구요.. 다음 번에는 시간을 두, 세 시간 정도 줬으면 좋겠습니다..그래야 멀 제대로 해볼것 같아요..
크게 새로운 내용은 아니지만, 작게나마 도움이 되는 내용이었으면 좋겠습니다.
대전 집에 내려오다보니 조용한 시간이 저녁 밖에 없어서 12시가 넘은 시각에 녹화를 했습니다.^^; 그래서 그런지 목소리가 조금 더 가라앉았네요.. 다음에는낮에 해서 좀 더 밝은 분위기로 해야할 것 같네요ㅕ..
처음이라 내용이 어렵지 않은 튜토리얼로 골랐는데, 그래도 시간이 부족해서 많은 부분을 빼고 진행했습니다.. 처음 계획은 30분이었는데, 아무리해도 30분에는 못 맞추겠더라구요.. 다음 번에는 시간을 두, 세 시간 정도 줬으면 좋겠습니다..그래야 멀 제대로 해볼것 같아요..
크게 새로운 내용은 아니지만, 작게나마 도움이 되는 내용이었으면 좋겠습니다.
제가 참여하고 있는 프로젝트가 이제 막바지에 다들으고 있습니다.
완성도를 높이기 위해 노력하고 있는데요, 프레임웍 자체의 완성도를 높이는 것도 중요하지만, 잘 만들어 놓은 상품을 잘 설명하는 것도 그에 못지 않게 중요하다는 생각합니다.
아무리 잘 만들어 놓더라도, 이를 잘 설명하지 못하면 말짱 꽝이니까요. 아무리 좋은 물건도 이를 잘 사용하지 못하면 오히려 해가 될 수도 있으니까요. 그래서 저번 일요일에는 새벽 5시까지 개발 가이드를 만들기도 했습니다..
주석 또한 이런 가이드에 못지 않게 중요한 요소입니다. 남이 짜 놓은 소스를 알아 보기란 참 쉽지 않죠.. 그래서 주석을 잘 남겨 두려는 생각에 작업을 하고 있습니다.
주석을 생성해주는 단축키는 alt+shift+j죠. 문제는 멤버 단위(변수나 메소드)로 밖에 주석을 만들어주지 못 한 다는 점입니다. 그래서 지나치게 지루한 감이 생겨서 전체적으로 주석을 생성해주는 플러그인을 찾아 봤더니 역시나 있더군요^^.
jAutoDoc 입니다. 기본적으로 클래스 수준에서 주석을 일괄적으로 생성해줍니다. 옵션도 꽤나 다양해서 사용하는데 크게 문제 없습니다.
특이한 점은 멤버의 이름을 사용해서 주석에 자동으로 설명을 달아 준 다는 점입니다. 단어를 매치 시킬 수도 있어서 메소드 이름만 잘 지어 놨다면, 깜찍하게 쓸 수 있을것 같습니다.
완성도를 높이기 위해 노력하고 있는데요, 프레임웍 자체의 완성도를 높이는 것도 중요하지만, 잘 만들어 놓은 상품을 잘 설명하는 것도 그에 못지 않게 중요하다는 생각합니다.
아무리 잘 만들어 놓더라도, 이를 잘 설명하지 못하면 말짱 꽝이니까요. 아무리 좋은 물건도 이를 잘 사용하지 못하면 오히려 해가 될 수도 있으니까요. 그래서 저번 일요일에는 새벽 5시까지 개발 가이드를 만들기도 했습니다..
주석 또한 이런 가이드에 못지 않게 중요한 요소입니다. 남이 짜 놓은 소스를 알아 보기란 참 쉽지 않죠.. 그래서 주석을 잘 남겨 두려는 생각에 작업을 하고 있습니다.
주석을 생성해주는 단축키는 alt+shift+j죠. 문제는 멤버 단위(변수나 메소드)로 밖에 주석을 만들어주지 못 한 다는 점입니다. 그래서 지나치게 지루한 감이 생겨서 전체적으로 주석을 생성해주는 플러그인을 찾아 봤더니 역시나 있더군요^^.
jAutoDoc 입니다. 기본적으로 클래스 수준에서 주석을 일괄적으로 생성해줍니다. 옵션도 꽤나 다양해서 사용하는데 크게 문제 없습니다.
특이한 점은 멤버의 이름을 사용해서 주석에 자동으로 설명을 달아 준 다는 점입니다. 단어를 매치 시킬 수도 있어서 메소드 이름만 잘 지어 놨다면, 깜찍하게 쓸 수 있을것 같습니다.
언제 부터인지는 정확히 모르겠지만, 이클립스 메뉴에 등장한 친구 입니다. 분석 기능을 가지고 있는 "Analyze" 입니다.
이상한게 하나 추가 됐구나하고 생각하고 주의깊게 보지 않았는데, 오늘 직접 해보니 상당히 유용한 기능을 제공하고 있습니다. 역시 직접 해봐야 한다니까요..
발단은 오늘 잠깐 받았던 RSA 교육이었습니다. 강사가 RSA에 있는 이 기능을 보여주더군요. 저는 "흠..어디서 보던건데.."하는 생각이 들어서, 자리에 오자마자 이클립스를 띄워보니 떡 하니 이 친구가 있더군요.
실행법은 간단합니다. Launch As... 클릭해서 다이얼로그 창을 띄우고, 대상 프로젝트를 선택하고,
분석할 템플릿을 정하면 끝입니다.
RSA에는 더 많은 템플릿이 있던데, 제 이클립스에는 한 가지 종료 밖에 없군요. 추가할 수 있는지 찾아 봐야 겠습니다.
그럼 적용하고, 수행합니다.
결과 창을 확인해보면 다음과 같습니다.
적용한 템플릿은 "J2SE Best Practice"로, 각 항목 기준에 어긋난 부분을 타겟 프로젝트 내에서 찾아 줍니다. 예를 들어, Comparison항목을 확인해보겠습니다.
"Always place constants on the left side of the equals()"라는 항목의 기준에 대해서 위반한 소스가 40개가 있습니다. 문자열 비교할 때, 상수를 뒤에 둔 경우를 말합니다.
매우 간단한 Best Practice지만, 자칫 잘못하면 NullPointerException이 발생하는 원이이 되기도 합니다. 이렇게 소소한 부분은 눈으로 찾거나, 실제 코딩할 때 놓치는 경우가 많은데, 이렇게 한 번에 찾아 주니 매우 좋군요. 굳 입니다!
해당 소스에 보면 파란색 밑줄이 쳐져 있고, 왼쪽에 초록색 아이콘이 나타나 있습니다.
여기서 핵심은 이 아이콘을 선택하거나, ctrl+1을 누르면 해당 항목에 대해 수정할 수 있는 방안을 제시해줍니다.
이클립스의 최대 장점인 Quick Fix이죠. 문제점을 지적만 하는게 아니라, 대안까지 제시해주는 놀라운 발상의 전환이죠. 칭찬은 이정도만 해야겠군요^^.
리팩터링 메뉴를 통해서 리팩터링을 직접하는 방법도 있지만, 이렇게 베스트 프랙티스를 등록해두고, 템플릿에 맞추어 일관된 리팩터링을 할 수 있는 훌륭한 방법이라 생각합니다.
또는 코드 스타일을 동일하게 유지할 수 있는 대안이 될 수도 있겠네요. 개발하는 과정에서 템플릿을 제공할 수도 있지만, 아무래도 사람이 하는지라 놓치는 부분도 있겠죠. 그런 경우 훌륭한 대안이 될 것 같습니다.
다만 아쉬운 점은 지적된 항목에 대해 일괄적으로 Quick Fix를 수행하는 메뉴가 없다는 점입니다.
이상한게 하나 추가 됐구나하고 생각하고 주의깊게 보지 않았는데, 오늘 직접 해보니 상당히 유용한 기능을 제공하고 있습니다. 역시 직접 해봐야 한다니까요..
발단은 오늘 잠깐 받았던 RSA 교육이었습니다. 강사가 RSA에 있는 이 기능을 보여주더군요. 저는 "흠..어디서 보던건데.."하는 생각이 들어서, 자리에 오자마자 이클립스를 띄워보니 떡 하니 이 친구가 있더군요.
실행법은 간단합니다. Launch As... 클릭해서 다이얼로그 창을 띄우고, 대상 프로젝트를 선택하고,
분석할 템플릿을 정하면 끝입니다.
RSA에는 더 많은 템플릿이 있던데, 제 이클립스에는 한 가지 종료 밖에 없군요. 추가할 수 있는지 찾아 봐야 겠습니다.
그럼 적용하고, 수행합니다.
결과 창을 확인해보면 다음과 같습니다.
적용한 템플릿은 "J2SE Best Practice"로, 각 항목 기준에 어긋난 부분을 타겟 프로젝트 내에서 찾아 줍니다. 예를 들어, Comparison항목을 확인해보겠습니다.
"Always place constants on the left side of the equals()"라는 항목의 기준에 대해서 위반한 소스가 40개가 있습니다. 문자열 비교할 때, 상수를 뒤에 둔 경우를 말합니다.
매우 간단한 Best Practice지만, 자칫 잘못하면 NullPointerException이 발생하는 원이이 되기도 합니다. 이렇게 소소한 부분은 눈으로 찾거나, 실제 코딩할 때 놓치는 경우가 많은데, 이렇게 한 번에 찾아 주니 매우 좋군요. 굳 입니다!
해당 소스에 보면 파란색 밑줄이 쳐져 있고, 왼쪽에 초록색 아이콘이 나타나 있습니다.
여기서 핵심은 이 아이콘을 선택하거나, ctrl+1을 누르면 해당 항목에 대해 수정할 수 있는 방안을 제시해줍니다.
이클립스의 최대 장점인 Quick Fix이죠. 문제점을 지적만 하는게 아니라, 대안까지 제시해주는 놀라운 발상의 전환이죠. 칭찬은 이정도만 해야겠군요^^.
리팩터링 메뉴를 통해서 리팩터링을 직접하는 방법도 있지만, 이렇게 베스트 프랙티스를 등록해두고, 템플릿에 맞추어 일관된 리팩터링을 할 수 있는 훌륭한 방법이라 생각합니다.
또는 코드 스타일을 동일하게 유지할 수 있는 대안이 될 수도 있겠네요. 개발하는 과정에서 템플릿을 제공할 수도 있지만, 아무래도 사람이 하는지라 놓치는 부분도 있겠죠. 그런 경우 훌륭한 대안이 될 것 같습니다.
다만 아쉬운 점은 지적된 항목에 대해 일괄적으로 Quick Fix를 수행하는 메뉴가 없다는 점입니다.
Prev
Rss Feed