[바미] 좋은 코드를 만들기 위한 노력.

세상에 수 많은 개발자들이 있는데 그 중에서 "저 사람 잘하네"라고 할 때 그 기준 중에 하나가 프로그램을 튼튼하게 만든다는 점에 있습니다. 튼튼하게 만든다는 것은 프로그램이 터지지 않는 것, 멈추지 않는 것을 의미합니다.

프로그램을 튼튼하게 만들기 위해 중요한 것 중에 하나가 '방어 코드'인데 실제로 정말 잘 짜여진 프로그램의 코드가 100%라 했을 때 실제 동작하기 위한 코드가 20%, 나머지 80%는 방어코드로 이루어져 있다고 합니다.

그래서 20%의 동작을 위한 코드는 내가 그렇게 되길 바라는 코드이고 나머지 80%는 그렇게 안되는 부분들을 막기위한 코드라 보면 되죠.

'20-80법칙'이라고도 하는데 방어코드를 잘 짜는 것 하나만으로 상위 20% 개발자에 들어설 거라 확신합니다.

간단하게 설명하자면 방어코드의 유형은 아래와 같습니다.

 

javascrpit의 경우

var a;

라 정의해도 됩니다. 그 이유는 a가 아직 int인지, string인지, 등의 타입이 a에 삽입되는 값에 따라 타입이 자바스크립트 엔진이 바꾸어주기 때문입니다.

 

저 상태에서 a는 정해진 값이 없기 때문에 아직 정해지지 않았은 값, 아직 할당하지 않은 값을 표현하기 위해 사용하는 값을 의미하는 undefind라는 값을 갖게 됩니다. (좋은 방법은 아니지만)

하지만 C와 같은 컴파일러 언어의 경우

int a;

위와 같이 정의 해놓으면 대차게 욕을 먹을 가능성이 큽니다. 그 이유는 int a;로만 해놓고, a를 출력하면 알게 될 것입니다.
혹시나 저기에서 a는 0일까? 0이라 생각하는 사람이 있다면 당장 확인해보기 바랍니다.
(0이 될 수 있지만 0이 되지 않을 때도 있다는 것 알고 계셨죠?)

그래서 항상 

int a = 0;

과 같이 변수를 초기화 시켜주어야 하는데 이 간단한 코드도 방어코드에 속합니다.

예를 들어보죠. a를 초기화 하지 않은 상태에서

a = b + c

라 했을 때 값을 만족하게 됩니다. 그 이유는 a = b + c라는 값을 넣었기 때문이죠.
하지만

b = a + c

를 하게 된다면 a를 초기화 시켜 사용하라는 IDE의 문구를 확인할 수 있을 것입니다.

그래서 IDE의 기능들은 대부분 사용자가 이러한 코드를 사용하지 않도록 도움을 줍니다.
'하이라이트'의 기능 또한 마찬가지이죠.

 

거기에 int형 범위에 맞게 사용 될 수 있게 하는 것 또한 방어 코드 중에 하나 일겁니다.

아래는 int형 범위를 나타낸 이미지입니다. 참고만 하세요~!

int형 범위

여기까지 변수안에서 알아 보았고, 함수로 넘어가볼까요?

function func(int a, string b) {
   int hi = a;
   string hello = b;
}

라는 함수가 있을 때 우리는 과연 a와 b가 제대로된 값이 들어갈 것이라 확신할 수 있을까요?

제가 개발해본 경험으로는 대부분은 제대로 된 값이 들어가지만 몇몇 경우가 그러하지 못했던 일이 있었습니다.

예를 들어 null값이나 undefind값이 들어갔음에도 그 함수가 정상 작동하였을 때가 있었죠.

그래서 저런식의 함수안에서는 

function func(int a, string b) {
   if (a == 'undefind' || a == null) {
     error();
   }
   if (b == 'undefind' || b == null) {
     error();
   }

   int hi = a;
   string hello = b;
}

위와 같이 생각하지 못한 값이 들어가는 경우를 체크하여 생각하지 못한 값이 들어왔을 경우 에러처리를 해주고, 제대로 된 값이 들어왔을 경우 정상 동작하도록 만드는 것이 습관이 되었고, 이것이 이 후에야 방어코드 중에 하나라는 것을 알게 되었습니다.

이는 모듈도 마찬가지 였습니다만. 간단하게 여기까지만 다뤄보도록 하겠습니다.

그리고 두 번째로 구조입니다. 좋은 코드의 가장 좋은 예는 당연한 코드만 있는 상태입니다.
불필요한 것을 없애고, 당연하게 남아있어야 할 코드만 남는 상태를 의미하는데 모두가 당연시 생각하지만 이렇게 짜기에는 정말 쉽지 않죠.

많은 개발자들이 이상적으로 생각하는 코드의 형태?가

이런식으로 심플하게 흘러가는 프로그램일 것입니다.
하지만 늘 그렇듯 우리가 개발해야 하는, 개발하고 있는 코드는 저런 형태가 아니죠.
언제나 그렇듯A에서 B로 흘러가는 과정에서 수 많은 장애물이 있을 겁니다.

이 장애물들을 넘어가기 위해 미로처럼 돌아가는 것은 어쩔 수 없지만 타당한 장애물이 없음에도 아래와 같은 모습들을 항상 경험하곤 합니다.

지금까지 살펴본 2가지의 경우만 놓고 보더라도 코더와 프로그래머를 나눈다고 합니다.
코더라고해서 나쁜건 아니지만 개발자의 밈?만 보더라도 좋은 표현은 아니죠.

프로그램을 튼튼하게 짠다라는 것은 정말 힘든 일입니다. 많은 경험을 통해 만들어지는 것이지 않을까 싶습니다.

오랜 기간 개발을 해왔어도 우리가 모르는 버그가 언제든지 도사리고 있는게 우리의 코드가 아닌가 생각해봅니다.
방어 코드를 생각하면서 제가 그 동안 어떤 개발을 하고 있었나?, 내가 지금까지 코더로써 개발을 하고 있는지,

개발자로써 개발을 하고 있는지에 대한 생각이 들었습니다. 앞으로 더 튼튼한 코드를 만들 수 있도록 성장하길 소망해봅니다.

지금까지 간단하게나마 '좋은 코드'란 무엇일까에 대해 간단하게나마 알아보았습니다.

덧붙일 얘기, 틀린 부분을 알려주신다면 너무 감사할 것 같습니다. 긴 글 읽어 주셔서 감사합니다.