클린코드&테스트 - 추상과 구체

요즘은 코드를 잘 짠다 = 읽기가 좋다 = 가독성 있다 , 라는 말을 많이 하는 것 같습니다.

저 또한 매우 동의하는 말인데요 하지만 개인적으로 "가독성 있다"라는 말 또한 추상적인 개념이라 생각합니다.
가독성 있는게 좋아? , 그럼 어떤 코드가 가독성 있는건데? 라는 질문을 받게 되는 것이죠

그래서 우리는 "가독성 있는 것"에 대한 기준이 필요한데 저에게는 "직관적이냐" 입니다.

다음은 제가 좋아하는 3-Tier Architecture인데요 이것을 처음 봤을 때 느낀것은 정말 직관적이다 였습니다.

계층과 책임이 너무 명확히 나눠져있어서 누가 봐도 이해가 가능한, 이런게 "직관적이다" 라고 생각하고
이런 직관적임을 코드레벨까지 성공적으로 가져 왔을 때 곧 읽기좋은 코드가 된다 생각합니다.

 

 

 

저는 추상화를 이렇게 정의합니다,  무언가를 간추린다.
무언가를 간추린다면 전부 추상화에 해당하며 적용되는 범위또한 굉장히 넓다 생각합니다. 

예를 들어 우리가 "탈 것"이라는 인터페이스를 만든다면 이는 추상화 정도가 굉장히 높은 타입을 설계하는 것과 동일 하거든요
"탈 것"이라는 타입은 추상화 정도가 너무 높아 , 구체화가 없고 단순히 명시만 돼있는 Specification의 역할만 하는 것이죠.

단순히 말하면 야 너는 어떻게 하는지는 너 마음인데 , 가속이랑 감속은 가능해야 한다? 같은 것이죠 
따라서 구체화된 코드 없이 메서드의 Spec만 명시합니다.

"탈 것"을 구현한 "자동차"라는 타입을 만들고 이에 대한 api를 제공한다면 이 또한 추상화입니다.
api라는 통로를 이용해 외부에서 이 자동차라는 타입이 어떻게 설계되고 내부적으로 어떻게 동작하는지를 몰라도 
사용할 수 있게 됐기 때문입니다.

우리가 docker run 명령어를 사용했을때 내부적으로 어떻게 동작하는지 정확한 이해와 함께 쓴다고 생각하진 않습니다.
아 이 명령어는 = 이 api는 이런 동작을 하는 구나~ 정도의 이해만 가지고 있는 것이죠 

이렇게 api는 외부에서 접근 가능한 일종의 추상계층으로서 역할을 하게 됩니다.

저는 정보를 숨기는 것 , 절차를 간추리는 것 , 데이터를 간추리는 것.... 이 모든 것이 추상화의 영역이라 생각합니다.

마침 1년 전쯤에 추상화에 대한 글을 작성한 적이 있는데요 많이 부족한 글이지만 첨부해봅니다.

Abstraction(추상화) 기본 개념 - 1편

 

 

 

제가 이번 세션에서 가장 인상깊게 들었던 부분은 추상화 레벨인데요 

같은 세계에서는 추상화의 정도가 같아야 한다. 라는 의미입니다.
와 이건 정말 생각하지 못했던 부분이라 놀랐는데요 

이런 피드백을 한번쯤은 들어보셨을 겁니다.

"메서드 여러개로 분리해라" 

이유는 간단한데요 거대한 기능을 하나의 메서드로만 관리하면 너무 많은 책임을 갖게 됩니다.
기능이 고도화 될 수록 메서드는 더욱 거대해지고 이는 직관적으로 표현하기가 어려짐을 의미합니다.

따라서... 책임의 분리 -> 직관적인 표현 + 유지보수의 편의성을 위해 메서드를 분리 하는 것인데요

하지만 "그럼 정말 모든 메서드를 기능별로 하나하나씩 쪼개서 최대한 작은 단위로 만들어야 하나?" 라는 질문을 한다면  
저는 아니요 라는 답변을 할 것입니다.

여러 행위를 한다 해도 그것이 하나의 주제와 문맥으로 설명 가능하다면 하나로 만들어도 된다 생각합니다.

왜냐하면 메서드가 많아지는 것도 직관적인 것과는 거리가 멀어지기 때문입니다.
메서드를 분리한다는 것은 결국 코드의 양이 늘어난다는 것이며 누군가가 내 코드를 다룰 때 찾아봐야 하는 부분 또한 늘어납니다.
따라서 마냥 쪼개는 것이 좋다고는 생각 안합니다.
 

그리고 이런 고민은 커밋을 할때도 똑같이 발생 하는데요
커밋도 한번에 많은 양을 올리지 마라 , 쪼개서 하나의 단위씩 올려야 좋다. 라고 말하곤 합니다.
그럼 정말 하나의 코드 변경 = 1커밋 이여야 할까? , 만약 우리가 리펙토링을 통해서 이름을 변경했다고 했을 때
A이름변경 , B이름변경 , C이름변경 ......... 이렇게 이름변경에 관한 커밋을 수십개씩 쪼개놓았다면 어떨까요?

코드를 리뷰하려고 봤는데 커밋이 수십개씩 쌓여있으면 리뷰하기가 겁나는 경험이 있으실 겁니다.
설령 그것이 큰 내용이 없는 코드라 할지라도 너무 잘게 쪼개져있으면 집중력있게 리뷰하는 것은 어려워 집니다.
중요한 변경사항이 아니라면 차라리 묶어서 표현하는게 좋지 않을까요? User 관련 객체 이름변경.. 등으로

 

이렇게 되면 머리가 아파집니다. 무작정 쪼갤수도 , 무작정 합칠수도 없다면 무엇을 기준으로 쪼개고 합쳐야 하나?? 라는 것이죠
이 추상화 레벨에 대한 것은 판단에 대한 하나의 기준이 될 수 있다 생각합니다.

-> 지금 얘가 가지고 있는 추상화 레벨의 정도가 주변의 것들과는 조금 다른거 같은데??
-> 위에는 전부 강하게 추상화하여 구체화를 숨기고 명시적으로 어떤 기능을 할 것임만을 말했는데 갑자기 구체화가 등장하네??
-> 아 이거는 메서드 분리 해야겠다

와 같은 흐름을 통하는 것이죠 , 이 부분에 대해서는 기존에 생각했던 것이 아니라 참 인상깊은 부분이였습니다.