DRY(Don’t Repeat Yourself)
코딩을 시작한지 얼마안됬을 때,
코드의 재사용성을 높이는 일이 굉장히 효율적임을 알게되면서 여기에 중독되었던 것 같다.
특히 컴포넌트화를 하며 중복되는 ui들은 재작업할 필요가 없어 view를 빠르게 작업할 수 있었고, 로직에 집중할 수 있었다. 또한 기능 수정이 필요했을 때 오로지 딱 한 곳만 수정하면 됐으니 유지보수하기 매우 편하다고 느꼈다.
하지만 시간이 흐를수록,
내가 개발했던 서비스는 점점 변화하고 발전했다.
기존과 비슷한 디자인을 가졌으나 약소하게 노출해야할 문자나 ui, 페이지가 달라졌다. 이땐 그 부분만 찾아가서 조건을 하나씩 추가하며 계속해서 같은 컴포넌트, 같은 페이지를 사용하도록 하고 만족했었다.
근데 이 변화는 점점 눈덩이처럼 커졌다. ㅠ
더는 조건으로 분기치며 동일한 컴포넌트와 페이지를 쓰는게 오히려 유지보수하는데 어려움을 느끼기 시작했다.
서비스가 어떻게 발전할지 몰라서 처음에는 간단한 분기처리를 했었어도 점점 그 변화가 커진다면, 시간을 내어 아예 루트 부터 다른 분기처리가 되었어야 한다.
짧은 경력으로 앞으로 재사용성을 뒤돌아보면
아무리 디자인이 유사하더라도 서비스의 성격, 대상이 다르다는 판단이 들면 페이지부터 분리하는 것이 좋겠다는 생각이 든다.
재사용성의 포인트가 디자인이어서는 안된다는 걸 느꼈다.
또한 지금 코드에도 남아있는 잔재같긴한데,
하나의 함수는 한가지 기능만 담당하는 단일책임원칙을 적용해보면 이 역시 지키지 못했는데...
함수조차 재사용하려고 한 흔적이 보인다. ㄷㄷ
예를 들어, 게시물을 생성하는 기능과 수정하는 기능의 ui가 유사하다하여
- 동일한 페이지를 사용하여 현재 생성인지 수정인지 type을 갖고있는 상태,
- type에 따라 이 함수내에서 생성 api를 사용할지, 수정 api를 사용할지 판단하는 상황..
그냥 페이지를 분리하거나, 함수 내에서 로직을 분기치기보다 처음부터 함수를 분리하는게 좋을 것 같다. 화면과 로직이 비슷해보여도 이 역시 서비스가 어떻게 변경될지를 몰랐던 것 처럼 기능이 어떻게 변할지 알 수 없기 때문이다.
정리해보면 ui에만 의존하거나 단순히 중복회피를 하기 위한 코드를 작성하지 말아야겠다. 의도된 중복인지를 생각해보며 적절한 기준으로 코드를 작성해야 할 것 같고, 기준 변경이 필요하다 생각이 들면 빠르게 리팩토링해야겠다.
아예 손도 댈수없는 상황까지 끌고가지말고........... 또륵
