유지 가능한 소프트웨어를 만들지 못하게 하는 5가지 Common C# 실수 — Derek Comartin의 설명

1. 국가에 대한 소유권 부재

데릭은 먼저 소유권이 명확하지 않은 상태에서 여러 경계 또는 서비스가 공유 데이터를 업데이트하도록 허용하는 오류를 지적합니다. 그는 청구 시스템이 애플리케이션의 다른 부분에 접근하여 상태를 변경하는 예를 사용합니다. 이는 특히 해당 객체가 시스템 내 다른 위치에 있을 때 데이터 일관성 문제를 야기합니다.

이런 무질서한 접근 방식은 개발자들이 "왜 이 데이터가 틀렸지?" 또는 "누가 수정했지?"와 같은 질문을 하게 만드는 오류를 발생시킵니다. 데릭은 소유권을 명확히 정의해야 한다고 강조합니다. 시스템의 각 부분은 상태 관리를 담당하는 잘 정의된 API 또는 메서드를 제공해야 합니다.

데릭은 애플리케이션의 어떤 부분도 공유 데이터를 수정하도록 허용하는 대신 명시적인 명령과 쿼리를 만들 것을 제안합니다. 예를 들어, 배송 정보를 업데이트하려면 전용 인터페이스를 통해 명령을 실행합니다. 이는 구조를 제공하고 추적 불가능한 변경으로 인한 리소스 누수를 방지합니다.

2. 암묵적 코드 vs. 명시적 워크플로우

데릭에 따르면, 많은 시스템이 CRUD 작업(생성, 읽기, 업데이트, 삭제)에 크게 의존하지만, 이로 인해 암묵적인 워크플로가 발생합니다. 해당 코드는 기술적으로는 작동하지만, 어떤 기능을 하는지 명확하지 않습니다. 클래스가 일반적인 연산만 지원하는 경우 실제 비즈니스 워크플로는 숨겨집니다.

다음 예를 살펴보겠습니다. 운전자가 소포를 픽업하면 운송장이 생성됩니다. 시스템에서 UpdateShipment만 실행하는 경우, 문자열 변경(예: BOL 번호)이 픽업 때문인지 수정 때문인지 불분명합니다. 데릭은 모호한 업데이트를 PickupStopLoaded와 같은 명확한 작업으로 대체해야 한다고 지적합니다.

이렇게 하면 코드를 더 읽기 쉽게 만들 수 있습니다. 또한 예외 처리에도 도움이 됩니다. 예외가 발생하면 스택 추적을 통해 어떤 작업이 실패했는지 명확하게 알 수 있기 때문입니다. 명시적 메서드는 각 함수가 단일한 책임만을 가지므로 더 나은 코딩 표준을 지원합니다.

3. 불필요한 간접 참조 추가

데릭은 호출자와 대상 메서드 사이에 불필요한 단계를 삽입하는 간접적인 방식에 대해 이야기합니다. 그는 이를 데이터베이스 연결을 통해 설명합니다. 컨트롤러는 서비스를 호출하고, 서비스는 헬퍼를 호출하고, 헬퍼는 또 다른 서비스를 호출하며, 최종적으로 이 서비스는 Entity Framework를 통해 쿼리를 실행합니다.

이러한 추상화 계층 구조는 문제 추적 및 성능 개선을 더욱 어렵게 만듭니다. 추상화를 만드는 것은 유용할 수 있습니다. 예를 들어 리소스 관리를 개선하기 위해 IDisposable 인터페이스를 래핑하는 것과 같은 방식입니다. 하지만 데릭은 이러한 추상화를 과도하게 사용하는 것을 경고합니다. 추상화가 API를 단순화하는지, 아니면 특정 위치에만 존재하는 타사 라이브러리 의존성을 숨기는 데 그치는지 스스로에게 질문해 보세요.

데릭은 단순히 계층 구조를 만드는 대신, 결합도를 직접 관리할 것을 제안합니다. 과도한 간접 참조는 코드를 복잡하게 만들 뿐만 아니라 메모리 누수 가능성을 높이고 가비지 컬렉션의 이점을 약화시킵니다.

4. "만약에" 게임하기

