자바 개발자가 가져야 할 기본

참고 : 영록이 블러그

http://youngrok.com/wiki/wiki.php/%C0%DA%B9%D9%C0%A5%C7%C1%B7%CE%B1%D7%B7%A1%B8%D3%C0%C7%B1%E2%BA%BB#s-4.2.7

인터넷 검색을 하다 좋은 글을 발견하여 참고 삼아 정리해 작성한 글입니다.

 

  

 

프로그래밍 초보자가 능히 한 사람 몫을 할 정도로, 혼자 코딩하도록 내버려둬도 다른 사람들이 불안에 떨지 않을 만큼 성장하는 가장 빠른 방법은 무엇일까? 디자인 패턴을 공부하고 최신 기술을 익히고 실전 프로그래밍을 많이 해보는 것? 물로 중요하다. 그러나, 이보다 훨씬 더 중요한 것은 기초를 다지는 것이다.

  

 

1. web.xml (배치 서술자, Deployment Descitper)

 

web.xml 은 웹 프로젝트를 구성하는데 있어 필수적이면서도 웹 애플리케이션의 동작을 조정하는 역할을 한다.

 

 

2. 예외 처리

 

자바의 강점 중 하나가 편리한 예외 처리 방식이다. C언어 등 예외 처리 문법이 없는 언어를 먼저 접한 프로그래머에게는 생소한 개념일 수 있겠지만 알면 알수록 편리한 것이 자바의 예외 처리이다. 하지만 이외로 많은 자바 프로그래머들이 예외 처리를 어려워하고 예외 처리를 제대로 하지 않아 여러 가지 문제를 발생시킨다. 기본이라고 할 수 있는 부분이긴 하나 사실 이것은 자바의 예외 처리 문법만 배운다고 되는 문제는 아니며 예외 처리에 대한 많은 고민이 필요하다.

 

특히 웹 애플리케이션의 예외 처리는 프로그래머를 위한 부분과 웹 사이트 방문객을 위한 부분 두 가지를 모두 고려해야 한다. 먼저 프로그래멍의 입장을 살펴보자. 예외가 발생하면 어디까지나 그냥 던지고 어디서 캐치하는 것이 좋을까? 자바의 예외는 자바 코드의 모든 영역에서 발생할 수 있다. 이 모든 영역에 다 try-catch를 걸고 예외를 잡을 수는 없는 일이다. 대부분의 예외는 일단 그냥 던지는 것이 좋다. 자바의 예외가 좋은 것은 꼭 예외가 발생한 그 지점에서 처리를 하지 않아도 된다는 것이다. 예외를 던짐으로써 예외를 처리하기에 적절한 위치에서 처리하게 만들 수 있다. 어떻게 처리해야 할지 잘 모르겠다면 그냥 그대로 던지도록 하는 것이 좋다. 예외를 잡아서 처리해야 하는 곳은 일반적으로 사용자에게 화면을 보여주기 직전이며 이것은 웹 애플리케이션이 MVC 패턴으로 작성되어 있다면 컨트롤러에서 이 역할을 하게 된다. 컨트롤러에서 예외를 보고 판단을 해서 사용자에게 보여줄 화면을을 결정하는 것이다.

 

웹 사이트 방문객을 위해 중요한 것은 자바 예외가 발생했을 때 이해할 수 없는 시스템 에러 메시지나 스택 트레이스 등의 황당한 화면이 아닌 친절한 에러 메시지를 표시해주는 것이다. 이를 위해서는 컨트롤러에서도 처리하지 못하고 던졌던, 정말 예상 밖의 예외를 모두 끌어모아서 처리하는 부분이 필요하다. Servlet/JSP에서는 이런 부분의 처리를 위한 기능을 여러 가지 제공하고 있고 스트럿츠 등의 프레임워크에서도 다양한 방법을 제공하고 있다. (서블릿 컨테에너의 web.xml 에 상황에 따른 에러 페이지 지정하기)

 

  

3. 로깅

 

에러 페이지에서 해야할 또 하나의 중요한 일은 예외 상황에 대한 로그를 남기는 것이다. 에러 페이지까지 왔다는 것은 이미 개발자의 예상을 벗어난 동작을 하고 있다는 것이므로 이 사실을 개발자에게 빨리 전달되어야 한다. 때문에 로그를 제대로 남겨서 조회하기 편한 시스템을 구축해야 한다. 로깅 API는 여러 가지가 있고 JDK 자체에도 포함되어 있지만 log4j가 가장 널리 사용되고 성능, 기능, 안정성 등 여러 가지 면에서 다른 것들보다 낫다.

 

  

4. NullPointerException 처리

 

초보자를 괴롭히는 문제는 NullPointerException 이다. 사실 이것은 초보자에게는 아주 까다로운 문제지만 조그만 알면 가장 찾기 쉬운 문제 중 하나다.

 

if ( "Y".equals(param) ) {

    doSomeThing();

}

else {

    doOther();

}

 

