초급 개발자 딱지를 떼려면 이 정도는 해야 한다

이번 글에서는 그 동안 자바 개발자들의 소스 코드를 많이 리뷰하면서 본 여러 문제점들을 정리하여 초급 개발자 딱지를 떼려면 어떤 것이 기본인지 정리해볼까 한다.

초급 개발자들은 경험 부족으로 이러저러한 실수를 한다거나 소스 코드에 폭탄을 심어놓는 경우가 있다. 아래 얘기하는 것들에서 어느 정도 준비된 사람이라면 적어도 내가 볼 때 우리나라에서는 초급 개발자가 확실히 아니라고 할 수 있겠다.

null 검사

우선 얘기하고 싶은 것은 null 검사다. null 검사를 하지 않는 경우 NullPointerException이라는 폭탄이 수시로 여기저기서 터지는데 그때그때 응급 조치만 하는 경우가 많다.

프로그램 세계에서 null은 수학에서 0과 같은 개념적 중요성이 있다. 고대인은 숫자 계산에서 0이라는 개념 또는 표현이 없었다고 한다. 하지만 인도에서부터 0이라는 개념이 도입되어 0도 숫자로 표시하고 계산함으로써 숫자의 영역이 한 차원 넓혀졌고 수학이 크게 발전할 수 있었다.

프로그램에서도 null은 명확히 처리해야할 대상이라는 인식을 해야 한다. 대충 무시하고 있다가 어디선가 일 생기면 허겁지겁 땜질할 것이 아니다. 기본적으로 개발자는 자신이 사용하는 모든 변수가 어디서부터 들어오는 것인지, 들어올 때 null일 수 있는지 아닌지를 항상 생각해야 한다. 어쩌다가 아니다. 기분 좋을 때도 아니다. 밤이나 낮이나 코딩할 때는 항상이다. 이게 습관이 돼야 좋은 프로그램을 만들 수 있다.

직접적으로는 NullPointerException이 발생하는 위치가 "객체.메서드"와 같은 형식으로 객체에 속한 필드나 메서드를 액세스하는 경우이므로 이러한 형태의 객체 사용을 반드시 점검해야 한다.

하드 코딩 자제

소스 코드에 숫자나 문자열이 보이는 경우 상당수는 하드 코딩을 남용한 경우가 많다. 0처럼 양수와 음수의 경계를 나타내는 명확한 조건, http:// 처럼 이미 약어로 굳어져 있는 프로토콜 등 아주 일반화된 상수인 경우, 그 밖에 단순 메시지 출력인 경우가 아니라면 소스 코드 선언부 외에는 하드 코딩된 상수를 가능하면 사용하지 않아야 한다.

좋은 방법은 어떤 상수가 외부로부터 들어오는 경우 분명 어떤 변수가 있었을 것이고 그 변수를 계속 사용하는 것이다. 변수로부터 나오는 게 아니고 정말 프로그램 내내 바뀌지 않는 상수라면 소스 코드의 선언부에 final 상수로 선언하는 것이 맞다.

private final String SUCCESS = "01"

이 외에 시스템적인 환경 변수 값을 하드 코딩하는 경우가 있는데 이 역시 위험하다. 우리나라 개발자들은 대부분 윈도(Windows)에서 개발하는데 운영 환경은 Un*x 계열인 경우가 많다. 개발할 때 줄바꿈 문자라든가 폴더 구분 문자라든가 하는 것들이 환경에 따라 바뀔 가능성을 염두에 둬야 한다. 예를 들어 폴더 구분 문자를 "\\"과 같이 하드 코딩하지 말고 File.separator라고 쓰는 것이 맞다.

코드 서식(formatting)

코드 서식은 형식적인 것이긴 하지만 좋은 프로그램을 만드는 개발자 치고 엄격한 스타일을 지키지 않는 사람이 없다.

코드 서식은 개발자의 코드 품질을 직접적으로 나타내지는 않지만 어느 정도는 코드 품질을 단적으로 나타내는 간접적인 요소다. 비유를 하자면 사회 생활하는 멀쩡한 사람이 옷이 찢어져 있다거나 침을 흘리고 다니지는 않지 않겠는가?

