잘 짠 코드란??
잘 짜여진 코드가 무엇일까요??
코드를 잘 짠다는 것은 매우 어려운 일입니다. 많이 아는 것도 중요하지만, 많이 바꾸는 것도 중요합니다.
코드에 애정이 있다면 자연스럽게 많이 바꾸게 될 것이고, 아름답게 가꾸고 싶어질 것이며 자연스레 코드는 점점 더 좋아 질 것입니다. 물론 공부를 안하면 애정이 있어도 어떻게 아름답게 해야하는지 모를 수도 있겠지요.하지만 애정이 있다면 역시 공부를 하게 되겠죠?? - 한번에 좋은 코드를 짜는 건 세상 어떤 프로그래머도 불가능 합니다.-
소설가들은 좋은 글을 작성 하기 위해서 한 문장에 대해서 한 달 이상 고민을 한 적도 있다고 합니다.
근데 그렇게 쓰여진 문장을 몇 년 후에 다시 보았을 때, 후회가 밀려오기도 한다고도 합니다.
더 좋은 문장이 생각나기도 하기 때문입니다.
국어/영어 자체를 뛰어나게 잘 안다고 해서 소설(글짓기)를 잘하는 것과는 또 다른 영역의 문제입니다.
SF 소설을 쓰기 위한 컨텍스트를 조사하고 이해 하기 위해 수년간 해당 분야 전공을 공부하는 경우도 있다고 합니다. 역사소설도 마찬가지일 것입니다.
이 글에서는 잘 짜여진 코드에 대해서만 언급합니다.
즉 코드를 잘 짜는 것과 해당 주제를 잘 수행하는 것과는 조금 다른 면이 있습니다. (이 글에선 구분해서 설명합니다.)
유려하게 글을 잘 썼지만, 팩트가 엉망이면 .......
좋은 작품을 만들기 위해서는 해당 주제를 잘 수행하기 위해서는 아래에 나올 코드를 잘 짜는 것에 추가적으로 해당 주제에 대한 깊은 공부를 해야 합니다. 따라서 아래의 글은 "해당 주제에 대해 용도에 맞게 정확히 실행되는 코드" 라는 점을 가정하고 그 코드가 잘 짜여진 것 처럼 느껴지려면 어떤 점이 나타나야 하는지에 대해서 서술합니다.
잘 짜여진 코드는 아는 만큼 보이며, 아는게 많아도 상호간 기준에 따라 조금은 다르게 판단 할 수도 있습니다.
이제 제가 느끼는 잘 짠 코드가 가지는 요소들에 대해 11가지로 정리해 보겠습니다.
(여유가 생길 때마다 좀 더 풀어서 설명 하도록 하죠)
1. 변경이 쉽다.
ㅡ 변경함에 있어서 해당요소의 경계가 명확해야 합니다.
ㅡ 변경함에 있어서 주변소스의 변경은 최소화 해야 합니다.
2. 반복이 없다
ㅡ 반복되는 부분을 하나로 만듭니다.
3. 이름짓기를 잘한다.
ㅡ 추상층이 높아 질 수록 보편적으로 사용하는 키워드를 사용하며, 가급적 GoF패턴의 명칭들은 그 의도와 비슷한 경우에만 사용합니다. (자바쪽에 특히 오용된것들이 많습니다 )
4. 해당언어의 이디엄과 추구하는 방향에 맞춰 코딩한다.
ㅡ 예를들어 자바 코드짜는데 C처럼 짜면안되겠죠. 마찬가지로 코틀린 코드 짜는데 자바처럼 짜면 후지다라는 느낌이 듭니다.
5. 팀이 정한 컨벤션에 일치한다.
ㅡ 예외처리(가까이서 처리? 멀리서 처리? 등)나 로깅의 경우 답이 없기 때문에 일치화가 중요합니다.
ㅡ 탭사용규정,줄바꿈규정 등등
6. 바퀴를 재발명하지 않는다.
ㅡ 이미 잘 짜여진 기술이 있고, 변경 필요가 없다면 있는것을 사용해서 의사소통 비용줄임. 예를 들어 JVM에서 프록시 패턴을 굳이 스스로 만들기 보단 다이나믹 프록시 사용합니다. 스프링지원기술들 사용하는것도 같은 맥락입니다.
물론 발명 할 필요성은 추후에 검토 합니다. C++의 STL이나 자바의 컬렉션이나 보편적 성능일뿐이지 특정상황에선 엄청느리니까요
7. 후임자가 실수 할 여지를 줄인다
ㅡ 제약 상황을 많이 만들어 넣어서 후임자가 잘못하면 가급적 컴파일 타이밍에 에러를 내게 합니다.
8. 추상화가 잘 된 코드
ㅡ 코드 흐름에 대해서 추상화(일반화)를 잘 해서 뽑아 내면, 유연성을 가지게 됩니다.
다만 오버엔지니어링 이슈가 있습니다.
9.잘 알려진 패턴이 적절하게 적용된 코드
ㅡ 익히 알려진 패턴을 사용하는 것은 대게 좋은 설계를 선택하게 만들며, 의사소통 비용도 줄 일 수 있습니다.
10. 시대흐름에 맞는 코드
ㅡ 모던C++, 모던자바를 사용합니다. 언어의 업그레이드에 대해서 관심을 갖습니다.
11.테스트 친화적 코드
ㅡ 테스트 하기 쉬운 코드는 대게 좋은 설계를 의미합니다.
이런것들이 잘 적용되어 작성된 코드를 보면 감동이 밀려 오지요