컴포넌트, 로직 분리 (추상화, 구성 관점)

Date
Tags
 
notion image
  • 프로필 터치 시 상황에 따라 핸들링 되는 경우가 많아서 별도 훅으로 분리한 것 자체는 좋다.
  • handlePressProfile 이라는 이름으로, 프로필 터치 전체를 핸들링하는 느낌을 주는데 그렇지 않다.
  • 훅에서는 함수 종류들을 반환해 줄 뿐이며, 훅을 사용하는 곳에서 로직을 한번 더 작성해줘야 프로필 터치 처리가 완성된다.
  • 프로필 터치 처리에 대한 책임이 분산되어 유지보수 측면에서 아쉬움이 있다.
  • 해당 로직까지 훅 안에서 정의 한 후, 사용하는 곳에서는 단순히 반환된 함수를 사용하도록 하는 형태가 훨씬 좋다.
 
notion image
  • 리턴문에서 로직들을 다 풀어가고 있어서, 한눈에 보여야 할 컴포넌트 구성이 눈에 들어오지 않았다.
  • 아이콘 판별이라는 하나의 목적을 가진 로직을 별도로 묶어주고, 추상화된 결과물을 사용함으로써, 리턴문에서의 컴포넌트 구성이 한눈에 보일 수 있게 되었다.
 
notion image
  • 전체적인 구성을 하는 곳에서는 추상화된 로직들의 조합으로 “구성이 명확히 한눈에” 들어와야 한다.
  • 구성이 보여야 하는 곳에 풀어져있는 로직이 있다면 가독성을 떨어트린다.
  • 별도의 로직으로 분리 및 추상화 레벨을 맞춤으로써 가독성을 향상시키고, 기능별로 분리되므로 유지보수성도 챙길 수 있다.
 
notion image
  • 엔진 특성상, 슬립모드에서 깨어난다는 것이 유저의 사용을 뜻하므로, 여기에 물려있는 로직들이 많이 있다.
  • 현재 점검 중인지 여부를 판단하는 로직이 추가되었는데, 여러 로직들이 묶이는 곳에 곧바로 코드를 작성하여 가독성이 악화되었다.
  • 여러 로직들이 공존하는 곳에서는 기능별로 로직이 분리 및 추상화되고, 사용하는 쪽에서는 무엇이, 어떻게 사용되는 지만 명확하게 보이도록 만드는 것가독성유지보수 측면 모두 챙길 수 있는 방향이다.
 
notion image
⇒ 이후 이렇게 설계되면 안되는 이유와, 내가 생각하는 올바른 방향을 오프라인에서 대화를 나눔.
⇒ 이후 별도 PR 작업하여 리팩토링 태스크 진행하였음. (태스크 담당자에게 맡기고 싶었으나, 시간 관계상)
 
notion image
  • 전체적인 구성과 흐름을 봐야하는 곳에서는 그 흐름이 명확히 보일 수 있도록 구성시켜야 한다.
  • UserCell이 어떻게 구성되는지 등 한눈에 보여야 하는 로직이 있는데, 구체 함수 정의문이 길어서 방해가 된다.
  • 별도 훅으로 분리 및 추상화 시켜줌으로써 해결한다.
 
notion image
  • 비슷한 로직인데 추상화 레벨이 각각 달라서 코드 이해에 혼란을 주고 있었다.
  • 따라서 추상화 레벨을 같게 맞추도록 제안
 
notion image
  • 인터페이스 없이 클래스를 바로 작성하고 있다.
  • 무결성 관련된 클래스는 내부 처리 방식이 달라질 가능성이 있으므로, 인터페이스를 빼주는 것이 좋다.
    • e.g. 1차엔진, 2차엔진, 2차엔진 B2C 등 상황에 따라 달라질 수 있음.