Broken Code (window31)

아으 거의 한달만에 글을 쓰는거 같네요...
2월에는 개인적인 일도 많았고 그밖의 사건사고도 끊이지 않았는지라 ;

오늘은 코딩이라는 주제에 대해 한번 뭔가 써볼까 합니다.
요즘은 그런 생각이 자주 듭니다.
깔끔한 코딩이란 무엇일까 하는...

흔히 이런얘길 하죠...
"내 코드 더러워서 못줘."    <- 자학
"니 코드는 왜이렇게 개같냐..."    <- 비난
"A가 짠거 봤냐? ㅂㅅ같애!"     <- 뒷따마


음~ 사실 깔끔한 코딩과 더러운 코딩이라는 경계선이 존재한다고 분명하게 믿고 있었는데
요즘은 그 라인이 모호해진다는 느낌이랄까
깔끔하다는 얘기가 상대적인 것이지 않은가 하는 생각이 많이 듭니다.

아주 단순한 예를 들어보겠습니다.

bool bSuc = IsFunc(); if (bSuc) { // ....}
<코드 A>

if ( IsFunc()) { // ... }
<코드 B>

<코드 A> 스타일을 즐겨 사용하시는 분이 있고, <코드 B> 스타일로 가시는 분들이 있습니다.
누가 더 깔끔하다고 말할 수 있는 것일까요?

하나만 더 들어보겠습니다.

{ if ( ...) return false; // ... if ( ...) return false; // ... if ( ...) return false; }
<코드 C>

bool IsFunc() { if ( ...) { // ... if ( ... ) { // ... if ( ... ) { } } } }
<코드 D>

중간중간 리턴코드로 걸러주시는 분이 있고, return 모시기 삽입 없이 항상 참인 상태가
지속되도록 코딩을 하시는 분이 계십니다.
<코드 C>와 <코드 D>의 경우 역시 누가 더 깔끔하다고 말할 수 있을까요?

깔끔하다는 의미라는 것이 상대적이라는 냄새가 서서히 납니다.
제 생각이긴 하지만, 보통 개발자들은 결국 자기 눈에 맞지 않으면, 혹은
자기 스타일이 아니면 더러운 코드라고 느끼는 것 같습니다.

물론 그렇다고 해서 정말 더러운 코드가 없는건 아닙니다.
예를 들어 이런건 누가봐도 정말 더러운 코딩이죠. 무한 if 문입니다.

bool IsFunc() { if ( ...) { // ... if ( ... ) { // ... if ( ... ) { // ... if ( ... ) { // ... if ( ... ) { // ... if ( ... ) { // ... if ( ... ) { // ... } } } } } } } }
<코드 E> 끝없는 if 문

머 조건과 필터링이 걷잡을 수 없이 늘어나는 경우가 분명 있긴 하지만 한 조건 안에
10개가 넘는 if 가 들어가면 사실 뚜껑이 열리는 것은 분명합니다 (어시스트 없으면 죽습니다
아 ㅅㅂ 어느게 어느 중괄호야 !!!! 대략 이런 반응....)
하나 더 있습니다.
알 수 없는 변수명이죠.

bool IsFunc() { DWORD a; DWORD b; if (!a) return false; if (b > 100) return true; }
<코드 F>

for 루프 카운터 변수가 아닌, 일반 변수를 이딴식으로 지어 놓은 것을 보았을 때,
그리고 내가 그 변수명으로 인해 헷갈려서 큰 사고를 칠 뻔했을때, "이 코드의 주인공을
찾으면 반드시 목을 비틀고 만다!" 라는 생각 해보신 분 분명 있을겁니다.

다시 원래의 주제로 돌아와서,
깔끔한 코드의 기준이 상대적이라는 말을 뒷받침해줄 예가 하나 더 있습니다.
사수에게 코드를 인계받았을 때는 물론 이런 얘긴 하지 않지만
보통, 자기랑 실력이 비슷하거나 혹은 더 못한 전임자에게 코드를 인계받았을 때는
소스를 분석하다말고 거의 십중 팔구 이런 소리를 합니다.

"ㅇ ㅏ!!! 것참 더럽게 짜놨네 ㅅㅂ 내가 처음부터 다시 짜고 싶다 !"

그래서 일부의 경우는, 부분부분 리펙토링을 하거나 아니면 정말 자기가 다시 처음부터
코드를 만들기도 합니다. 그러나 시간이 지나고 자기도 유지보수의 압뷁에 시달리다 보면
결국 어느 순간은 "일단 구현하고보자" 의 코드가 여기저기 생겨나게 되고 같은 현상이
되풀이 됩니다. 그리고 그사람이 떠날 때 그 후임자가 코드를 받는다면, 역시 똑같은
소릴 하겠죠 :)

저는 업무 특성상 "실시간 순발력"과 "일단 만드는게 먼저"를 요하는 일만 계속 해왔기 때문에
설계 능력도 떨어지고, 구조적인 감도 하나도 없습니다.
빨리! 빨리! 그저 고속 코딩만을 해왔죠...
뭐 빨리 해야 윗분들이나 고객들이 좋아하고, 저도 그냥 설계다 뭐다 핑계로 질질끄는게 싫어서 ;

그래서 정말 저의 코드는 더럽습니다.
그냥 머 ... 더럽지만 퍼포먼스 테스트만은 잊지 않는 정도의 수준이랄까 ;
주로 남한테 기생하는 기능만 만들었던 지라 ;; 내형적으로는 더럽더라도 외형적으로는 깔끔하게
잘돌아가야 하니까요. lol

어쨌든 그래서 사실 많은 개발자들이 자신의 목숨에 비할만큼 가치를 높게두는 코딩 자존심이나 
방법론 등에 대한 이해도 별로 없고 또 잘 알지도 못합니다.  그래서 코딩이라는 일을 또다른
학문으로 승격시키며 출간되는 수많은 책들... 본것도 없고 잘 모릅니다 ㅎ ; 뭐 근데 그건 저
뿐만이 아니고 라이브 서비스를 주로 하셨던 분들은 대부분 그렇지 않나 싶기도 합니다.

어쨌든 그래서 저는 요즘들어 이런 철칙들이 더욱 중요하다고 느껴집니다.
"남의 코드 씹지 말자."
"내 코드 씹히더라도 개의치 말자." 

인간들이 꺼려하는 기본 규율에만 어긋나지 않는다면, 코드가 더럽다는 것은 다
상대적인 것이 아닐까. 하는 생각이 많이 듭니다. 어차피 실전에서 변수명을 저따위로 두거나
하나의 함수 길이를 1000줄이 넘도록 작성하거나 하는 일은 많지 않으니까요.

더럽고 깔끔하다는 상대적인 개념만 극복하면, 코딩에 대해 씹힌후 기분 나쁠 일도,
타인을 씹을 일도 없는 게 아닐까 하는게 그냥 요즘 드는 생각입니다.


window31. 2009년 2월.