주희아빠의 헝그리 라이딩

초보 이클립스 입문기 1,2 본문

잡다한 이야기

초보 이클립스 입문기 1,2

도림천 버섯돌이 2016. 11. 23. 21:38
개발자로 밥 먹고 산지 얼마 안 됐을 때 Jlab 게시판에 적었던 글입니다. 이제는 jlab 은 없어지고 인터넷 다른 사이트에 복사본이 남아 있는 것을 건져와 봅니다. 그 옛날 적었던 글을 다시 보는 것은 역시나 손발이 오글거리는 일이군요.


제목 : 초보 이클립스 입문기 1 (2004-03-12 00:11:46.0 )
이름 multitab



1. 이클립스와의 만남. 
 
이클립스가 유행인지는 좀 된 듯하다. 물론 처음 시도는 좀 더 이전에 있었다. 그러나, 지금과 비슷한 이유로 고생하다가 바로 포기해 버린 적이 두번 정도 있다(너무 느리고 에디팅 방법이 생소하고..)
 
이번프로젝에서는 이클립스의 사용이 공식적으로 요청됐다. 필수는 아니지만 효과적인 프로젝 관리를 위해서 이클립스로 작성해 달라고 한다.
이클립스로 만들면 뭐가 다르게 나오는지를 모르기 때문에 어쩔 수 없이 사용을 해야 할 듯 했다.
 
처음으로 준 테스트프로그램 모듈(프로젝을 위해 제공된)을 기존에 사용하던 ant 에서 돌리는데 실패했다. 물build.xml 이 구성이 안되어 있었기 때문인데 이를 조목조목 따져보기보다는 이클립스에서 돌리는 편이 빠르다는 생각이 들어서 이클립스에서 바로 시작해 보았다. 
 
프로젝 메뉴중에서 import 라는 것이 비슷한 듯 싶어서 대충 찍어서 폴더를 골라줬다. 그런데 무쟈게 하드 읽는 소리가 들리며, 컴파일되고 있다는 메세지가 계속해서 나왔다. 역시나 내컴퓨터에서는 무리인가보다 하는 생각이 앞섰다.
 
그런데, 신기하게도 한번에 바로 돌아가는 것이 아닌가.(물론 클래스를 실행시키는 법을 몰라서 또 한참 헤매기는 했다.)
이렇게 해서 이클립스와의 인연이 시작되었다. 과연 이 괴물을 잘 사용할 수 있을 것인가..

2. 본격적인 사용 첫째날...
 
사용 첫느낌. 일단 실행을 시키고 나면 무쟈게 오래 걸린다. 이클립스 로고 뜨는데도 한참이지만, 로고 없어지는데는 더 오래 걸린다. 제2의 부팅 시간이란 느낌이 든다.
여기서 어쩔 수 없이 본인의 컴퓨터 사양과 개발 환경을 소개한다.
- 펜티엄III 700MHz, 384M 메모리, 하드적당히, 비디오카드 후짐 and Windows2000
 
다른 프로그램을 돌릴 때는 별로 느리다는 생각을 가져본 적이 없다. 이제까지의 주로 사용하는 툴들이 Editplus, Secure-CRT 들로 대부분의 컴파일 작업은 별도의 리눅스 서버에서 이루어졌다. 연결은 주로 samba 를 사용하며, 원거리인 경우 ftp 로도 사용한다. 물론 tomcat 이나 apache 등도 리눅스에서 실행하므로 본인의 컴퓨터가 처리에 이용되는 경우는 거의 없었다. 소스 에디팅이나 명령 실행정도였다. 
 
데스크탑 자체는 윈도우지만 개발 환경으로 본다면 리눅스에 더 익숙하다고 볼 수 있겠다.(vi 만으로도 코딩이 불가능한 것은 아니지만 소스 전반에 걸친 copy & paste 나 tab 조정 등은 vi로 극복하기가 힘들었다.)
 
