⭐고광필
블로그에 작성한 회고글입니다
⭐김동언
아쉬움이 많이 남는 과제였던 것 같다. 과제를 시작할때만 해도 클린코드를 지향하겠다는 마음가짐이었는데 프로젝트를 진행하면서 계속해서 갈아엎는 과정을 거치며 마음가짐도 같이 갈아 엎어진것 같다. 그냥 작동되는 것을 목표로 무턱대고 하드코딩한 점이 아쉽다. 리팩토링을 진행할 생각인데 실력이 부족해서 한다고 해도 그렇게 많이 변할것 같지는 않다. 많이 부족하다는게 느껴져서 더 열심히 해야겠다는 생각이든다. 그리고 css 관련해서도 하면 하지 라는 마음으로 미뤘었는데 막상해보니 생각한대로 스타일링도 안되고 시간도 많이 잡아먹은 것 같다. 평소에 작은과제라도 css 스타일링을 적용하면서 익숙해져야겠다.
⭐박민제
노션 클론 프로젝트 회고⭐이상진
과제 내용을 다 수행하지는 못했지만, 프로젝트 진행 과정에 있어서 많은걸 배울 수 있는 시간이었습니다. 보이는 것보다 요구사항이 많을수도 있고, 요구사항 하나를 구현하는데도 버그나 중복입력 같은 요인들을 고려하다보면 시간이 훨씬 많이 지나있더라고요. 만든 코드가 잘 돌아가는지 테스트할 수 있는 환경을 만드는 것 또한 작업의 연속이었습니다. 바쁘게 보낸 시간인만큼 짧은 시간에도 많이 성장하는 것을 느낄 수 있었습니다! 모두 고생하셨습니다!
⭐조채우
스스로 생각하지 못한 부분이 아쉽지만 구글링을 하다가 1기 선배 님의 글을 읽고 프로젝트의 구조에 대해서 깊게 생각할 수 있었고, 거기에 힘을 얻어 중앙 처리 방식으로 프로젝트 전체를 리팩토링 할 계기가 되었습니다. 아직 부족한 부분이 많지만 Redux의 구조를 라이브러리에서 사용하는 것이 아닌 스스로 하나의 구조를 직접 구현하는 것이 매우 좋은 경험이었다고 생각합니다. 아직 모자란 부분과 버그도 많지만 이 또한 하나의 성장 발판이라 생각하며 앞으로 계속해서 이를 고쳐나갈 생각입니다.
🥞 팀단위 프로젝트 회고&토의
🧇웹페이지 개발 절차
각자 어떤 방식으로 페이지를 구현할 계획을 세웠는지 의견을 나눴다. 광필님, 민제님, 상진님의 경우에는 일단 html만으로 페이지의 대략적인 뼈대를 세워본 뒤 컴포넌트를 하나씩 하나씩 만들어가는 방식으로 계획을 세웠다. 동언님께서는 우선 몇개의 슈퍼 클래스를 만든 다음, 기능의 분화가 필요하다싶으면 새로운 파일을 만드는 방식으로 개발을 하셨다. 한편 채우님께서는 핵심 컴포넌트를 우선 구현한 다음, 중요도에 따라 다음 기능을 구현하는 방식으로 개발을 하셨다.
회고록을 읽어보면 많은 분들이 말단 기능부터 구현한 뒤 나중에 합치는 방법을 택했다는 것을 알 수 있었다. 이런 방식은 독립적인 기능을 개발하는데에는 적합하지만, 나중에 여러 기능을 한 페이지에 넣었을 때 예상치 못한 문제가 생길 수 있는 것 같다. App과 같은 제일 높은 단위의 컴포넌트부터 구현해서 오류를 최소화할 수 있으면 좋겠지만, 당장의 환경에서는 앱의 모든 흐름을 예상하고 만들기에는 무리가 있어보인다.
🧇State관리와 데이터 흐름
각 컴포넌트의 핵심적인 데이터와 상태를 담고있는 state어떻게 관리하는지 의견을 나눴다. 크게 보면 App과 같은 최상위 컴포넌트에 state 관리를 “중앙집권적”으로 구현한 분들과 각 컴포넌트가 필요한 state를 알아서 관리하는 “지방분권적”으로 구현한 분들이 나뉘어있었다.
App에서 State 저장과 수정, 이를 반영하는 컴포넌트 갱신을 맡긴 분들은 state흐름을 파악하는데 매우 용이하고, 독립적으로 만들어졌던 컴포넌트들을 한 페이지에 넣을 경우 부작용이 적을 것이라는 생각이 들었다. 하지만 App에서 state 관리를 도맡다보니 말단 컴포넌트에서 state에 변화를 주면 콜백을 통해 App까지 전달을 해야한다는 문제점이 있었다. 반대의 방법으로 구현을 한 사람들은 정반대의 장단점을 가졌었다.
어쩌면 state는 적당히 큰 단위의 하위 컴포넌트에 위임하고, fetch 하는 함수에 래퍼 함수로 감싸 안에 App을 호출하는 함수를 넣는 것이 적절할지도 모르겠다. 이렇든 저렇든 아직 어떤 방식으로 하는 것이 사이드 이펙트를 더 줄일 수 있는지 몰랐기 때문에, 돌아오는 로토님과의 세션이나 멘토님과의 면담 시간에 물어보기로했다.
🧇폴더 분류법
웹개발 프로젝트의 폴더 구성방법에 대한 의견을 나눴다. 많은 경우 각 컴포넌트별로 폴더를 만들고, 안에 하위 컴포넌트 파일을 넣는 방법으로 프로젝트 폴더를 구성했다. 하지만 이때 컴포넌트 파일을 얼마나 세세하게 쪼갰냐에 따라 경로가 지나치게 깊어질 수 있다는 문제점이 있었다. 이 외에도 각 컴포넌트에 적용할 css는 따라오기 힘들다는 문제가 있었다.
광필님이 여기에 본인이 알고있는 것을 공유해주셨는데, 위와 같은 이유 때문에 각 회사들은 정해진 디자인 패턴에 따라 적절한 크기의 컴포넌트 아래로는 하위 폴더를 더이상 만들지 않거나, 각 컴포넌트에 적용되는 css파일을 js파일과 함께 배치한다고 했다.
🧇컴포넌트 구분
어떤 기준을 가지고 각 컴포넌트를 파일별로 나누는지에 대해 의견을 나눴다. 현재 데브코스는 컴포넌트별로 js파일을 나누었기 때문에, 컴포넌트를 너무 크게 만들면 재사용성이 떨어지고, 작게 만들면 state흐름 관리와 파일 간의 관계가 지나치게 복잡해질 수 있다는 문제가 있었다. 이에 대해 팀에서는 크게 UI로 먼저 나눈 다음, 동적으로 생성되는 요소인지 또는 재사용을 할 수 있는 요소인지에 따라 별개의 컴포넌트로 나누는 것이 좋다는 결론을 내렸다. 예를 들어 이번 프로젝트의 사이드바에 있는 Document Tree의 경우 Document의 상태에 따라 동적으로 생성, 수정, 삭제되므로 별개의 컴포넌트로 분리하는게 좋을 것이다.