본문 바로가기

Programming

[programming] 가독성..?

-- 본 글은 글쓴이의 주관이며 동의하지 않으시거나 첨언을 해주실 때에는 댓글, 혹은 트위터를 이용해주세요. :)

프로그래밍을 시작할 때에 hello world 를 찍고 그 다음에 접하는 것은 무엇일까요?
보통 변수의 선언과 초기화라고 생각합니다. (data)
그리고 이어서 그 변수를 어떻게 가공할지 메소드를 작성하지요. (algorithm)

이때 처음 프로그램을 접할 때에 우리는 변수명을 x, a, i, j, k 그냥 마구 나열해서 선언하고 초기화합니다.

시간이 지나면서 x가 operand가 되고 a가 temp가 되고 i가 count가 되고 j가 innerCount가 되고 k가 result가 됩니다. 
점차 프로그래밍을 하면서 초기화가 이루어질 data에 대해 이해를 하고
algorithm에 있어서 이 variable들이 어떤 역할을 하는지에 대해 고민을 하기 시작하는 것이죠.
그리고 마침내,
예전에 작성하였던 소스를 돌이켜보면서 본인이 작성한 코드를 본인이 몰라보는 현실이 너무나 싫어져서,
혹은 작성한 소스를 기반으로 추후에 다른 사람이 유지보수 등을 하거나 프로젝트 자체를 협업하게 되는 경우 등등으로 

작성한지 한참 후에도 누구나 이해할 수 있도록 변수 선언시나 메소드 선언시에 고민을 하면서 코드를 작성하게 됩니다.

이 과정이 가독성 평가항목 중 하나인 naming입니다.

가독성이란 프로그램 코드를 작성할 시에 사람이 이해할 수 있는 정도를 뜻합니다.
여기에는 앞서 말한 네이밍을 포함하여 여러가지의 항목들이 있습니다.

제가 고민한 가독성의 평가항목들은 아래와 같습니다.
1. 목적에 의한 네이밍, 그리고 일관되는 네이밍룰.
2. 들여쓰기에 의한 brace의 명시
3. 명확한 패키지의(폴더) 조직화
4. 쓸데없는 중복의 최소화
5. 주석을 통한 각 클래스와 메소드변수에 대한 더이상 뺄 것이 없는 안내.
6. enum 클래스의 활용을 통한 경우의 수들 제어
7. DTO 사용
8. 진행중인 프로젝트에 참여하게 되었다면 기존 프로젝트의 스타일에 나를 맞추기.    


들여쓰기에 의한 brace의 명시는 코드를 이해하는데 아주 큰 도움이 됩니다.
반복문이나 조건문 등을 사용할 때에 그 제어문 내에서 어떤 로직이 수행되는지 명확히 이해할 수 있기 때문이죠.
그래서 단 1개의 로직만을 제어문 내에 작성할 때에도
컴퓨터는 괄호가 없더라도 로직을 작성자의 의도대로 이해하고 기능을 수행하겠지만
저는 반드시 중괄호로 로직을 감싸도록 합니다.

명확한 패키지의 조직화는 파일들을 분류하여 관리하는데에 큰 도움이 됩니다.
또한 작성중인 코드를 보다 더 응집도를 높일 수 있게 하고, import 코드에 대한 이해를 하는데에도 도움이 되지요.
만약 패키지를 각 기능등에 따라 분류하여 관리하지 않고 한개의 폴더에 마구잡이로 넣어놓고 프로젝트를 수행한다면
파일을 찾는데에만 꽤 시간소요가 있을 것입니다. 그리고 코드를 작성할 때에도 어쩌면
이기능 저기능이 마구 들어가있는 수퍼 짬뽕 클래스를 만들어낼수도 있습니다.

쓸데없는 중복의 최소화는 반드시 명심해야하는 부분이지요.
중복은 우선... 남들에게 보이기 부끄러운 코드입니다. 남들에게 무시당하고 신뢰를 잃을 수 있는 코드이지요...ㅠㅠ
그리고 중복된 코드들을 그 코드들 사이에 어떠한 차이점이 있는지 이해하기 위해 시간을 많이 소요하게 만듭니다.
최초 작성시때부터 계속 힘든 작업이 요구되는 스타일이기도 합니다. 반드시 중복을 최소화하여야 합니다.

주석은 코드에 대해서 이해를 하는데에 큰 도움이 됩니다.
제가 코딩시에 크게 도움을 받으면서 스스로는 잘 못하는 부분이기도 하죠^^;;
주석은 로직 자체에 참여하지 않기때문에 남발되는 경우가 다반사입니다.
주석을 달 때에도 이 주석의 이 뜻이 과연 꼭 필요한 것인지 스스로 물을 필요가 있습니다.
주석이 과하면 코드를 이해하려 하기도 전에 질려버릴 수 있으니까요.
하지만 적절한 주석은 변수와 메소드, 그리고 클래스에 대한 이해를 크게 돕고 작업이 무척 수월해집니다.
이것은 귀찮을 수도 있는 부분이지만, 가독성을 생각한다면 반드시 필요한 작업이지요.