다음은 몇 가지 신경 쓸 코딩 서식의 기준이다. 이러한 기준을 일관되게 지킬 때 초급 개발자가 아니라고 할 수 있다. ("일관되게"라는 것은 본인이나 프로젝트에서 정한 기준을 계속 지키는 것을 말한다. 이쪽 소스에서는 이렇게, 저쪽 소스에서는 저렇게 작성하지 않는 것을 말한다.)

• 들여쓰기를 탭으로 하는가, 스페이스(빈칸)로 하는가? 칸 수로는 몇 칸을 하는가?
• 키워드와 문장 부호, 변수, 연산자 등에 대해 띄어쓰기는 어떻게 하는가? 어디는 띄우고 어디는 붙여쓰는가?
• 대괄호 [], 중괄호 {}, 소괄호 () 등의 괄호는 어디에 위치시키는가? 줄바꿈을 어디서 하고 띄어쓰기는 어떻게 하는가?

초급 개발자는 프로젝트에서 정하는 코드 서식을 일일이 머리에 담아두고 지키기 힘들 수 있다. 이때 자바에서는 아주 유용한 방법이 있다. 프로젝트의 코딩 스타일을 이클립스(Eclipse)에서 설정해 두고 소스 코드 공유(버전 관리 등)를 통해 팀원 간에 공유하는 것이다. 이렇게 하고 코드 작성할 때 모르겠으면 ctrl-shift-f만 누르면 해당 서식에 맞게 소스 코드가 자동 정리된다.

오타 주의

우리 회사에 전에 오타의 여왕이라고 있었다. 프로그램이 뭐가 잘 안풀린다고 질문을 해서 가보면 열에 다섯, 여섯번은 오타가 문제인 경우였다. 여자 개발자들은 남자 개발자보다 성격적으로 질문을 좀더 잘해서 내가 볼 기회가 많았기 때문인지 모르겠는데 여자 개발자들에게 이런 문제가 많았다.

아무래도 영어로 프로그램을 짜다 보니 오타가 있을 수 있다. 익숙하지 않으므로. 하지만 이런 사소한 실수가 몇 시간을 못 푸는 문제의 원인이 되기도 한다. 깐깐하게 하자면 소스 코드 타이핑할 때 한 글자, 한 글자에 주의를 기울여야 한다. 이런 식으론 처음에 시간이 오래 걸리지만 나중엔 오타가 아주 쉽게 보일 것이다. 운전과 비슷하다. 처음 운전할 때 사소한 동작 하나, 하나가 신경 쓰이지만 익숙해지면 일상적인 동작은 문제 없이 자동으로 하게 되고 중요한 행동만 신경 쓰게 되는 것이다.

문서 작업

우리나라 프로젝트에서 포멀한 문서 작업은 개발자의 업무에서 상당한 분량을 차지한다. 따라서 이에 맞춰 MS Office라든가 아래아한글과 같은 프로그램을 익숙하게 사용하는 것이 필요하다. 문서 작업을 메모장 작업이나 마찬가지 수준으로 하는 개발자들이 상당수인데 다음 작업은 기본적으로 알아야 한다.

• 제목, 본문 등의 문단 서식을 프로젝트 표준으로 지정해 반복 사용할 수 있기(HTML/CSS와 비슷한 관계이며 코드 서식과 마찬가지로 일관돼야 한다)
• 목차(또는 차례) 자동으로 만들어 넣기

추가하자면 문서 정보를 나타내는 변수 사용, 참조 관계에 따른 링크 넣기 등도 유용한 작업 방법이므로 알아두면 좋다.

결론

사실 좋은 프로그램을 만들기 위해 개발자가 알아야할 것들은 책으로도 많이 나올 만큼 중요한 주제지만 내가 경험한 바에 의한다면 한국 개발자들이 잘 하는 것들을 제외했을 때 위와 같은 것들이 기초적이지 않을까 싶다. 비단 초급 개발자만의 문제도 아니다. 경험도 중요하고 기술도 중요하고 비전도 중요하지만 결국 초급이라는 딱지를 위해서는 "기초"가 잘 닦여 있어야 할 것이다.