스파게티 코드란 무엇이며 어떻게 피해야 하나요?

맛있는 이탈리아 저녁 식사가 될 수 있지만 코드베이스와 관련하여 마지막으로 듣고 싶은 것 중 하나는 스파게티 입니다. 당신의 코드가 스파게티 한 접시처럼 얽혀 있다는 생각은 끔찍하지만, 많은 개발자들에게 그 아이디어는 너무 추상적이어서 다루거나 피하거나 수정하는 방법을 이해할 수 없습니다. 그렇기 때문에 이 게시물에서 스파게티 코드가 실제로 무엇인지 자세히 알아보고, 이를 피하기 위한 몇 가지 모범 사례와 (발생할 때) 처리하는 방법을 보여드리고자 합니다.

YouTube 채널 구독

스파게티 코드란?

스파게티 코드는 악몽입니다. 위에서 말했듯이 속어는 스파게티 파스타의 거대한 엉킴처럼 한 가닥(코드 조각)을 당기면 다른 가닥, 다른 가닥, 다른 가닥으로 얽히게 되므로 이름이 붙여졌습니다. 얽힌 조각이 부서집니다.

예를 들어 CSS의 !important 속성에 대해 생각해 보십시오. 디자이너가 상속된 스타일을 재정의하고 전체 스타일시트를 다시 코딩하지 않고도 특정 요소를 제어할 수 있도록 하는 매우 강력합니다. 그러나 그들(또는 미래의 개발자와 디자이너)이 다른 것을 조정해야 할 때 이전 태그를 무시하기 위해 또 다른 !important 태그를 추가할 수 있습니다. 등등. 그러나 뒤로 돌아가서 해당 스택에 있는 스타일을 제거하거나 변경하면 페이지의 스타일 수에 관계없이 손상될 수 있습니다.

이것이 우리가 피하려고 하는 것입니다.

스파게티 코드를 피하는 모범 사례

1. 코딩 표준 개발

스파게티 코드를 방지하는 가장 좋은 방법은 조직 또는 프로젝트 내에서 표준을 만들고 코딩하는 것입니다. 코딩 표준은 WordPress와 같은 프로젝트를 가능하게 만드는 것입니다. 수천 명의 개발자가 WP Core에서 작업했지만 WordPress 코딩 표준은 모두 동일한 지침 내에서 작업하고 동일한 방식으로 동일한 매개변수 내에서 작업을 수행하도록 만들었습니다.

코딩 표준은 당신이 시행하는 규칙일 뿐입니다. 모든 사람의 코드가 동일한 패턴으로 작동하도록 하여 오류를 쉽게 찾고 수정할 수 있으며 미래의 개발자(또는 귀하 또는 귀하의 현재 팀)가 각 코드 행이 가능한 한 효율적으로 수행하는 작업을 정확히 알 수 있습니다. Susan의 코드가 테스트를 통과하지 못하면 입력되지 않습니다. Janine의 코드에 실행할 테스트가 없으면 pull 요청이 거부됩니다. 아마도 Daniel은 가장 최근의 pull 요청에 div를 사용하지 않을 것입니다. 일이 분할될 때까지 병합이 없습니다.

또한 스파게티 코드에 시달리던 원래 코드베이스 중 일부는 기능적 논리가 없는 오래된 언어였습니다. 코드는 기능 기반이 아니므로 다양한 논리가 코드 내의 특정 행으로 향했습니다. 소규모 프로젝트의 경우 탐색하기에 나쁘지 않습니다. 프로젝트 확장을 시작할 때 특정 파일 및 코드 줄에 대한 직접 참조가 있으면 해당 개발이 지연될 수 있습니다. 파일이 누락되거나 줄이 삭제되거나 번호가 잘못 매겨질 수 있습니다. 그리고 스파게티의 어느 가닥이 당겨졌는지 알아내기 위해 디버깅하는 데 수백 인 시간이 걸릴 수 있습니다. 코딩 표준이 있으면 이런 종류의 혼란이 자주 발생하지 않도록 할 수 있습니다.

