Today I Learned - Day 4 [스파게티 코드에 대해서]

스파게티 코드는 '장황한 코드' 보다는 '이해가 힘든 코드'라고 하는 것이 옳다.

스파게티 코드라는 이름 만 들으면 이리저리 꼬여서 제대로 알아보기 힘든 코드라고 생각하는 경우가 많다. 본인도 얼마 전 까지는 그러하였고, 그렇기에 최대한 정리하면서, 간단하게 작성하려고 했었다.

하지만, 미니 프로젝트[내일 작성할 예정]를 진행하면서 팀원의 피드백으로 알게 된 것이, '장황하다' 보다는 '알아보기 힘들다'가 주된 요인이라는 점이었다. 정확히는 어쩌다가 프로젝트 진행 중에 하나의 메소드에 여러 역할을 넣는 구성이 발생했는데, 이 부분을 다루는 도중에 발언된 팀원의 피드백을 통해서 알게 되었다.

 

비록 완벽하게 익힌 것은 아니지만, 스파게티 코드를 예방하기 위해서는 다음 요소를 반드시 지켜야 한다.

• Set[변수 설정], Get[변수 받아오기] 같이 사회적인 규격으로 정해진 형식은 반드시 따른다.
• 하나의 함수, UI 스크립트에 복수 기능을 넣지 않는다.
• 가능하면 기능 단위로 분리하여 함수를 배정한다.
  • 단, 그 중에 겹치는 부분이 있다면 하나의 함수로 합치되, 구별되는 부분을 다른 함수로 분리하는 것이 좋다.
• 파일 명은 반드시 명사형, 함수 명은 반드시 동사형으로 작성한다.
  • 또한, 이름으로 인한 혼동이 발생하지 않도록 확실하게 구별되는 이름을 사용한다.
• 함수는 기본적으로 함수명과 인자명 및 자료형과 함수 이름 만으로도 기능을 유추할 수 있도록 작성하는 것이 좋다.
  • 즉, 클래스 내부에 자료의 배열을 만든 뒤, 자연수를 인자로 받아서 사용하는 것은 지양하는 것이 좋다.

가장 중요한 것은 팀 내에서 정한 규범을 지키는 것이다. 이것은 같은 팀 안에서의 약속이자 가이드라인이기 때문에 이것이 어그러진다면 무질서한 코드들이 쌓일 수 밖에 없기 때문.

 

 

외계인 코드라는 것도 있다.

무슨 역할을 하는 지 알 수 없는 코드임에도 뺄 수가 없는 코드를 외계인 코드라고 부른다.

발생하는 원인은 다양하다. 작성한지 너무 오래되어 관련 기술이 유실됬거나, 제대로된 인계 절차를 밟지 못해서 정보 전달이 끊어졌거나 하는 등의 어쩔 수 없는 요인으로도 발생하고, 상술한 스파게티 코드에 의해서도 발생한다. 뺄 수가 없다는 점에서 긍정적인 의미로 오인할 수도 있으나, 실제로는 개선할 수가 없다는 방향에 가까운 부정적인 의미이다.

 

때문에 복잡한 코드에는 주석을 달고, 프로젝트를 진행할 때 네임 컨벤션 같은 가이드라인을 먼저 정하는 것이기도 하다. 반대로 말하면 이 두개가 미흡하다면 언제 생길 지 모르는 게 외계인 코드이기도 하다.

 

 

번외. 네임 컨벤션에 대하여

변수, 함수, 파일의 명명 규칙을 네임 컨벤션이라고 한다. 상술한 스파게티 코드를 방지하고 협력을 더욱 원활하게 하기 위해서 다양한 요소들의 명명 방식을 정해두는 것.

대표적인 네임 컨벤션에는 다음 3종류가 존재한다.

• 카멜 케이스: 단어 연결 시 첫 단어를 제외한 첫 글자를 대문자로 표기하는 명명규칙
  • ex. variableType, functionFirst
• 파스칼 케이스: 카멜 케이스에서 첫 단어의 첫 글자도 대문자로 표기하는 방식.
  • ex. VariableType, FunctionFirst
• 스네이크 케이스: 단어와 단어 사이를 언더바(_)로 잇는 방식. 주로 시스템 관련 요소에 많이 쓰인다.
  • ex. variable_type, function_first
  • 스네이크 케이스는 이름의 길이 제한 같은 요소에 걸리는 경우가 있어서 자주 쓰이지는 않는다.
• 케밥 케이스: 단어와 단어 사이를 바(-)로 잇는 방식. 잘 안쓰인다.
  • ex. variable-type, function-first