HAMA 블로그

잘 짜여진 코드가 무엇일까요??

코드를 잘 짠다는 것은 매우 어려운 일입니다. 많이 아는 것도 중요하지만, 많이 바꾸는 것도 중요합니다. 
코드에 애정이 있다면 자연스럽게 많이 바꾸게 될 것이고, 아름답게 가꾸고 싶어질 것이며 자연스레 코드는 점점 더 좋아 질 것입니다. 물론 공부를 안하면 애정이 있어도 어떻게 아름답게 해야하는지 모를 수도 있겠지요.하지만 애정이 있다면 역시 공부를 하게 되겠죠?? - 한번에 좋은 코드를 짜는 건 세상 어떤 프로그래머도 불가능 합니다.- 

소설가들은 좋은 글을 작성 하기 위해서 한 문장에 대해서 한 달 이상 고민을 한 적도 있다고 합니다.
근데 그렇게 쓰여진 문장을 몇 년 후에 다시 보았을 때, 후회가 밀려오기도 한다고도 합니다.
더 좋은 문장이 생각나기도 하기 때문입니다. 

국어/영어 자체를 뛰어나게 잘 안다고 해서 소설(글짓기)를 잘하는 것과는 또 다른 영역의 문제입니다. 
SF 소설을 쓰기 위한 컨텍스트를 조사하고 이해 하기 위해 수년간 해당 분야 전공을 공부하는 경우도 있다고 합니다. 역사소설도 마찬가지일 것입니다. 

이 글에서는 잘 짜여진 코드에 대해서만 언급합니다.
즉 코드를 잘 짜는 것과 해당 주제를 잘 수행하는 것과는 조금 다른 면이 있습니다. (이 글에선 구분해서 설명합니다.) 

유려하게 글을 잘 썼지만, 팩트가 엉망이면 .......

좋은 작품을 만들기 위해서는 해당 주제를 잘 수행하기 위해서는 아래에 나올 코드를 잘 짜는 것에 추가적으로 해당 주제에 대한 깊은 공부를 해야 합니다.  따라서 아래의 글은 "해당 주제에 대해 용도에 맞게 정확히 실행되는 코드" 라는 점을 가정하고 그 코드가 잘 짜여진 것 처럼 느껴지려면 어떤 점이 나타나야 하는지에 대해서 서술합니다.

잘 짜여진 코드는 아는 만큼 보이며, 아는게 많아도 상호간 기준에 따라 조금은 다르게 판단 할 수도 있습니다.
이제 제가 느끼는  잘 짠 코드가 가지는 요소들에 대해 11가지로 정리해 보겠습니다.
(여유가 생길 때마다  좀 더 풀어서 설명 하도록 하죠) 

1. 변경이 쉽다. 

ㅡ 변경함에 있어서 해당요소의 경계가 명확해야 합니다.
ㅡ 변경함에 있어서 주변소스의 변경은 최소화 해야 합니다.

2. 반복이 없다

ㅡ 반복되는 부분을 하나로 만듭니다.

3. 이름짓기를 잘한다.

ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용합니다. (자바쪽에 특히 오용된것들이 많습니다 )

4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.

ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.

5. 팀이 정한 컨벤션에 일치한다.

ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요합니다.
ㅡ 탭사용규정,줄바꿈규정 등등

6. 바퀴를 재발명하지 않는다.

ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시 사용합니다.  스프링지원기술들 사용하는것도 같은 맥락입니다.

물론 발명 할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요

7. 후임자가 실수 할 여지를 줄인다

ㅡ 제약 상황을 많이 만들어 넣어서 후임자가  잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다. 

8. 추상화가 잘 된 코드

ㅡ 코드 흐름에 대해서 추상화(일반화)를 잘 해서 뽑아 내면,  유연성을 가지게 됩니다.
    다만 오버엔지니어링 이슈가 있습니다.

9.잘 알려진 패턴이 적절하게 적용된 코드

ㅡ 익히 알려진 패턴을 사용하는 것은 대게 좋은 설계를 선택하게 만들며, 의사소통 비용도 줄 일 수 있습니다.

