스파게티 코드

멀티캠퍼스 웹 풀스택 개발자 교육을 들은 지 2주 차에

자바를 시작하고 처음으로 제대로 코딩을 배우다가

강사님께서 지나가듯이 개발자라면 스파게티 코드 정도는

기본적으로 알고 있어야 한다 라는 말씀을 해주셔서

잡담 카테고리에 간단하게 정리하고자 한다.

 

1. 스파게티 코드란?

프로그래밍에 있어서 기술적 부채에 해당하는 분류로 컴퓨터 프로그램의 흐름이 복잡하게 뒤엉킨 모습을 스파게티가 엉킨 모습에 비유한 것이다.

 

스파게티 코드는 작동 자체는 제대로 하거나 하는 것처럼 보인다. 하지만 해당 코드는 추후 유지보수가 매우 어려워진다.

코드의 작동 방식을 변경하거나 버그 찾거나 개선하는 등 코드를 수정하는 모든 작업에 방해가 된다. 

특히 객체지향프로그래밍(OOP)에서 상속 계층이 너무 많아 생긴 스파게티 코드는 따로 라자냐 코드라고도 한다.

 

이러한 이유로 스파게티 코드는 가독성이 많이 떨어진다는 평이 많다.

특히 이러한 코드는 프로그래밍 초보자들이 많이 작성한다.

심각한 경우 ' 수정할 바에야 다시 만드는 게 낫다'라는 농담을 하기도 한다.

 

2. 발생 원인

보통 계획 없이 바로 코딩을 시작하거나 요구사항이 원래 기획한 범위를 크게 벗어날 때 혹은 프로그래머의 알고리즘 구현 실력이 지나치게 떨어질 때

주로 출현한다. 발적 화도 덤으로 나타나는 경우가 많지만 스파게티 소스 코드라고 모두 실제 작동에서 비효율적인 것은 아니다.

 

-함수 / 메서드가 둘 이상의 작업을 한다.

하나의 함수/메서드에서는 논리적으로 구분되는 가장 작은 단위의 작업을 처리하는 게 이상하다.

이 규칙을 어겼을 때 로직이 꼬이면서 스파게티 코드가 발생한다.

하나의 함수/메서드의 코드 길이가 1000줄이 넘는다면 거의 대부분 이런 경우다.

 

-논리적으로 하나의 작업 단위를 억지로 둘 이상의 함수/메서드로 쪼개는 경우

 

-여러 함수/메서드들이 지나치게 서로서로 의존하면서 얽혀있는 것

특히 전혀 상관없는 클래스들의 메서드(인터페이스, 상속한 것도 아닌...)들이 뒤죽박죽 얽혀있으면 답이 없다.

이럴 경우 메서드 하나를 조금 손 보면 프로그램 전체가 오작동하기 십상이다.

 

-if-else 문의 계층이 지나치게 얽혀 있다.

여러 조건을 동시에 비교하는 경우에는 진리표나 패턴 매칭을 대신 사용해야 한다. 

순서도를 그렸을 때 마름모(조건 분기 기호)가 나무뿌리처럼 얽혀 있는 코드는 훌륭한 스파게티 코드다(훌륭한 스파게티 코드는 무엇..?)

/* 개별 변수 a, b, c를 if-else로 하나씩 비교하는 대신 if a and (not b) and c then 'do something' 하는 식으로 모든 조건을

한꺼번에 검사하면서 내려가라는 얘기다.  */  [이 부분은 아직 무슨 말인지는 모르겠다]

 

-다중 for 루프

행렬을 처리할 때에는 다중 for 루프가 하나의 논리적 처리 단위이므로 다중 for루프 자체는 스파게티 코드가 아니다.

문제는 트리 자료구조 등을 순회할 때 다중 for 루프를 통해 처리하는 경우다

트리 자료 구조를 처리할 때에는 과감히 재귀함수를 사용해 줄 필요가 있다.