위와 같이 param에 null체크가 귀찮아서 이런 식으로 코드를 쓰곤 하는데 만약 Param의 값이 Y인 경우는 doSomething()을 실행하고 N이나 null 이면 doOther()를 실행해야 하는 경우라면 이 코드는 문제가 없다. 그러나, 만약 param null이면 안되는 상황이라면 어떻게 될까? 다른 부분의 버그로 param에 null이 들어와도 프로그래머는 이것을 알아 차리지 못하고 넘어가게 된다. 즉, 버그를 은폐하는 코드가 된다. 당장의 문제를 발생하지 않더라도 이런 코드는 나중에 찾기 힘든 문제를 유발할 수 있다. 이런 경우 그냥 NullPointerException 이 발생하도록 내버려 두면 param에 null값이 들어왔을 때 다른 부분에 버그가 있기 때문이라는 사실을 감지할 수 있다. 상황에 따라 위와 같은 코드를 써도 되는지를 신중히 검토한 후 사용해야 한다. 예외 발생이 두려워서 버그를 은폐할 수 있는 코드를 만들지 말자.

 

  

5. 문자 인코딩

 

자바는 문자열과 바이트 스트림을 다르게 취급한다. 자바의 스트링은 유니코드의 문자셋을 사용하며 문자열을 파일에 쓰거나 네트워크로 전송하는 등 실제 입출력이 일어날 때는 문자열을 바이트 스트림으로 변환하게 된다. 이 때 바이트 스트림으로 변환하는 규칙이 인코딩이다. 따라서 바이트 스트림으로 전달된 것을 문자열로 바꾸거나 문자열을 바이트 스트림으로 전달할 때는 반드시 인코딩을 지정해 주어야 한다.

 

이런 인코딩 중 한글을 표현할 수 있는 인코딩은 자바에서 사용하는 이름을 기준으로 EUC-KR, UTF-8, UTF-16 정도가 있다. EUC-KR은 KS5601-1987에 기반한 인코딩으로 한글의 모든 문자를 다 표현 할 수 없다. UTF-8과 UTF-16은 유니코드의 인코딩들로 모든 한들을 표현할 수 있고 표준이며 한글 이외의 다른 캐릭터셋과 함께 표현이 가능하다.

 

URL 인코딩은 URL에 사용가능한 문자가 제한되어 있다. URL 스펙에 정의된 바로는 URL에 사용할 수 있는 문자는 알파벳, 숫자와 몇 가지의 특수 문자 뿐이다. 따라서 다양한 문자들을 URL로 전달하려면 URL에 허용하는 문자로 변환시켜서 전달해야 한다. 이것은 GET 요청의 파라미터로 값을 전달하려고 할 때 문제가 된다.

 

 

무엇을 알아야하는가를 가르쳐주는 것은 스펙이다. 스펙 문서들은 대부분 영어이고 그다지 친절하게 되어 있지 않지만 해당 분야에 대해 가장 정확한 정보를 담고 있다. 자세한 내용을 다 알진 못하더라도 스펙에 어떤 내용이 있는가 정도는 알아야 그 내용 중 자신에게 필요한 내용을 찾아서 공부할 수 있는 것이다. 이런 정보를 어디서 찾을 수 있는가를 알고 있는 것도 중요하다.

 

많은 프로그래머들이 실제로 자기 손으로 프로그래밍 해보는게 실력이 느는 제일 좋은 방법이라고 말하지만 여기에 동의하지 않는다. 물론, 실제 경험을 쌓은 것이 필수적인 과정이긴 하다. 그러나, 기본 지식을 등한시한 상태에서 코딩만 해보는 것으로는 실력이 잘 늘지 않는다. 코딩 기술은 늘 수 있겠지만 정말 실제 서비스를 해야하는 프로그래밍에서 중대한 실수를 저지르게 되거나 남들이 쉽게 하고 있는 일들을 어렵게 빙 둘러가면서 하게 될 수 있다. 그래서 기본기를 갖추는 것이 중요한 것이다.

 

거듭해서 기본의 중요성을 강조했는데 한 가지 덧붙이고 싶은 말은 이런 기본 지식 뿐 아니라 기본을 활용하는 능력을 키우는 것도 잊지 말아야 한다는 것이다. 앞서 언급한 예외 처리 같은 내용은 기본이긴 하나 자바 문법만 잘 안다고 알 수 있는 내용들이 아니며 기본을 바탕으로 좋은 판단을 내릴 수 있는 능력이 있어야 한다. 결국 좋은 프로그래머가 되려면 먼저 좋은 사고 능력을 가지고 있어야 하는 것이다. 글짓기를 잘하는 방법으로 흔히 다독, 다작, 다상량을 이야기한다. 많이 읽고 많이 쓰고 많이 생각하라는 것이다. 프로그래밍도 이와 비슷하다. 각종 스펙들과 좋은 코드들을 많이 읽어보고 직접 코딩도 많이 해보면 분명 실력이 늘지만 이것으로는 충분치 않다. 프로그래밍을 하면서 끊임없이 생각해야 한다. 지금 작성한 코드는 좋은 코드인가, 이렇게 코딩하면 불편한데 개선할 방법은 없을까?

 

 

프로그램을 작성하면서 항상 최선의 길을 찾는 것이 프로그래머라고 생각된다. 항상 배우고, 다양한 문서를 읽고, 스펙을 정리하고, 직접 코딩하고 이런 과정을 수 없이 반복하여 최선의 길을 찾는 일이 프로그래밍인 것이다.