10. 시대흐름에 맞는 코드 

ㅡ 모던C++, 모던자바를 사용합니다. 언어의 업그레이드에 대해서 관심을 갖습니다.

11.테스트 친화적 코드

ㅡ 테스트 하기 쉬운 코드는 대게 좋은 설계를 의미합니다. 

이런것들이 잘 적용되어 작성된 코드를 보면 감동이 밀려 오지요

"코딩을 잘하는 사람" 보다는 ooo 사람이 되라. <-- ?? 
"코더보다는 프로그래머가 되라" <-- ??
"코더/프로그래머 다음에는 관리자로 업그레이드 되야 한다" <- 아니다
" 코딩과 설계는 분리 가능하며 설계가 상위능력자의 일이다" <- 아니다

코딩이라는 단어에 대한 감각이 다들 다르니,  저런 식의 말들도 많이 있는거 같습니다.
저는 저런 식의 말들이 틀렸다라고 생각하진 않습니다. 옳을 수도 있는 말입니다.다만 그냥 저는 조금 다른 감각을 가지고 있습니다. (더 광의적으로 해석합니다. 아니 굳이 구분을 하는 의도에 불순함이 있어 보입니다) 

개발자의 '코딩'은 소설가의 '글쓰기'와 같다고 생각 합니다. (일맥상통하는 부분이 있다.)
소설가가 '글쓰기'를 잘하는 것은 가장 중요한 재능이나 노력의 결과인 겁니다. 
어떤 대학의 소설 한편 못써본 국문과 교수가, 직업 소설가를 바라보며 '글쓰기'는 사소한거다.
라고 말해바짜 비웃음만 당할 뿐이겠지요.  

'코딩'도 마찬가지입니다. '코딩'은 가장 중요한 덕목이며,
'코딩'을 잘하기 위해 서는 매일 매일 습작 하는 버릇을 들이고, 평생 '장인' 정신을 가지고 노력해야하는 일입니다.
'코딩' 도 잘하려면  어느정도의 재능과 하루하루 쌓아가는  오랜기간의 부단한 노력이 필요합니다. 

'코딩'을 잘한 다는 것은 

1. 어떤 주제에 대해서 유려하게 구성을 잡고, 꼼꼼하게 빈틈을 채워나가는 능력을 보유 한다는 것을 말합니다. 누구는 어떤 주제에 대해 겨우 10줄밖에 못짜겠지만, 누군가는 200줄로 짤 수 있을 수 있습니다. 
여기서 이 200줄이 쓸모없는 것이 아니라, 모두 필요한 요소들이라면 이 격차는 어마어마 한 것일 겁니다.

2. 문제해결을 위한 기본적인 지식을 기반으로 가지고 있거나, 상황에 따라서  빠르게 공부 할 수 있는 능력을 가지고 있어야 합니다.

3. 문제해결을 유연한 사고 방식으로 다른 각도에서 바라 볼 수 있는 창의력을  가지고 있어야 합니다.

4. 반복해서 고치고, 고민하고 덧붙히는 끈기가 있어야 합니다.

을 기반으로 코드를 작성해 나간다는 의미라고 생각합니다.

그러므로, '코딩'을 잘한다는 것은 우리 소프트웨어 개발자의 평생의 목적이지 않을까 싶습니다.
이렇게 정의를 내려 놓고 보니, '코딩' 을 잘하는 사람들에게 절로 존경심이 들며,  그 코딩의 다음 단계로 관리자가 되어야지, 코딩만 잘해서는 안되다는 말을 하는 사람들에게 역시 쓴 웃음이 나거나 고깝게 보이기도 하지만, 감각이 다르거니 하고 흘려 버려야 겠지요..

ps) 

코딩잘하는 사람을 보기란 정말 어렵습니다.
물론 모든 사람들이 최고의 능력을 보일 필요는 없습니다. 평범한 직업으로써의 능력만으로도 충분할 수 있으며, 삶을 영위 하는데 존중 받을 수 있습니다. 이게 "직업으로써의 소설가" 와는 조금 다를 수있는 부분 인거 같습니다.