특히 다중 for 루프에서 break와 continue를 마구 남발하면 GOTO [아직 뭔지 모름] 문을 사용한 것보다 코드의 흐름을 추적하기 더욱더 어려워진다. 

 

-포인터 남용

포인터는 양날의 검과 같다. 분명 강력하고 유용한 도구이지만 잘못 사용하면 그야말로 재앙이 된다.

값 복사의 오버헤드가 도저히 용납이 안 될 정도로 성능 하락을 보이는 게 아니면 포인터 전달보다는 값 복사를 사용하는 편이 좋고, 그게 어려울 때에도 포인터를 '상수'로 간주해 한 번 할당한 값을 변경하지 않는 게 좋고 그것도 여의치 않으면 최소한 포인터를 조작하는 로직을 코드의 한 군데에 모두 몰아넣어야 한다

 

-용도에 맞지 않는 프로그래밍 언어 사용

그래픽 프로세싱용 언어로 데이터베이스 로직을 구현하거나 논리 프로그래밍 언어로 기계제어 시도하는 경우 등.

원래 프로그래밍 언어가 상정한 활용 영역을 벗어나서 코딩하려니 라이브러리 지원도, 문법 지원도 받지 못하고 

차라리 어셈블리어가 읽기 쉬워질 지경의 코드를 만들게 된다.

 

-코딩 스타일이 통일되지 못함

특히 다소 마이너한 주제의 무보수 오픈소스 프로젝트에서 흔히 일어날 수 있는 일이다. 

주제의 매니악함과 보수가 없음으로 인해 유입이 적고 엄격한 기여 규칙을 적용하기 어려워 지기 때문이다. 

또한 개발기간이 오래된 경우 과거의 잔재들이 남아있을 수 있는데 이 경우 곽의 잔재가 버그의 온상이 된다. 

 

3. 실제사례

넷스케이프 / 리그 오브 레전드 / 마인크래프트 자바 에디션 / 던전앤파이터 /

마비노기 / 패러독스 인터랙티브 제작게임들 / 포켓몬스터 적녹 등

https://namu.wiki/w/%EC%8A%A4%ED%8C%8C%EA%B2%8C%ED%8B%B0%20%EC%BD%94%EB%93%9C?from=%EC%8A%A4%ED%8C%8C%EA%B2%8C%ED%8B%B0%28%EC%86%8C%EC%8A%A4%20%EC%BD%94%EB%93%9C%29

 

 

---

후기

먼저 스파게티 코드를 언급해서 알게끔 해주신 멀티캠퍼스 H반 자바 이재희 강사님께 감사합니다.

발생 원인들이 죄다 내 얘기 같고 메서드나 다중 if-else문, 다중 for문, 상속 등 

자바 앞부분의 기초 내용을 쉽게 본 나에게 경각심을 일으켜 줬다.

 

오늘도 같이 수업 듣는 사람들이 잡담 방에서 같은 코드를 갖고 간단하게 만들어나가는데 그거 하나보다가

2시간이 갔다고 했다. 이제와서 그 코드를 따라갔다고 좋아하는 나한테는 그저 충격이고 '저 코드를 더 쉽게?'

라는 절망을 주었지만, 기초가 탄탄해야 나중에 사소한거라도 기억해내서 덜 복잡하게 코드 만들어야겠다는 

생각도 하게했다.

 

겉핥기로 1회독을 한건지 안한건지 모르겠는 느슨해진 자바지식에 여러가지로 긴장을 주고있다.

다같이 하는 캠키고 하는 스터디와 기초 정리하는 스터디, 우리 멀캠 H반 50명 다들 화이팅이다.

 

 

---

누가 이 글을 혹시나 읽을지는 모르지만 알고리즘이 띄워준 노마드 코더의

클린한 코드 만드는 5가지 방법이다. 짧은 영상이 미래의 나에게 큰 도움을 줄 것이라 생각하고

꼭 한번 보는 것을 추천한다.

 

https://www.youtube.com/watch?v=Jz8Sx1XYb04