다시 이클립스로 얘기로 돌아와보면.
뜨는데만 오래 걸린다면 참고 쓸만하겠다. 그런데 java 파일을 작업하는중에도 계속해서 하드가 번쩍 거린다. 타이핑을 마치지도 않았는데 빨간밑줄이 쳐지지 않나, 아래 항목에 영향을 주는 듯 한 분위기가 들지 않나. 불안해서 못 봐줄 정도이다.
 
파일을 어느정도 작성하고 저장을 해보면 지가 알아서 바로 컴파일을 시도한다. 그리고는 수많은 에러를 주욱 쏟아낸다. 아직 마음의 준비를 하지도 않았는데.  T_T;
 
불편한점 좀더 야그해 보면, 가뜩이나 화면도 좁아 죽겠는데 뭐이리 보여주는 화면은 많은지 넓지도 않은 모니터에 정작 에디팅 할 수 있는 화면은 너무나 좁다. 왼쪽과 하단에 나오는 내용들은 아직 눈에 들어 오지는 않지만, 괜히 없앴다가는 중요한 정보를 놓치거나 나중에 다시 나오게 하는 법을 못찾을 까봐 불안해서 그냥 놔두고 쓰고 있는 상태이다.
 
특히나, editplus 처럼 화려한 구문강조(syntax hilight)에 익숙해져 있던 나로서는 이 썰렁한 컬러 감각에는 정말 할말이 없어졌다. 정말 최소의 명령어에만 표현되는 이 표현이란 참...(그러나 이후 JSP 를 본 충격에 비하면 별거 아니었다 자신한다.).
 
프로그램 전환간에는 그 느린 속도가 더욱 느껴지는 순간이다. 이눔의 javaw 가 메모리를 어떻게 사용하는지는 모르겠으나, alt-tab 등을 이용하여 이프로그램 저프로그램 사이를 오가다 보면 하드만 읽고 있는 컴퓨터가 정말 한심하게 느껴졌다(회사에다가 업그레이드를 해달라고 졸라봐?). 한참이라도 다른 프로그램을 사용하다가 이클립스로 돌아오면 지금껏 기다린 정도에 2배정도 더 있으면 된다. 에지간하면 이클립스만 사용해야 겠다는 생각이 들었다. 절대 최소화 시키지 않으리 -_-;

3. 인내력과 함께한 이틀째...
JSP 프로그래밍 환경을 구축하기 위해서는 jakarta-tomcat 을 설치해야 했다. 역시나 기분나쁜 일은 tomcat 역시 로컬PC 에 설치를 해야 한다는 것이었다. tomcat 을 다운받고 압축을 풀었다. exe 보다는  zip 파일본이 더 났다는 글을 본 듯 해서이다. 어짜피 개발 본이니 서비스로 올리는 일은 없을 듯 해서이기도 하다.
 
tomcat 의 고양이를 보기까지는 역시나 하드 돌아가는 소리를 안스러워해야만 했다.
tomcat 의 플러그인이라는게 있다고 한다. sysdeo 사이트를 검색하여 다운받아 설치했다. plug-in 디렉토리에 풀어 놓고, 이클립스를 재시동 하는 것으로 끝이라고 한다. 뜬후에 별로 달라진게 없다. 모가 달라진건지 게시판을 한참 헤맨후에야 알았다.
tomcat 을 start, stop, restart 할 수 있는 버튼과 템플릿 등이 생긴듯 하다. 이것의 사용을 위해서는 독립적으로 실행했던 tomcat 을 죽이고 이클립스 내부에서 실행해야만 하는 듯 하다. 기존의 tomcat 을 내리고 start 버튼으로 시동했다. 가능하면 restart 기능은 사용하지 않기로 했다. 각각 stop과 start를 실행한 시간과 거의 같아 보인다. 그냥 stop 과 start 를 모아 놓은 버튼 같다. 
 