데릭이 지적하는 다음 실수는 결코 발생하지 않을 수도 있는 가상의 사용 사례를 준비하는 것, 즉 그가 "가상 시나리오 게임"이라고 부르는 것입니다. 많은 C# 개발자들이 미래의 요구 사항을 고려하여 유연한 클래스와 함수를 작성합니다. 예를 들어, "두 가지 언어를 지원해야 한다면 어떻게 해야 할까요?" 또는 "기술을 바꿔야 한다면 어떻게 해야 할까요?"와 같은 질문들이 있을 수 있습니다.

데릭은 이러한 사고방식이 지나치게 복잡한 프레임워크와 일반적인 코드로 이어진다고 경고합니다. 그는 문자열 연결 로직과 참조 타입 래퍼를 접했는데, 그것들은 실제 사용 사례가 하나뿐이기 때문에 아무도 이해하지 못한다고 언급했습니다.

데릭은 미지의 것에 대비하기보다는 실제 필요한 사항에 집중하라고 조언합니다. 각 방법과 변수는 현재 상황에 맞는 타당한 목적에 부합해야 합니다. 사용하지 않는 기능은 유지 관리 비용만 증가시킵니다. 데릭이 말했듯이 개발 시간뿐만 아니라 소유 비용도 발생합니다. 예를 들어, 공개된 bool Equals 구현이 상상할 수 있는 모든 예외 상황을 다루지만 실제로 발생하는 예외 상황은 하나도 고려하지 않는다면 귀중한 시간을 낭비한 것입니다.

5. 워크플로우를 제대로 관리하지 못함

마지막으로 데릭은 워크플로우를 모듈식 단계가 아닌 절차적 블록으로 취급하는 오류에 대해 논의합니다. 그는 실제 사례를 들어 설명합니다. 바로 온라인 주문입니다. 사용자가 결제를 완료하면 시스템은 신용카드로 결제 금액을 청구하고 확인 이메일을 보냅니다.

만약 결제 과정과 같은 특정 단계에서 오류가 발생하면 코드는 어떻게 반응합니까? 주문을 취소하시겠습니까? 오류가 발생했습니까? 실패 이메일을 보내시겠습니까? 데릭은 이를 하나의 덩어리로 묶으면 관리하기 어려운 복잡성이 초래된다고 설명합니다.

그는 워크플로우를 메시지를 통해 소통하는 작고 독립적인 단위로 설계할 것을 권장합니다. 비동기 작업과 yield 반환을 사용하면 이러한 단계를 더 쉽게 관리할 수 있습니다. 또한 파일 접근이나 데이터베이스 연결과 같은 외부 리소스에 대해 using 문과 using 블록을 사용하면 메모리 누수를 방지하는 데 도움이 될 수 있습니다.

예를 들어, 스트림을 using 블록으로 감싸면 스트림이 올바르게 해제되도록 보장할 수 있습니다. 이는 IDisposable 인터페이스를 사용할 때 매우 중요한 요소입니다. 워크플로가 복잡해지면 이러한 모범 사례를 통해 예외를 효과적으로 포착하고 처리하여 성능과 유지 관리성을 유지할 수 있습니다.

마무리: 깔끔하고 유지보수하기 쉬운 코드를 작성하세요

데릭은 영상 12분 45초에서 이러한 실수들을 자신이 목격한 것일 뿐만 아니라 대규모 비즈니스 시스템을 구축하는 과정에서 자신이 직접 저지른 것이기도 하다고 결론짓습니다. 이것들은 경험을 통해 얻은 교훈이며, 그는 시청자들에게 댓글로 자신의 실수담을 공유해 달라고 권합니다.

데릭의 조언은 C#뿐만 아니라 다른 여러 언어에도 적용됩니다. 문자열 비교, Equals() 메서드 사용, 또는 새로운 기능 설계 등 어떤 작업을 하든 핵심은 명확성, 의도, 그리고 유지보수 가능한 코드 유지입니다.

C# 실력을 향상시키고 흔히 발생하는 실수를 피하고 싶다면, 데릭의 채널에서 시스템 아키텍처, 디자인 패턴, 실제 프로그래밍 언어 활용법 등 다양한 무료 자료를 확인해 보세요. 이러한 실수 중 하나만 피해도 프로젝트의 품질을 크게 향상시킬 수 있습니다.

그러니 다음에 코드를 작성할 때는 데릭의 말을 기억하고 "내가 이 코드를 필요 이상으로 복잡하게 만들고 있는 건 아닐까?"라고 자문해 보세요.

더 많은 콘텐츠를 보려면 데릭 마틴의 CodeOpinion 유튜브 채널을 확인하세요.