20 08 회고
컴포넌트에서 @Store.State('stateName') stateName!: StateNameInterface 형태로 사용한다. 하지만 StateNameInterface는 Store의 State 타입을 직접적으로 알고 있을 때 사용 가능하다. Store의 State 타입 정의부가 변경되면, 컴포넌트도 변경이 필요하다. 때문에 타입을 사용하는 방법에 개선이 필요하다.
Store의 State를 참조하는 형태로 수정하면 현재 문제점이 개선 가능하다.
- [AS IS]
@Store.State('stateName') stateName!: StateNameInterface - [TO BE]
@Store.State('stateName') stateName!: StoreState['stateName']
- class를 Prop으로 전달 받는 방식은 버튼 사용 시, 요구하는 게 두가지 있다.
- 컴포넌트 사용방법과 적절한 상수이 두가지를 알아야 사용가능하다.
- color를 Prop을 받는 방식은 요구하는 게 하나다.
- 컴포넌트 사용방법만 알고 있으면 해당 버튼을 구현할 수 있다.
컴포넌트를 사용하는 데 필요한 인터페이스를 정의할 필요가 있다. 암묵적으로 컴포넌트 파일을 열어 Prop과 Emit에 대한 정보를 파악하게 되는 데, 이렇게 되면 구현을 직접 참조하게 되고, 참조한 타입으로 변화가 필요할 때 많은 부분을 수정해줘야 한다.
때문에 컴포넌트의 인터페이스를 정의하고, 인터페이스를 사용하는 형태로 수정이 필요하다.
컴포넌트 볼륨이 커서 스크립트 코드 작성 후 다시 해당 탬플릿으로 돌아가기 힘들다. 컴포넌트 볼륨이 커질 때를 대비해서 컴포넌트 쪼개는 작업은 우선순위를 높이는 게 좋을 듯 하다.
응집성을 가지는 방법은 크게 두가지가 있다고 생각한다. 첫번째는 기능에 따른 응집성, 두번째는 추상화 방법에 따른 응집성이다.
프로젝트에서 추상화 방법에 따라 응집성을 가지도록 했다. 추상화 방법에 따라 응집성을 가지게 되면 개발시 약간의 어려움이 있다.
추상화 방법으로 그루핑된 폴더를 찾아가며 추가/수정을 해줘야 한다. IDE에 폴더 트리와 파일이 파편화되어 있음으로 기능이 추가될 때 번거로움과 피로감을 느꼈다.
결론적으로 응집성을 기능에 따른 응집성을 가지는 게 작업시 용이할 것으로 판단된다.
2020.08.19: 지금 다시 생각해봐도 기능에 따른 응집성이 작업에 용이하다 ㅠㅠ