JSP 를 편집하려 클릭하는 순간 엄청난 배신감에 빠졌다. 기본적으로는 확장자 연결도 안되어 있는 상태라고 한다. 억지로 default editor 를 선택해 JSP 를 열었을 때의 분위기는 정말로 쏴하다. java 파일은 그나마 절제된 칼라감각이라도 있었다면, 이건 마치 브라우저에서 소스보기 기능으로 열린 메모장의 HTML 을 보는 듯 하다.
게시판을 열심히 뒤져보니 이끔찍한 칼라를 바꿀 수 있는 플러그인이 있다고 한다. 
이름하여 lomboz 와 solaeclipse.. 어느게 나은지를 알 수 없으니 둘다 깔아 보기로 했다.
숨은 기능둘이 어떤 것이 있는지는 모르겠으나, 순전히 색감만을 가지고 솔라이클립스를 선택하기로 했다. JSP 와 HTML,XML 을 지원한다. 여전히 editplus 처럼 화려면 색감을 보이지는 않지만, 이정도라면 오전의 충격에서는 벗어날 만 하다.


좀 더 희망적인 얘기는 2편에서 계속 


개발자로 밥 먹고 산지 얼마 안 됐을 때 Jlab 게시판에 적었던 글입니다. 이제는 jlab 은 없어지고 인터넷 다른 사이트에 복사본이 남아 있는 것을 건져와 봅니다. 그 옛날 적었던 글을 다시 보는 것은 역시나 손발이 오글거리는 일이군요.


제목 : 초보 이클립스 입문기 2 (2004-03-12 00:12:47.0 )

이름 multitab


1. 본격적인 사용

1주일을 넘기고 나서부터는 어느정도 분위기에 적응할 수 있었다. 헛갈리던 메뉴 체계도 정리가 되어 간다.

중요한 프로퍼티들은 window/preferences 와 navigtor 에서의 마우스 오른쪽버튼 클릭으로 나오는 properties 를 통해 고칠 수 있게 되었다.

Java Build Path 의 Libraries 정도까지만 잘 다루면 실행이 안되거나 하는 일은 없어 보인다.

성급한 결론부터 내자면, JSP 편집보다는 java 편집에 탁월한 능력을 보이는 듯 했다. 


- 자동 문법체크

기존에 귀찮게만 따라다니던 빨간색 줄이 순간순간 문법 오류를 짚어 주고 있으므로, 굳이 저장하기전에(즉, 컴파일 하기 전에) 에러를 수정할 기회를 주었다. 이전에는 한번 컴파일 명령을 내린후로는 과연 몇개의 에러가 줄줄이 나올 것인가를 기대하고, 하나하나씩 잡아가는 그런 반복들이었다. 이제는 컴파일 수를 최소로 줄여가면서 작업할 수 있게 되었다. (새삼 강조하지만 느린 PC 에서는 컴파일 속도 역시 중요하다. 그러나 이클립스만 본다면 자체적으로 ant 와 합쳐져 있으므로, 당연히 새로 갱신되는 파일에 대해서만 컴파일 작업이 이루어진다. )

 

- 자동 완성

자동완성 기능정도라 불러야 할까.. MS 의 비주얼스튜디오 등에서 보던 자동 완성 기능이다. 처음엔 이 역시 불편한 존재라 생각했는데, 나중이 되니 정말 사람을 게을러 지게 만드는 주원인이었다. 일단 객체 생성후 어떠한 메소드를 불러야할지 고민하다 보면 어느새 메소드 리스트를 쫘악 토해낸다. 그중에서 얼추 비슷하게 때리다 보면 생각하던 메소드를 만날 수 있게 된다. 물론 넘겨줘야할 인자와 반환되는 타입에 대해서는 친절히 알려준다. 잘못된 타입의 경우 역시 무엇을 무엇에 하려 한다는 식으로 잘 나타내 준다.