따라서 표준을 개발함으로써 스파게티 코드 저장소를 가질 가능성을 매우 효과적으로 낮췄습니다. 일반적인 코딩 표준에 대해 자세히 알고 싶다면 GeeksforGeeks에 훌륭한 가이드가 있습니다.

2. 스타일 가이드 따르기

코딩 표준 외에도 따라야 할 스타일 가이드가 있으면 코드가 너무 복잡해지는 것을 방지할 수 있습니다. 이론상 비슷해 보이지만 둘은 매우 다릅니다. 코딩 표준은 코드가 효율적으로 작동하도록 유지하기 위해 개발자가 따르는 시행 가능한 규칙입니다. 이는 프로젝트에서 프로젝트로 또는 조직 내에서 팀에서 팀으로 변경될 수 있습니다.

그러나 스타일 가이드는 일반적으로 언어별로 작성되어 코드를 읽기 쉽고 기능적으로 만들기 위한 일련의 모범 사례를 제공합니다. 예를 들어, Airbnb는 React.js를 위한 최고의 스타일 가이드 중 하나를 만들었습니다. React 개발자가 아니라면 아무 의미가 없습니다. 그러나 React 개발자의 경우 이것을 보면 미래의 개발자가 가능한 한 분류할 수 있도록 액세스할 수 있도록 코드를 구성하고 작성하는 방법에 실질적인 도움이 될 수 있습니다.

일반적인 코딩 표준과 달리 스타일 가이드는 반드시 시행 가능한 규칙은 아닙니다. 코드를 더 균일하게 만들어 코드를 읽기 쉽게 하기 위한 제안입니다. 주어진 시간에 어떤 가닥을 당기고 있는지 정확히 알기 때문에 스파게티 코드를 방지합니다.

3. 코드에 주석 달기

코드 주석은 저장소가 스파게티 코드로 채워지는 것을 방지하는 가장 쉬운 방법일 수 있습니다. 당신이 무언가를 쓸 때 그것이 무엇을 하는지에 대한 코멘트를 작성하십시오. 복잡한 기능이나 스니펫인 경우 논리의 역할과 중요한 이유를 설명하세요.

그러나 혼란을 방지하기 위해 코드 주석에 의존하는 몇 가지 문제가 발생합니다. 첫 번째는 프로젝트에 많은 추가 시간을 추가한다는 것입니다. 마감일을 맞추거나 기능이 제대로 작동하는지 확인하기 위해 바쁘게 움직이고 있을 때 자세한 설명을 작성하는 것이 항상 최우선은 아닙니다. 그리고 코멘트를 시작하고 프로젝트 중간에 떨어지거나 다음 개발자가 계속되지 않는다면? 그것은 스파게티의 큰 접시입니다.

다른 사람들은 개발하는 엄청난 양 때문에 코드에 주석을 달거나 이전에 코드에 주석을 추가하는 방법을 배운 적이 없다는 생각에 압도됩니다. 완전히 유효합니다. 그러나 중요한(또는 심지어 위태로운) 라인이나 스니펫에 대해 이따금 댓글을 달더라도, 과거에 이를 참고하여 그것이 무엇을 하는지 알아내려고 애쓰던 누군가, 잠재적으로 자신을 구할 수 있을 것입니다.

마무리

스파게티 코드는 악몽입니다. ​​반복합니다. 거대한 저장소에서 어떤 코드 라인이 변경되었는지 알아내려고 수많은 시간을 보내는 것은 개발자가 되는 데 있어 가장 나쁜 부분 중 하나입니다. 디버깅은 괜찮습니다(ish). 디버깅을 시작하고 어디서부터 시작해야 하는지 또는 원격으로 문제를 일으키는 원인을 모르는 것은 그렇지 않습니다. 그러나 팀이 코딩 표준을 설정하고 언어 스타일 가이드를 따르며 사소한 코드 주석 정책이라도 있다면 디지털 스파게티 접시가 그렇지 않은 경우보다 훨씬 덜 엉키게 될 가능성이 매우 높습니다.

스파게티 코드를 방지하려면 어떻게 합니까?

Donnay Style의 기사 특집 이미지 / Shutterstock.com