나는 아름답게 작성되고 과도하게 엔지니어링된 코드를 발견했습니다. 어느 순간 “그거 정말 흥미로운 방법이구나”라고 생각하다가 다음 순간에는 “대체 무슨 일이 일어나고 있는 거지!”라고 궁금해할 것입니다. 나는 또한 너무 먼 미래를 생각하고 타협하는 코드를 과도하게 작성하는 데 어려움을 겪었습니다. 지금. 그만큼 야그니 (You Are n’t Gonna Need It) 원칙은 과도한 엔지니어링에 대응하는 좋은 방법입니다. 기능은 필요할 가능성이 있는 것이 아니라 필요할 때만 구현해야 합니다. 나는 지금까지 오버 엔지니어링에 대해 몇 번 언급했는데, 이 글을 읽고 있는 여러분 중 일부는 아마도 오버 엔지니어링이란 무엇인가?라고 생각하고 있을 것입니다.

매우 간단히 말해서, 과도한 엔지니어링은 소프트웨어/시스템 설계를 필요 이상으로 복잡하게 만들고 있습니다. 이는 일반적으로 A의 구현을 단순화하고 나중에 B의 기능을 추가하기 위해 구성 요소에 추가 기능을 추가하려고 하기 때문에 발생합니다.

초대를 관리하기 위한 코드베이스가 있습니다. 이는 이자를 발생시키는 기술적 부채가 있는 상속된 레거시 코드베이스입니다. 레거시 코드에 대해 더 많은 작업을 시도할수록 다른 곳에서 더 많은 문제가 발생합니다. 대부분의 경우 되돌리고 처음부터 다시 시작해야 합니다. 레거시 코드를 해결하는 작업은 결국 기술 부채에 대한 이자를 발생시킵니다. 이는 앱 전체의 기능을 손상시킬 위험이 있거나 코드베이스에 더 많은 기술적 부채를 추가하는 것 사이의 대립입니다. 우리가 생각해낸 세 번째 해결책은 추상화였습니다. 우리는 애플리케이션의 새로운 기능이나 개선 사항을 모듈화하고 필요한 경우 데이터를 노출하고 공유하는 방법을 찾아야 했습니다. 처음에는 이것이 성모송처럼 보였습니다. 마지막으로, 우리는 부작용을 최소화하면서 이 손상된 코드베이스를 작업할 수 있습니다. 우리가 틀렸나요 !! 추상화는 나선형으로 진행되었고 코드베이스는 과도하게 추상화되어 문제에 대한 솔루션을 부풀리고 코드베이스의 복구된 측면을 지옥으로 가져갔습니다. 그 과정에서 우리는 추상화 규칙을 잊어버리고 이제 애플리케이션의 서로 다른 부분이 서로 의존하게 되어 시작한 곳으로 되돌아갑니다. 나는 이것이 두 명의 개발자가 있는 코드베이스에서 일어날 것이라고 생각합니다. 각각은 기능을 제공하기 위해 노력하고 있습니다. 결국 배송 유지 관리와 더 많은 기술 부채가 발생했습니다.

코드베이스에서 여러 사람과 공동 작업할 때(거의 항상 그렇습니다) 코드 품질보다 기능 제공에 더 관심이 있는 기업의 경우 코드 검토는 항상 어려움을 겪습니다. 과도한 엔지니어링 및 과도한 추상화와 같은 문제의 경우 기존의 한 줄씩 코드 검토에서는 이러한 체계적인 문제를 놓치는 경우가 많습니다. DRY 원칙에 따라 기능 통합을 지원하기 위해 몇 주 전에 생성된 구성 요소를 확인하고 이제 구성 요소에 따라 10개의 상호 연결/유사 기능이 있다는 것을 알게 됩니다. 이러한 아키텍처 문제를 파악하고 구성 요소 간의 종속성 요구 사항이 충족되는지 확인하려면 코드 검토를 강화해야 합니다.

스파게티 DRY 코드

우리는 DRY(Don’t Repeat Yourself) 복음을 지키며 살고 있습니다. 왜냐하면 그것이 작업을 단순화하고 개발자들은 본질적으로 (좋은 의미에서) 게으르기 때문입니다. DRY 원리는 직교 시스템, 즉 작고 독립적인 구성 요소가 결합되어 시스템을 형성하는 시스템과 잘 작동합니다.

시스템은 서로 독립적인 기능을 구현하는 일련의 협력 모듈로 구성되어야 합니다..

Alıntılar – 실용적인 프로그래머: 숙련공에서 마스터까지 | Kitap.Guru.

직교 시스템과 DRY 코드가 더 강조되어야 합니다. 생성한 재사용 가능한 기능을 서로 결합하고 저장소가 확장되거나 과도하게 추상화되지 않으면 저장소가 진행됨에 따라 확장하는 것이 더 쉽습니다. 이 시점에서 서로 너무 많이 얽혀 있는 경직된 시스템으로 끝나고 정확한 규칙을 충족하지 않는 코드의 어떤 측면을 연결하기가 복잡해지고, 새로운 연결에 작동하도록 하면 기존 시스템이 손상되기 때문에 코드가 복제되는 자신을 발견하게 됩니다. 축하합니다. 구부릴 수 없는 스파게티 코드를 얻으셨습니다. 진정한 직교 시스템을 사용하고 스파게티 DRY 코드를 방지하려면 모든 코드 모듈 변경이 업데이트되는 모듈에만 영향을 주어야 합니다.

