개발하실 때, 어느 정도의 확장성을 고려하시나요?

[jeongwoo903]

Q. 개발하실 때, 어느 정도의 확장성을 고려하시나요?

최근에 함께 프로젝트를 하시는 팀원 분이 모달 컴포넌트를 작성해 주셨는데, 코드 자체는 견고하게 잘 짜여져 있었습니다.
다만 해당 컴포넌트가 프로젝트의 도메인이 나오지 않은 상황에서 만들어졌는데, 개인적으로는 확장성 좋게 짜이긴 했지만 로직이 복잡하고 추상화가 과하다는 생각이 많이 들었습니다.

이 코드를 보면서 많은 생각이 들었는데요.
저 또한 기준이 모호한 것 같아 질문을 올리게 되었습니다.

컴포넌트를 개발할 때, 초기부터 확장성을 염두에 두고 설계하는 것과 실제 확장이 필요해졌을 때 리팩토링으로 대응하는 것 사이에서 가끔 고민이 듭니다.

처음부터 유연한 설계를 하자니 코드가 과도하게 추상화되거나 복잡해질 수 있고, 반대로 현재 요구사항에 집중하면 나중에 확장이 어렵거나 기술 부채로 이어질 수 있다고 생각하기 때문인데요.

어떤 기준이나 원칙을 가지고 확장성을 고려하고 계신지 말씀해 주시면 큰 도움이 될 것 같습니다!

[Imjurney]

기획혹은 도메인에 따라 다를 것 같은데
유저가 할 것 같은 보통의 일련의 행동을 고려해서 리스트화해 확장을 고려합니다. 이걸 공용으로 잡습니다.

오히려 동 떨어지는 부분은 같은
디자인이라도 디자이너와 얘기해서 베리에이션을 다시잡거나, 디자인을 유지해야한다면 컴포넌트이름만 바꿔서 새로 만드는 편입니다.

관심사의 분리인데 결국 내 기준이 아니라 타인의 기준에서 항상 생각하려고 하며 타인의 제 코드의 사용량이 높은지 낮은지를 지켜보며 추상화를 조절하려고합니다🙂

[jeongwoo903]

도메인과 유저의 행동을 먼저 고려한 후 확장성을 고려한다는 순서가 막연한 확장성을 방지하는데 도움이 되는 말인 것 같아요!
생각을 정리하는데 도움이 되었습니다!! 좋은 말씀 감사합니다 ☺️

[Imjurney]

오타가 가득했네요 ㅎㅎ 오전에 쓰느라 조금 정신없었나봐요. 죄송해요.
"이렇게 짰을 때 다른 사람이 쓰기 편할까?" 한 번 더 생각하며 코드를 짜긴합니다. 저도 하다보면 방대해질 때 있습니다🥲

크게는 상태 별(사용자 입력에 의해서냐, API에 의해서냐), 텍스트 + 아이콘등 조합 종류 이렇게 큰 두덩이로 나눕니다. 기능적으로는 더 작은 단위로 나눌 수 있으나 인지했을 때 너무 파편화되는 경우는 조금 합쳐서 컴포넌트를 만들어요.

여러가지 방법으로 많이 짜고 타인의 의견을 많이 물어보는 것도 좋은 방법일 듯해요.

좋은하루 되세요. 감사합니다.