덕분에 API 문서를 찾아 보는 일이 현저히 줄었다. 그어려운 String 비교함수인 .equalsIgnoreCase() - 역시 스펠링 안외워도 된다. 

 

- 자동 정리(?)

이와 더불어 가장 편리한 기능중 하나인 자동 import 찾아주기.. 메뉴상에는 Source/Add Import 로 나와 있는데. 예를 들어 List 객체를 import 도 안해준채 그냥 사용을 했다 치자. 이런경우 뻘건줄이 List 에 떡하니 자리 잡고 있다. 이전같으면 화면위로 올라가서 부지런히 import java.util.List 라고 쳐주었겠지만, List 를 마우스로 잘묶어서(또는 더불클릭) source/add import 를 실행하게 되면 자동적으로 import 구문을 만들어 준다. 대단히 편리한 기능이라 할 수 있겠다. 중복된 이름의 객체가 있다면 여러개의 경로 중 선택할 수 보여준다. 

자동으로 import 를 붙여주기만 할 뿐 아니라 없애주기도 한다. 뭐를 없애줄지에 대해서는 노란색 전구와 느낌표가 import 구문 앞에 나타내 준다. 이 import 에 사용된 객체는 한번도 사용이 안된 것이라는 문구이다. 이런것들이 여러개 보일 때 그냥 과감히 source/organize imports 를 실행하면 알아서 정리해 준다.

그 밖의 javadoc comment 를 자동으로 붙여준다거나, // 주석문 붙였다 띄었다라던가 적절한 내용의 try/catch 문의 자동 완성 역시 매우 편리한 기능이다. get/set 메소드 만들기도 노가다 줄이인데 큰 공신이다.

나머지 source 메뉴에 대해서는 잘 봐봐라. 단축키만 외워도 프로그램 짜는 모습이 무지하게 터프해 보인다. 

 

2. 이클립스를 구분하는 진정한 위력들

2주가 넘어서는 에디터로서의 이클립스 기능은 어느정도 마스터 한듯 했다. 이제는 고급기능들에 대해서도 도전해 보기로 했다.(특별히 고급도 아니지만.)

처음에는 눈에 아예 보이지도 않던 창들이 보이기 시작한다. navigator 나 outline, task, conole 등.. 덕분에 에디팅 화면이 좁아진다. -_-; 


- 리펙토링

일단 Refactor 메뉴이다. 리팩토링이 뭔지에 대해서는 관심만 많았지 내가 할일은 아니라고 생각하던 터이다. 생짜 코딩하기도 힘든데 이걸 또 고치라니..

그러나 특별히 모양새의 패턴들이 아니더라도 소스를 고쳐야 할 경우는 많이 있다. 가장 흔한 경우가 메소드의 이름이 바뀌는 경우라 하겠다. 이전 같으면 editplus 에서 여러 파일 찾기후 일괄 치환하여 저장후 컴파일하며 오류를 점검했을 것이다. 이때 중요한 것은 문자열과 메소드를 잘 구분하는 일이며, 테스트시에 잘못바뀐 메소드에 대해서 꼭 찾아야 한다는 부작용이 있다.

rename, move 를 제외하고는 나머지는 상속이나 인터페이스 등을 쓸때에 유용한 명령들이라 보여진다.(토달지 말자..) 초보선에서는 rename 과 move 만으로도 충분히 위력적이었다. 메소드의 파라메터 내용을 단체로 고쳐주기도 한다. 잊어버린 부분 없이 모두 고쳐준다는 것이 큰 장점이다.

java 메소드가 아닌 jsp 상의 이름들은 search 기능을 이용해서 바꿀 수 있다. 찾은 후에는 매우 편리하게 replace 할 수 있는 환경이 있다. 이기능 역시 매우 맘에 든다. 프로젝트나 폴더 위에서 ctrl-H 를 누르면 찾기 창이 나온다. 마치 윈도우에 있는 '찾기' 처럼...