복잡한 구성요소

구성 요소는 반복을 피하는 것에만 초점을 맞춰서는 안 되며, 전체 시스템의 작은 추상화에도 초점을 맞춰야 합니다. 그렇지 않으면 구성 요소가 너무 복잡해져서 연결된 구성 요소를 한 번만 변경해도 쉽게 손상될 수 있습니다. 재사용 가능한 코드를 생성할 때 접근 방식은 특정 방식으로 작동하기 위해 다른 코드 블록에 의존하지 않는 코드를 작성하는 것이어야 합니다. 재사용성은 목표가 아닌 도구로 사용되어야 합니다. 동일한 구성 요소에 비즈니스 또는 API 논리가 포함된 재사용 가능한 UI 구성 요소가 있으면 지나치게 추상화되는 고속도로에 있는 것입니다. 그것은 작게 시작하여 무슨 일이 일어나고 있는지 깨닫기도 전에 질병이 저장소 전체에 퍼졌습니다. 이제 구성 요소에 외부 논리/컨텍스트를 추가하지 않으면 동일한 UI 기능과 다른 논리를 사용하여 다른 페이지에서 구성 요소를 재사용할 수 없습니다.

과도한 추상화 및 과도한 엔지니어링을 방지하기 위한 패턴

모듈성 모듈성 모듈성

모듈화에는 시스템을 모듈이라고 하는 더 작고 독립적인 코드/구성 요소로 나누는 것이 포함됩니다. ‘더 작게’라는 단어에 주의하세요. 필요한 것보다 더 많은 코드가 포함된 비대해진 모듈을 갖는 것이 가능하며, 이는 과도한 추상화를 생성하므로 피해야 합니다. 과도한 추상화는 실제로 모듈화에 대한 실패한 시도입니다. 모듈은 필요한 데이터만 노출하면서 다른 모듈과 독립적으로 작동할 수 있어야 합니다. 좋은 모듈식 구조화된 코드에 대한 변경 사항은 연쇄 효과 없이 모듈에만 영향을 주어야 합니다.

기능성 우선

직교 시스템을 구축하고 과도한 추상화를 쉽게 피하는 좋은 접근 방식은 기능을 먼저 구축한 다음 특징을 구축하는 것입니다. 이는 구성 요소 기반 아키텍처(상태 저장 구성 요소에서 UI 구성 요소를 분리)와 잘 맞습니다. 기능 단계에서는 기능을 구현하기 위해 조합된 재사용 가능한 가장 작은 코드 단위에 중점을 둡니다. 로그인 기능은 사용자 이름 및 비밀번호(UI) 수집, 사용자 데이터 유효성 검사, 사용자 프로필로 리디렉션/수집된 사용자 데이터 거부 등의 기능으로 구성됩니다. 각 기능은 필요한 데이터에만 의존하여 독립적으로 작동해야 합니다.

지나치게 정교한 코드에는 메달이 없습니다

모든 코드 구현을 작성한 후에는 동일한 결과를 얻을 수 있는 더 쉽고 간단한 방법이 있는지 자문해 보세요. 우리 대부분은 회사에서 단 한 사람만이 편집하거나 작업할 수 있는 코드에 대한 이야기를 들어본 적이 있는데, 이는 자랑스러워할 만한 일이 아닙니다. 자신만이 유지 관리할 수 있는 코드를 작성한다는 것은 코드가 지나치게 정교하거나 비정통적인 절차를 사용한다는 것을 의미할 가능성이 높습니다. 비정통적인 절차를 사용한 코딩의 좋은 예는 다음 기사에 나오는 Gilfoyle의 하드 드라이브입니다.

“열이 부족합니다.” – Jimmy Miller의 최고이자 최악의 코드베이스입니다. 한 회사의 전직 직원은 코드를 체크인하지 않고 자신의 하드 드라이브에 프로그램과 코드베이스의 일부를 저장하는 것으로 알려져 있습니다(해당 제품을 유지 관리하는 데 드는 오버헤드를 상상해 보십시오!).

나는 방금 배운 새로운 기술/패키지/라이브러리가 작업에 가장 간단한 도구인지 여부를 고려하지 않고 사용하고 싶어서 지나치게 정교한 코드를 작성하고 있음을 발견했습니다. 새로운 것을 배울 때의 설렘은 크지만, 언제 어디서 적용해야 하는지에 대한 관심이 더 중요할 것입니다.

종악장

가능한 모든 미래 및 시간 여행 사례를 설명하는 완벽한 코드를 작성하려는 과정에서 결국 지나치게 엔지니어링된 코드베이스를 얻게 됩니다. 완벽한 코드를 작성하는 것은 불가능하므로 포기해야 하며, 즉각적인 요구 사항을 모두 충족할 만큼 좋은 코드를 목표로 삼아야 합니다. DRY 원칙은 기본입니다. 반복은 소프트웨어 개발에서 여전히 죄악입니다. DRY 원칙은 각 모듈이 독립적이고 별도의 회의 지점(기능 모듈)에서 데이터를 교환하는 분리된 코드베이스를 생성하기 위해 직교 시스템에 적용되어야 합니다. 이는 유지 관리 및 디버깅이 쉬운 시스템을 만드는 데 도움이 됩니다. 소프트웨어 개발에서는 단순한 것이 항상 더 좋다는 것을 기억하십시오.

출처 참조