https://itnext.io/what-are-the-hidden-costs-of-over-abstracting-your-codebase-8b6a8ab0ab2b

https://itnext.io/what-are-the-hidden-costs-of-over-abstracting-your-codebase-8b6a8ab0ab2b

What Are the Hidden Costs of Over-Abstracting Your Codebase?

Over-abstraction is like wrapping a simple gift in so many layers that no one can open it — including you.

itnext.io

모든 개발자는 깔끔하고 재사용 가능한 코드를 좋아합니다. 추상화는 마치 초능력처럼 느껴지지만, 그렇지 않은 경우도 있습니다.

저는 인정하고 싶지 않을 정도로 지나친 추상화의 늪에 여러 번 빠져봤는데, 말처럼 화려하지는 않았습니다.

이 글에서는 '완벽한 추상화'에 대한 집착이 어떻게 역효과를 냈는지,

왜 그것이 프로젝트를 더 어렵게 만들었는지(개선이 아니라), 같은 실수를 피하는 방법을 공유해 보려고 합니다

1. 복잡성: 단순함을 혼돈으로 바꾸기

경력 초기에 저는 모든 서비스의 모든 요청 유형을 처리할 수 있는 범용 API 클라이언트를 만들겠다는 기발한 생각을 했습니다.

URL, 매개변수, 페이로드를 동적으로 구성하는 함수를 만들 수 있는데 왜 각 엔드포인트에 대해 새 함수를 작성해야 하나요?

천재적인 생각이죠? 6개월 후, 제 '걸작'은 유지보수의 악몽이 되었습니다.

새로운 서비스에 필요한 헤더나 고유한 응답 형식 등 요구 사항이 조금씩 달라질 때마다 추상화에 조건부 로직을 더 추가해야 했습니다.

결국에는 너무 비대해져서 실패한 요청을 디버깅하는 것이 폭탄을 해체하는 것처럼 느껴졌습니다. 최악의 부분은?

팀의 한 후배 개발자가 "그냥 각 서비스마다 별도의 함수를 작성하면 안 되나요?"라고 물은 적이 있습니다.

저는 웃어넘겼지만 마음속으로는 그 말이 맞다는 것을 알았습니다.

교훈: 지나친 추상화는 단순화된 것이 아닙니다.

복잡성을 레이어 아래에 숨길 뿐입니다.

그리고 이러한 레이어가 쌓이면 코드 탐색이 불가능해집니다.

2. 성능 병목 현상: 추상화로 인해 속도가 느려지는 경우

한 프로젝트에서 저는 프런트엔드 양식 작성기를 추상화했습니다.

텍스트 필드, 드롭다운, 체크박스 등 스키마에 따라 동적으로 입력을 생성할 수 있었습니다.

저속 기기에서 양식을 로드하는 데 3초가 걸린다는 QA의 보고가 있을 때까지는 꽤 자랑스러웠습니다.

왜 그럴까요? 각 필드는 구성 요소를 초기화하고 유효성 검사 규칙을 처리하며 불필요한 리렌더링을 트리거하는 정교한 팩토리 패턴을 거쳤기 때문입니다.

지금 생각해보면 존재할 필요가 없는 코드를 프로파일링하고 최적화하는 데 며칠을 소비했습니다.

특정 양식의 필드를 하드코딩했다면 성능 문제 없이 절반의 시간으로 완료할 수 있었을 것입니다.

교훈: 추상화에는 비용이 존재합니다.

더 많은 계층을 추가할수록 성능을 저해하는 비효율성이 발생할 가능성이 높아집니다.

3. 온보딩 문제: 신입 개발자를 겁주기

몇 년 전, 저는 모든 것이 추상화된 프로젝트에 합류했습니다. 모델에는 모델에 대한 인터페이스가 있었고,

서비스에는 다른 서비스를 호출하는 팩토리가 있었습니다.

간단한 사용자 프로필을 업데이트하는 것조차 추상화의 미로 속으로 깊이 파고들어야 했죠.

"이 기능의 로직은 어디에 있나요?"와 같은 질문을 하고 "유연성을 위해 세 개의 추상화 계층으로 나뉘어 있습니다."와 같은 답변을 들었습니다.

무엇을 위한 유연성인가? 프로젝트가 너무 경직되어 새로운 기능을 추가하는 것이 마치 카드의 집을 수술하는 것처럼 느껴졌습니다.

(역주: 카드의 집은 자주 나오는 표현인데, 한국어에서는 사상누각정도로 표현되는듯)

교훈: 지나친 추상화는 속도를 늦출 뿐만 아니라 팀원을 소외시킵니다.

코드를 상속받은 다음 개발자는 여러분의 이름을 저주할 것입니다, 업보니 받아들이세요

4. 경직성: 유연성 신화

과도한 추상화의 가장 아이러니한 부분은 무엇일까요?

추상화는 코드를 더 유연하게 만들어야 하지만 종종 그 반대의 결과를 가져온다는 것입니다. '

모든 유형의 변환'을 처리하도록 추상화된 데이터 파이프라인을 작업한 적이 있습니다.

클라이언트가 추상화에 맞지 않는 사용자 정의 기능을 요청하기 전까지는 훌륭하게 들렸습니다.

기능을 추가하는 대신 전체 파이프라인을 리팩터링하여 호환되도록 해야 했습니다.

결국에는 추상화가 너무 왜곡되어 원래 설계와 거의 닮지 않게 되었죠.

더 나쁜 것은 며칠이면 끝날 일을 몇 주나 허비했다는 것이었습니다.

교훈: 지나친 추상화는 요구사항이 바뀌는 순간 깨지는 경직된 구조에 갇히게 합니다.

때로는 단순하고 구체적인 것이 일반적이고 추상적인 것보다 낫습니다.

과도한 추상화를 피하는 방법

1.구체적인 솔루션으로 시작하세요

대부분의 경우 모든 사용 사례에 일반적인 유틸리티나 팩토리가 필요하지 않습니다.

간단하고 구체적인 코드를 먼저 작성하세요. 추상화는 필요한 경우 나중에 추가할 수 있습니다.

2.유지 관리에 대해 생각하세요

다른 레이어를 추가하기 전에 스스로에게 물어보세요: "다른 사람이 6개월 후에 이 기능을 이해할 수 있을까? 내가 6개월 후에 이해할 수 있을까?"

3.3의 법칙을 받아들이세요

같은 문제를 적어도 세 번 이상 겪어보기 전까지는 추상화하지 마세요.

성급한 추상화는 불필요한 복잡성의 근원이 됩니다.

4.추상화를 정기적으로 검토하세요

요구 사항이 진화함에 따라 추상화가 더 이상 의미가 없을 수도 있습니다.

더 이상 코드베이스에 도움이 되지 않는 것은 리팩터링하거나 심지어 삭제할 준비를 하세요.

----

읽고나서 너무 좋은 글이라 가져와봤다.