[포스팅 리뷰] Simple code scales better than "scalable" code.

You're Not Building Netflix: Stop Coding Like You Are

과도한 추상화

이 글에서 다루는 내용은 과도한 추상화에 대한 이야기다.

---

나는 개발을 하기시작한지 3년이 넘어가며 Clean Architecture, DDD, TDD, Hexagonal, Port & Adaptor, XP 책, 수많은 기술블로그 아티클, 강의와 다양한 패턴에 대해서 설명하는 글들을 많이 읽고나서는 하나의 정답처럼 여겨지는 코드들의 부산물들이 내 머릿속에 있었다. 

그것은 마치 "인터페이스가 없는 클래스는 죄악이다", "모든 것은 DI로 해결해야 된다.", 확장 가능성이 없는 코드는 Legacy다" 같은 강박들이었다.

간단한 기능 클래스를 하나 추가할 때도 습관적으로 Interface, Factory, Strategy 같은 폴더를 만들고 있었다.

나는 회사에서 일을 할때도 "혹시 모를 확장"에 대해서 고민했었고, 과거 내가 만들어둔 추상화 계층은 그때의 비즈니스 요구사항과 미묘하게 맞지않아 뜯어 고쳐야 했다.

 

동의한다

추상화는 공짜가 아니다. 그것은 인지적 부채다.

---

"구현체가 하나뿐인 인터페이스는 IDE에서 클릭수를 늘리고 코드를 리뷰하는 것에 방해가 된다"는 내용에 나도 동의한다.
"단순한 코드가 확장 가능한 코드보다 더 잘 확장된다"라는 저자의 말을 수용한다. 

이런것들이 쌓였을때 개발 생산성을 저해 한다는 불안감을 느꼈었고, 복잡하게 얽힌 "세련된" 코드보다, 조금 멍청해 보이더라도 직곽적인 코드가 유지보수가 훨씬 쉬었던 경험이 나한테도 분명히 있었기 때문이다.
그럼에도 불구하고 "최소한의 안전장치"는 필요하다고 생각한다.

글쓴이는 jest.mock()이 있으니 테스트를 위해서 인터페이스를 만들필요가 없다고 말한다. 하지만 이것은 절반만 맞는 말이라고 생각한다.
구현체에 강하게 결합된 코드는 테스트 코드조차 내부 구현을 알아야 하게 만든다. 
반면, DIP(의존성 역전)를 통한 인터페이스를 테스트하는 것은 행위에 집중하여 테스트를 작성하도록 돕는다.

또한, 구현체가 하나뿐인 인터페이스가 과연 무용지물일까?

다수가 같이 협업하는 환경에서는 "설계도 이자 약속"이라고 생각한다.
인터페이스를 먼저 정의함으로써 개발자들은 내부 구현이 완성되지 않아도 서로 협업할 수 있다. 이는 "코드의 복잡도"를 높이는 것이 아니라, "커뮤니케이션 비용"을 낮추는 역할을 한다.
이 글의 제목을 따라하여 모든 팀원이 "넷플릭스 급" 실력을 갖춘 것이 아니기에, 강제된 패턴은 때로는 스파게티 코드를 막는 최소한의 안전장치가 되어준다. 

 

아키텍처

아키텍처는 목표가 아니라 도구다

---

아키텍처를 하지 말자가 아니라 적재적소에 써야된다. 
마치 인터페이스로 일종의 규약을 정하는 것처럼 아키텍처의 과도한 추상화를 막기위한 장치에 대한 리스트가 마음에 든다.

1. Rule of Three
2. YAGNI
3. 변화하는 것을 추상화. 안정적인것을 추상화하지말자.
4. 테스트가 훨씬 쉬워진다.

또한, 대부분의 추상화가 다음과 같은 오류로 생성이 된다고 한다.
꼭, 자신에게 질문을 해보자.

1. 책에서 읽고
2. 전문적인거 같아서
3. 지루하니까 도전적으로
4. 세련되지 못한 모습의 두려움

 

 

패턴 중독

Simple code scales better than "scalable" code.

---

패턴 중독은 어쩌면 성장을 위한 필연적인 과정이라고 생각한다. 이렇게 시도를 함으로써 감춰져있던 사실들을 알게되니까, 
저자가 적은 코드 적으로 가장 훌륭한 코드에 대한 내용도 동의한다. 
세련되고 패턴을 잔뜩 바르고 박사들이 이해할수있는 코드가 아니라, 동료가 읽었을 때 어 이게 다야 ? 라고 느낄만큼 쉬운 코드라는것을 명심하자.