HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
프로그래머스 프론트엔드 데브코스 2기
프로그래머스 프론트엔드 데브코스 2기
/
✌️
찬희팀
/
프로젝트 중간 점검(찬희 멘토)

프로젝트 중간 점검(찬희 멘토)

협업

회의를 주도하는 사람과 기록하는 사람을 분리하면 좋을 것 같아요.
회의록
을 살펴보니, 일부 회의 기록은 어떤 대화가 오고갔는지 파악하기가 어려웠어요. 혹시 회의를 주도하는 사람이 기록도 같이 하는 상황이라면, 서기 역할을 한 명이 맡아서 진행하는게 좋습니다. 회의는 보다 수월하게 진행하면서 보다 구체적으로 기록을 남길 수 있을 것 같아요.
서기는 단순히 회의 내용의 시작과 끝을 기록하는 속기사가 되어서는 안됩니다. 어느정도 실시간으로 기록은 해야겠지만, 결과적으로 그 날 진행했던 회의를 참고할 수 있는 “문서"를 만들어야 해요.

발표

현재 개발 상황을 브라우저에서 실행하면서 보여주면 더 좋을 것 같습니다.
중간 발표 영상에서 와이어프레임 대신 브라우저를 통해 (일부분이라도) 실제 동작하는 화면을 보여주면 더 좋았을 것 같습니다. 영상만 봐서는 어느정도로 진행이 되었는지 가늠하기가 어려워서 아쉬웠어요.

기술

컴포넌트를 비즈니스 로직과 프레젠테이션 로직에 맞게 나눠서 구현해봅시다.
컴포넌트는 재사용을 할 수 있어야하는데 제 컴포넌트에 데이터가 얽히면서 코드가 복잡해지고 이걸 다른 사람이 가져가서 활용할 수 있을까…. 고민이 듭니다… 일단 할 수 있는대로 구현에 집중하고 있습니다…ㅠ
흔히 “컴포넌트를 나눈다(쪼갠다)”고 합니다. 하지만 단순히 나눈다고 해서 재사용 가능한 컴포넌트를 만들 수 있는 것은 아니에요. 데이터(비즈니스 로직)와 UI(프레젠테이션 로직)의 결합도를 낮춰야 합니다. 데이터와 UI 로직이 섞인 컴포넌트는 재사용하기도 어렵지만, 나중에 유지보수하는 것도 어려워집니다.
개인적으로 Presentational-Container 패턴을 살펴보는 것을 추천드립니다. 이 패턴은 꽤 예전부터 사용하던 컴포넌트 작성 패턴인데, 시각적인 부분은 Presentational로, 비즈니스 로직은 Container로 컴포넌트를 나눠서 작성하는 패턴입니다. 그 외에도 인사이트에 도움이 될만한 아티클을 같이 첨부해드릴게요.
presentational and container 패턴이란 무엇인가
❗ 본 글은 Hook 개념이 없는 과거 리액트를 기준으로 쓰여진 글입니다. 리액트에서 과거에 자주 언급되고 활용되었던 패턴 중 Presentational and Container Components 라는 패턴이 있다. 처음 이 패턴을 소개한 Dan Abramov는 2019년 기준으로 현재는 이 패턴을 사용하지 말라고 언급하고 있다. (출처) 2019년 업데이트 : 이 아티클을 예전에 썼었고 이제는 내 관점이 달라졌다.
presentational and container 패턴이란 무엇인가
https://tecoble.techcourse.co.kr/post/2021-04-26-presentational-and-container/
presentational and container 패턴이란 무엇인가
프론트엔드 아키텍처: Business Logic의 분리
우린 왜 프론트엔드 아키텍처에 관심을 가져야 할까요? 프론트엔드 프로젝트는 충분히 복잡하기 때문입니다. 복잡하다는 것은 개발자가 프론트엔드 프로그램을 살펴볼 때 인지적인 한계에 부딪히게 된다는 사실을 의미하고, 이 사실은 개발을 진행할 때 뿐만 아니라 유지보수를 진행하는 데 비용을 증가시킵니다. 이런 문제를 해결하기 위해 우린 잘 설계된 프로그램을...
프론트엔드 아키텍처: Business Logic의 분리
https://medium.com/@shinbaek89/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-business-logic%EC%9D%98-%EB%B6%84%EB%A6%AC-adc10ae881ab
프론트엔드 아키텍처: Business Logic의 분리
프로젝트의 README.md 를 작성해주세요.
실제 프로젝트가 진행되는 상황을 확인하고 싶은데, 지금 상황에서는 REACT_APP_API_BASEURL 환경 변수를 추가해야 한다는 정보를 어디에서도 확인할 수가 없는 것 같아요. (혹시 별도 회의록이 있다면 알려주세요) 리드미에 환경 변수에 대한 정보를 포함해서 어떤 패키지 매니저를 사용하는지 등의 내용을 담으면 좋을 것 같아요.
이와 별개로 .env.sample 같은 파일을 커밋해두면 어떤 환경 변수를 기입해야 하는지 빠르게 확인할 수 있어서 편리합니다. 샘플 파일은 실제 환경 변수 값을 제외하고, 키 값만 추가해야 합니다. 아래 내용을 참고하세요:
아이콘 컴포넌트의 사용법이 적절하지 않은 것 같아요.
Icon 컴포넌트의 icon 프로퍼티에 따라 정해진 컴포넌트를 표시해주는 방식인데, 편의성이 좋지 않은 것 같아서 몇가지 제안을 드려요.
  1. Icon 컴포넌트를 통해서 사용하는 방법 대신, 직접 개별 아이콘 컴포넌트를 가져다 사용하는 것이 좋을 것 같습니다. 대신 아이콘 컴포넌트들의 이름에 Prefix를 지정해주면 더 좋을 것 같아요. 예를 들면 IconHyperLink 처럼 말이죠.
  1. 현재 구조를 유지한다면, propTypes 를 통해서 icon 프로퍼티에 대한 유효성을 런타임에서 체크해주세요.
    1. iconList 객체를 컴포넌트 바깥으로 빼내면 Object.keys 로 더 쉽게 관리할 수 있겠네요.
 
결정적으로 현재 아이콘 컴포넌트의 구현은 트리 쉐이킹에 적합하지 않습니다. 트리 쉐이킹에 대해서는 아래 문서를 참고해주세요:
Tree Shaking | 웹팩
Tree shaking은 사용되지 않는 코드를 제거하기 위해 JavaScript 컨텍스트에서 일반적으로 사용되는 용어입니다. ES2015 모듈 구문은 정적 구조에 의존합니다. 예를 들면, 와 가 있습니다. 이름과 개념은 ES2015 모듈 번들러의 rollup 에 의해 대중화되었습니다. webpack 2 릴리스에서는 ES2015 모듈(별칭 harmony 모듈)과 사용하지 않는 모듈의 export를 감지하는 기능을 제공합니다.
Tree Shaking | 웹팩
https://webpack.kr/guides/tree-shaking/
Tree Shaking | 웹팩
 
REACT_APP_API_BASEURL=
Icon.propTypes = { className: PropTypes.string, icon: PropTypes.oneOf(['bars', 'bell', 'calendar', /* ... */]).isRequired, };