일부러 패키지 이름과 메소드 명을 대충 붙여서 작업했다. 그리고 중간에 크게 한번씩 들어다 놨다. 다 예상대로 잘 됐는데 한가지, 패키지명이 중복이라고 바뀌지 않는 경우가 있다. 해결법이 없으려나. 결국 그냥 치환기능으로 다 처리했다. 


- cvs

혼자서 작업하던터라 cvs 는 굳이 사용안해도 될 듯 했지만, 어짜피 해야할 기능 마저 하기로 했다. 기존에도 cvs 는 사용했으나, 기본적으로 올리고 내리는 커맨드만 알고 있던 터라서 가장 중요하게 생각되는 버전관리나 브랜치 등은 이용해 보지 못하고 있던 차였다. 

소스트리에 등록하고 다운 받고 하는 부분은 그냥 그려러니 하고 넘어가졌다. 그다음 히스토리가 관리되고 이를 되돌리거나 읽어오거나 하는 부분은 생각보다 쉽게 되었다.  이제 드뎌 소스가 엉켜도 이전으로 돌아가는 일이 자유로와 졌다. 

아직 작업중인 프로젝트가 마무리가 안되고 있는 관계로 브랜치와 버전에 대해서는 실험하지 못하고 있다. v1.0 이 되면 제대로 테스트 해 볼 수 있으려니 한다.

또한 cvs 로 관리해서 좋은 점은, 서버상에 개발소스를 반영할 때 매우 편하다는 장점이다. 주로 linux 서버를 이용하는데 update 된 내용만 다운 받아서 ant 로 때리면 컴파일 된다. 참고로 이클리스에서도 ant 의 build.xml 을 만드는 환경을 지원한다고 하나, 좀 헤매다 포기했다. 찾으면 그때 다시적겠다.

하여간 따로 써도 참 좋은 툴이다. 개발자가 2명 이상이라면 꼭 쓰자. 이전에는 커맨드가 귀찮아서 못 썼다면 이젠 그런 변명은 버려도 될 듯.


- junit

junit 에 대한 한가지 오해가 있었다. 이걸 깔기만 하면 이것이 내가 만든 프로그램을 완전 자동으로 테스트해주는 그런 넘으로 알고 있었다. 그래서 매우 신기하게 생각했다. 그런데 정체를 알고보니 그렇게까지 훌륭한 넘은 아니었다.(넘 무리한 요구였을까.) 

굳이 XP 개발론을 들먹이지 않더라도 완선된 모듈의 테스트는 중요하다고들 한다. 정작 본인도 별로 테스트 모듈을 만드는 편은 아니다. 그러나 독립적인 util 이나 중요알고리즘 부분을 작성할 때는 테스트가 꼭 필요하다. 정작 junit 으로 편해진건 테스트를 어떻게 하느냐가 아니라, 테스트 하는 넘들만 따로 모아 놓았다는 점이겠다. 

지금 하는 부분이 웹부분이라서 전체적인 흐름에 대해서는 테스트가 불가능했다. 물론 struts 의 경우는 테스트 모듈이 있다던데 안해봐서 모르겠고..역시나 유틸이나 주요 로직에만 테스트 모듈을 만들어 놨다. 이클립스에 junit 이 있어서 확 편해졌다기 보다는 있으니 자주 활용하는게 어떻겠냐는 정도의 느낌이다.(아직까지이지만 어찌 생각 바뀔지는 모른다.)


- debug

이전까지 debug를 써본적이 없어서 잘 모르겠다. java application 라면 활용도가 많아 보인다. 디버그의 묘미는 역시나 메모리 값이 보인다는 것이라 생각된다. 적당한 곳에 브레이크포인트 찍고 기다리면 중간에 있는 변수들의 값이 변하는게 모두 보인다. 어떻게 해서든 system.out.println 을 줄여보자는 의도인데 요즘은 log4j 같은 로그툴을 활용해서 로그를 간수하므로 둘이 적당히 쇼부보면 될 듯 하다.

