[읽기좋은 코드가 좋은 코드다] 표면적 수준에서의 코드 개선

본 포스팅은 읽기 좋은 코드가 좋은 코드다.의 첫번째 챕터인 표면적 수준에서의 코드 개선 중에 몇가지 새로 알게 되었거나, 생각하게 되었던 내용들을 바탕으로 작성된 글입니다.

가독성

코드에서의 가독성 이라고 하면 흔히 보기 좋게 라는 단어가 먼저 떠오른다. 하지만 왜 보기 좋아야 하는것일까?를 생각해보면 더 깊은 본질을 알 수 있다.

여기에서는 소프트웨어의 본질이 개입한다고 볼 수 있다. 소프트웨어는 본디 하드웨어의 동작을 쉽게 바꾸기 위해 만들어진 기술이다. 즉, 하드웨어의 동작을 쉽게 바꾼다 라는 말 안에 변경이 자주 일어난다 라는 의미도 포함되어 있다고 볼 수 있다.

저자는 가독성을 다음과 같이 정의한다

코드를 읽고 이해를 하기 위한 시간을 최소화 해야 하는 값이다.

즉, 내가 되었건, 남이 되었건, 코드를 쉽게 이해하고 해석할 수 있어야, 빠르게 동작을 수정할 수 있다는 것이다.

Get, Set 등등의 표현

개발에서는 Get, Set 등과 같이 많이 사용되는 용어들이 있다. 하지만, 흔히 쓰이는 만큼 병패도 존재하게 된다.

보통 Get, Set을 만나게 되면 단순히 어떤값을 반환하거나 세팅해주는 정도로 생각하기 쉽다.

그래서, 협업을 하면서 어떤 개발자가 다음과 같은 코드를 사용했다.

for(int i = 0; i < 1000000; < ++i)
{
	SomeObject.GetNumber();
}

어떤 일을 하는지는 모르겠는데, 100만개의 요소에서 어떤 숫자를 가져오고 싶었나 보다. 보통 GetNumber 라고 하면 특정 숫자만을 반환한다고 생각하기 때문에, 100만개를 모두 순회하며 연산을 하여도 성능에는 크게 지장이 없을것이라고 생각한다.

하지만, 저 GetNumber를 만든 개발자는 다음과 같이 코드를 작성하였다.

public int GetNumber()
{
	int heavyCostNumber = 0;
	//어떤 오브젝트를 할당해서
	//엄청 복잡한 식을 계산한 다음
	return heavyCostNumber;
}

알고 보니, 특정 멤버의 값만 반환하는것이 아니라, 엄청나게 비용이 많이 들어가는 연산을 한 후에, 결과를 반환하는 함수였다.

이렇게 되면, 이유를 알 수 없게 성능저하가 일어날 수 있다. 또한, 처음 호출한 개발자는 저 함수 구현을 보지 않기 때문에, 최적화를 할 수 있는 여지조차 줄 수 없다.

따라서, 많이 사용되는 용어 같은 경우 그 용어의 의미를 정확하게 파악한 후에 사용해야 한다.

위와 같은 함수라면, ComputeNumber() 또는 CalculateNumber()정도가 적당해 보인다.

경계의 숫자들

리스트나 배열을 사용하면, 그 안에 들어가 있는 특정 자료들을 사용할 때, 이것이 포함(inclusive)인지, 미포함(exclusive)인지를 알기가 힘들다. 이 책을 읽다가 알게 되었는데, 이것도 많이 사용하는 용어가 있다.

경계를 포함할 때 first (inclusive) ~ last (inclusive)

경계를 포함하고, 배제하는 범위 begin (inclusive) ~ end (exclusive)

코드의 열 맞추기

코드를 작성하다 보면, 공통된 의미를 가진 변수들이나 함수들이 많이 생기는 경우가 있다. 나는 보통 줄 맞춤을 하진 않는데, 저자는 필요한 경우 줄맞춤을 하는게 좋다고 한다. 다음과 같은 경우이다.

int step_first   = 0;
int step_second  = 1;
int step_third   = 2;
int step_fourth  = 3;
int step_fifth   = 4;

나는 보통 IDE의 줄맞춤 기능을 많이 사용하기 때문에, 해당 기능은 많이 사용하지 않는다.

주석에 관한 이야기

정말 잘 작성된 코드들을 보면, 주석이 필요없이도 이해가 가능한 코드들이 있다. 이 책을 읽기 전까지 나는 그런 코드들에 매료되어, 나도 그런 코드를 짜봐야지 라는 생각으로 주석 대신에 코드를 더 깔끔히 만들자 라는 취지로 주석을 거의 달지 않았다. 하지만, 이 책을 읽고 나서 생각이 조금 바뀌었다.

우선, 주석의 본질이다. 주석은 코드를 읽는 사람이 코드를 작성한 사람만큼 코드를 잘 이해하게 돕는데 있다. 반대로 이야기 하면, 코드를 작성한 사람이 내 코드를 보자마자 잘 이해하게 된다면, 주석이 필요없다는 것이다. 하지만, 사람마다 스타일이나, 생각이 다 다르기 때문에, 아무리 좋은 코드라도 특정 사람에게는 잘 안읽히는 경우가 있다. 이것을 이번에 협업을 하면서 깨달았다.

그러면, 어떨 때 주석을 다는것이 좋을까? 저자는 다음과 같이 정의한다.

주석을 달지 말아야 할 것

1. 코드 한줄마다 그 코드를 설명하는 주석
2. 빠르게 유추할 수 있는 코드
3. 나쁜이름에 달리는 주석(이름을 바꾸자)

주석을 달아야 하는 곳

1. 코드를 작성할 때 내 생각 및 의도
2. 코드의 결함
3. 상수의 의미에 대한 설명 (왜 이 값이 상수에 들어가있는지)
4. 코드를 사용하는 예시
5. 함수의 동작 방식

이번에 게임을 만들 때, 상호작용 하는것들도 많고, 코드들이 많아지니까 내가 썼던 코드까지 까먹는 경우가 있었다. 진짜 지금까지는 프로젝트 하면서 그런적이 없었는데, 게임은 다르다는걸 느끼면서 주석을 잘 달아야겠다고 생각했다.

ReadableCode 카테고리 내 다른 글 보러가기