전 enum을 꽤 좋아합니다.
상수를 사용하면서 코드를 작성하는 것은 관련 코드 전체를 훑어보면서 이해하여야 합니다.
무척 번거롭고 또한 스스로 기억에만 의존하기에도 결코 안전치 못합니다.
로그인 프로세스 중에 패스워드를 잘못입력하여 에러가 발생한 경우를 처리한다면
login = 2;
login = INVALID_PASSWORD;
위와 같은 코드를 작성할 수 있는데, 위와 아래. 어느 코드가 더 이해가 빠를까요?

DTO 사용은 프로그램 작성을 너무나 편리하게 해주고 또한 이후 유지보수시에도
꽤 고마운 작업이 가능해집니다.
우리는 프로그램을 개발할때 어찌되었던 data를 가지고 어떤 가공을 행합니다.
이 작업에 진행하는데에 있어서 data를 객체로 만들지 않고 기본형만을 가지고
작업을 진행하게 된다면 작업소요도 길어질 뿐더러 코드도 지저분해지기 일수입니다.
따라서, 목적에 부합하는 data만을 가지고 있는 객체가 있을 필요가 있습니다.
예를 들어 일반적인 게시판의 data로 작성자, 작성일자, 제목, 내용, 조회수만 있다고 가정해봅시다.
이때 각 data를 담을 그릇과도 같은 DTO를 만들지 않는다면 저 data들을 어떻게 관리해야할까요?
Map 형태의 객체에 저 data들을 그냥 박아넣어야할까요?
그렇지 않다면 일일이 각 data를 얻거나 가공하기 위해 여러개의 메소드를 만들어야할까요?
(어찌되었거나 data를 가공하기 위해서 메소드를 만든다면 그 메소드는 1개의 객체만을 return하지요.)
작성자, 작성일자, 제목, 내용, 조회수에 해당하는 기본형의 변수를 필드로 가지고 있는
DTO를 만든다면 아주 작업이 편리해지고 코드량도 무척 줄어들며
DTO 네이밍을 게시판에 맞게 잘 정해준다면 아무래도 가독성이 무척 편리해지겠죠?

그리고..어떤 프로젝트를 수행하던지 그 문화의 스타일에 맞추어 작업을 해야합니다.
프로그램이 완성되고 또 유지보수가 있으면서 사람은 바뀔 수 있습니다.
하지만 그 프로그램에 대해서 프로젝트 구성팀은 바뀌지 않지요.
(프로그램을 타사에 넘기거나 SI사업에서 프로젝트 개발팀과 유지보수팀 같은 경우는 논외로 하겠습니다.)
만약 새로이 팀이 구성되어 새로운 프로젝트를 수행할 경우에는 처음에 가독성에 대해서
어떤 룰을 정할 수 있는데, 이때 본인의 스타일을 요구할 수 있을 수 있고 팀 전체에 반영을 요구할 수 있습니다.
하지만 룰이 이미 있는 경우의 프로젝트를 수행중이라면
반드시 그 스타일에 맞추어야 한다는게 제 생각입니다.
물론 꼭 그렇게 해야하냐고 반박할 수 있겠습니다.
직관적인 부분들은 상대적일 수 있는 것이고, 또한 익숙해지는 정도의 차이일 수 있겠습니다.
그러나 그런 상대적인 부분이 갑자기 툭 튀어나온다면 팀내의 다른 이들이 보기에 좀 당혹스럽지 않을까요?

이상 제가 생각하는 가독성에 정의해보고 그것을 위한 항목들을 나열해보았습니다. 
서두에도 말했듯이 프로그래머가 작성한 코드는 영원히 공개되지 않을 수가 없습니다.
(정~~~~~~~말 혼자 재미삼아 작성하고 버릴 코드들은 논외로 하구요^^;)
따라서 (이 포스트의 범위밖이지만) 확장에는 열려있고 변경에는 닫혀있는 코드를 작성하라는
OCP원칙을 중요하게 여기는 것입니다.
어찌되었건 훗날 코드가 공개될때 알아보기도 힘든 코드이고
상속을 받건 어쩔 수 없이 코드에 수정을 가하건 앞이 깜깜해지는 코드라면 엄청 욕먹겠죠?
가독성이 좋은 코드를 작성한다는 것은 깔끔한 코드를 작성한다는 것이고,
이는 협업을 하는 데에 있어서 필수적인 스킬입니다.


컴퓨터가 이해할수 있는 코드는 어느 바보나 다 짤수 있다.
좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다. - 마틴 파울러