실제로 사용해 보기는 이번이 처음인데, StringBuffer 의 내용이 점점 차가는 과정을 눈으로 볼 수 있다는게 신기했다. 잘쓰면 역시나 멋있는 기능인 듯.

그러나 web application 작업에 있어서는 아직까지 도움을 못 받고 있다. 원격 디버깅이나 모니 하면 된다는데, 아직 시도하진 않고 있다. jsp 개발에는 다들 비협조적이라는 생각이 드는 건 왜일까. junit 과 더불어 유틸리티 모듈 개발에는 적당한 도움들이 되었다. 

 

3. 아쉬운 것들.

이클립스를 사용한지 이제 2달정도가 되어 간다. 이제는 어느정도 정리가 되어 간다고 생각된다. 물론 늘 쓰는 기능만 쓰고 아는 기능만 알겠지만, 아쉬우면 또 찾아가면서 해결되리라 믿는다.

그러나 이쯤에서 끝끝내 아쉬운 점을 적어 본다. 이 내용들에 대해 해결법을 아시는 분들은 제발 답변을 바란다.


- 절대적 마이너스 속도/ 메모리 관리

이는 본인 개인적인 문제라 할 수도 있겠으나, 모든 개발자들이 펜티엄4에 널널한 램과 하드를 쓰는 것은 아닐 것이다. 더더욱 윈도우보다는 칙칙한 터미널 환경에 익숙하던 이들에게 화려한 GUI 를 위해 희생하는 속도와 램의 용량은 매우 큰 아픔이다. 여기에 jedit 까지 쓰려고 하니 죽어버리겠다. 

(개인적으로 이클립스보다 jedit 을 먼저 알게됐는데, 이때부터 자바 애플리케이션에 희망이 보이는 듯 했다. 멀티 플랫폼에서의 동작과 유니코드의 완벽한 지원 등. 조만간 맥 OS X 에서의 자바 개발을 하려한다. 왜? 이쁘잖어.)

프로그램중 어디서 메모리를 놓친건지.,이눔의 톰캣은 뻑하면 100M 를 넘게 쓰고 있다. 간혹 out of memory 도...이건 프로그래밍 잘못한 내죄지.

이클립스 자체도 하루에 2번 정도는 다시 띄워준다. -_-;

하나더. 이것저것 창 열어 놓으면 내 17인치 볼록 모니터에서 보기엔 웬지 좁아 보이는 건 왜일까. 이건 그냥 모니터 탓으로 돌리자.


- 찬란한 문법 하이라이트

물론 이제는 절제된 칼라감각으로도 표현이 가능하다는 것은 안다. 그러나 다량의 html 작업시에는 그냥 editplus 가 편하다. 직관적이고 띠어다 붙이기도 편하다. 근본이 html을 위한 편집기가 아니라 것은 인정한다. 


- jsp 지원 강화

여러가지 플러그인들이 있다고 하는데 테스트는 못해봤다. 솔라이클립스만 사용중이다. (롬보즈 인가는 깔아만 놓고 비사용중이다.) JSP 에서도 java 처럼 자동완성이나 문법 체크 등이 됐으면 좋겠다. 더불어 디버깅도 어케 하는지 알았으면 한다. 


- 그외 자잘한 질문

word wrap 이라고 하나.. 화면 끝났으면 아래로 좀 떨어지지 계속 오른쪽으로 표시하고 있나.. 이거 내리는거 아시는분?

굳이 컬럼 복사 기능 같은 것은 원하지도 않는다.

 

4. 마무리

이상으로 짧지만 나름대로 다양했던 본인의 이클립스 입문기를 마친다. 기본적인 내용이지만 다른 분들도 본인과 비슷한 과정을 통해 이클립스에 정이 들어갔으리라 믿는다. 그리고, 아직 시작하지 않은 입문자게 조금이나마 희망이 되었으면 한다.



반응형