오늘은 모듈 구조에 대해 팀원들과 이야기 했다.
현재 모듈들의 연결 상태이다.
당장에는 기능을 구현해서 실제로 동작하는지 확인하는 것이 급하기 때문에 모듈들의 관계를 생각하지 않고 APP모듈에 다 넣고 있다.
좋지 않은 형태 이었다.
모듈간에 서로 관계가 있어야 하는 경우가 있기 때문이다.
예를 들어 특정 학습 공간에 있는 학습공간멤버에 대하여 어떤 학습공간그룹의 멤버인지 찾기 위해서는 4개의 모듈이 서로 관련되어 작업하여 결과를 만들어 내야 하기 때문이다.
그냥 서비스를 exports하고 imports하면 되는 것이 아니냐고 할 수 있다.
이는 맞는 말이지만 앞으로 추가적으로 더 많은 기능을 구현할텐데 모듈들이 서로 exports하고 imports를 했을 때 구조를 생각하지 않고 막 했다가는 프로그램을 이해하기 어려워지고 순환 오류가 발생할 수 있다.
확장성과 유지보수 측면에서도 부정적인 영향이 클 것이다.
그렇기 때문에 어떻게 모듈을 구조화 할지 논의 했다.\
논의 이후 모듈 예시(미완성)이다.
논의 결과 작업을 수행하는데 있어서 서로 연결될 필요가 있는 모듈을 연결했다.
이때 작은 모듈들이 뭉쳐 큰 모듈을 만드는 방식으로 설계 하였다.
저희 프로젝트에서 큰 모듈들은 대부분 작은 모듈들을 끌어다 써야 했다.
그렇기 때문에 작은 모듈들이 자신의 책임과 역할을 제대로 수행한다면 큰 모듈들도 자신의 책임과 역할을 제대로 수행할 수 있게 된다.
또한 NestJS에서는 SOLID원칙을 지키는 것을 권장하는데 여기서 S인 단일 원칙 책임을 큰 모듈의 일을 하위의 작은 모듈에게 맡김으로써 지킬 수 있다.
이를 통해 유지보수 측면과 확장성 측면에서도 유리해진다.
모듈들이 상하관계를 가지때문에 프로그램을 이해하는 것이 더욱 쉬워질 것이다.
위 방식외에도 Event Emitter와 같은 방식을 사용해 이벤트 기반으로 모듈들이 느슨한 결합을 가지게 해보자는 계획도 있다.
지금 당장에는 어떻게 구조를 고쳐보자라는 계획이 정확히 세워지지는 않았지만, 구조를 잡기 위한 논의와 노력이 계속될 것이다.
느낀점
오늘 논의에 대해서 팀원 분 중 한명이 의견을 제시했는데 나는 이론적 지식을 바탕으로 고민해보기 보다는 상상력을 바탕으로 구현을 먼저 해보고 필요한게 생기면 그 때 가서 필요한 기술을 적용해보느라 고민하는 스타일인데, 팀원분의 예리한 의견에 내가 미처 생각하지 못 한 부분을 다시 생각해보게 되었고, 더 좋은 방법을 도출 하기 위해서 고민하고 더 나은 방법을 찾아가는 과정이 나에게 정말 필요한 부분인 것 같아서 좋았다.
