[Project Retrospect]230303~230312 1주차
230303 금요일
프로젝트의 첫 시간이었다.
10시부터 11시까지 ZEP에서 팀 편성이 이루어졌고 무엇을 해야할지 결정하지 못한채로 “기타” 카테고리에서 팀원들을 만났다. 우리 팀은 그렇게 만들어졌고 이후 팀 편성을 하지 못한 백엔드 한분이 추가되어 프론트엔드 3명 백엔드 4명으로 시작하게 되었다.
팀빌딩은 1시부터 시작되었다 한분께서 디스코드 서버를 만들었고 초대해주었다.
프로젝트 아이디어 미믹
기타를 선택한 우리는 광범위한 카테고리 안에서 무엇을 만들지에 대한 얘기를 나누었고 각자 만들어보고 싶었던 기능을 중점으로 얘기하다보니 최종적으로
1. 크몽, 콜리, 크레페 (소규모 커미션)
2. 스케쥴러 + 운동 + 식단 (루틴관리)
3. 독서 커뮤니티 + 루틴 (후기, 공유)
4. 공간대여 (MBTI 별로 추천 기능)
5. 환경 에너지
6. 여행 커뮤니티
위 6개의 후보가 만들어졌고 이후 아이디어 미믹을 진행했으며
우리 수준에서 진행 가능한 두 개의 후보로 간추렸다.
**크몽, 콜리, 크레페 ( 소규모 커미션 )** : 포토샵, 그림그리기 등등 재능기부 형식으로 변경 가능
1. 태그 방식 : 그림, 동영상, 개발 등등 → 넓은 분야 활용 가능
1. 어렵지 않을것 같음
2. 어떤 태그를 정해야할지 구체적으로 정해야함
3. 만들어진 태그만 사용할지/ 사용자가 태그 추가 가능할 지
2. 작가의 포트폴리오 (작업물) 공개 공간 → 이미지 업로드 기능
1. 토대 찾기는 쉬울 것 같음 (경험이 없어서 도전해야함)
3. 신뢰도 시스템 → 안해봐서 힘들겁니다
1. 추천 알고리즘(시간남을때) → 태그 별로 분류로 추천을 해줌(안되면)
4. 결제 시스템→ 안해봐서 힘들겁니다
1. 시큐리티 부터 복잡해짐 ㅇㅁㅇ → 재능기부 형식으로 변경 가능
2. 샌드박스 API
5. 문의 시스템 (Q&A)
6. 찜하기
7. 채팅 기능→ 안해봐서 힘들겁니다
8. 로그인,회원가입 등등 회원관련 기능 → 작가/사용자
9. 검색기능 → 안해봐서 힘들겁니다
10. 작가 커미션 판매글 작성
11. 후기 작성
12. 섬네일
**공간대여 ( MBTI 별로 추천 기능 )**
1. 시간별로 대여하는 느낌 → 1 ~ 2시간 짧은 시간도 대여 가능할 수 있게, 시간에 구애받지 않는 자유로움!
1. 예약시스템 : 전체적으로 빡셀듯? 찾아봐야할게 많을 것 같음
2. 공부 및 노력이 좀 많이 들어갈것 같습니다.
2. 추천 카테고리 : mbti, 취미 등등
1. 추천 알고리즘 (시간남을때) → 태그 별로 분류로 추천을 해줌(안되면)
3. 지도 : 공간의 위치를 나타내줌
1. 지도 API 연동 문제 (카카오)
4. 리뷰, 좋아요
1. CRUD
5. 컨텐츠속 장소 : 여기서 촬영이 있거나 기타 등등 홍보용
1. CRUD
6. 결제 시스템
1. 시큐리티 부터 복잡해짐 ㅇㅁㅇ → 안되면 무통장 입금
2. 보안 문제가 있을듯
3. [https://github.com/iamport/iamport-manual](https://github.com/iamport/iamport-manual)
7. 이미지 업로드
1. 토대 찾기는 쉬울 것 같음 (경험이 없어서 도전해야함)
8. 문의 시스템
9. 찜하기
10. 채팅
11. 로그인
⇒ 태그, 추천 알고리즘, 지도, 좋아요 기능, 예약 시스템, 결제 시스템, DB 이용, 이미지 업로드
⇒ 반응형
팀빌딩
백엔드에서 한분이 팀장 내가 부팀장을 맡았다. 프리 프로젝트를 통해서 소통의 중요성을 깨닳았고 최대한 소통을 하기 위해서 노력했다.
나는 어떤 집단에 소속될 때 내가 하나의 역할을 맡았다고 생각을 하면 더욱 몰입 가능하거나 스스로 편하게 느끼는 경향이 있다. 평소 낯선 사람들 앞에서 말을 잘 못하는 나도 그러한 롤을 정하면 말을 그나마 잘하고는 하는데 프리 프로젝트 때와 같은 실수를 반복하지 않기 위해서 그러한 마음가짐으로 대화에 임했고 나보다 말이 없던 두 프론트분들을 뒤로하고 내가 팀장이 되고야 말았다.
다른 분이 팀장을 맡았으면 더 괜찮은 결과물이 나왔을까? 아니면 내가 팀장이기에 이 정도라도 나올 수 있었을까?
아무튼 그렇게 프론트 팀장이 되었고 팀규칙 또한 정했다.
코어타임 9 ~ 13시 회의시간 12시 반
우리는 거의 출석을 위해 코어타임을 9시부터로 결정했다고 볼 수 있다. 시도는 좋았지만 야행성이 많았던 우리팀은 시간이 지날 수록 코어타임의 의미가 없어졌다.
브랜치 전략
우리는 브랜치 전략에 대해 더 깊이 생각했어야 한다. https://techblog.woowahan.com/2553/ 이러한 Git-flow를 참고했어야 하며 깃을 깔끔하게 관리하기 위해 방법을 고안했어야 한다. 대충 의미없는 feat/fe01 이라는 브랜치명은 옳지 못했고 추가될 기능마다 feature branch로 분기를 했어야했다.
git flow에 대한 공부를 지금이라도 제대로 해야겠다.
우리 팀은 우리가 만들 웹의 후보를 두 개로 좁혔고 주말 동안의 투표로 결정하기로 했다.
230306 월요일
주말동안의 투표로 커미션 페이지를 만드는 것으로 결정되었다.
사용자 요구사항 정의서
9시 30분 회의가 시작되었고 요구사항 정의서를 작성하기 시작했다. https://docs.google.com/spreadsheets/d/1j4PivhOMiK9ZddxZHwpwkS4NgBRTBY0UFALzvX0Ieck/edit#gid=0
우리의 회의는 늘 길지 않았다. 그 길지 않은 회의 하지만 길었어야 회의의 시작은 요구사항정의서부터 였을 것이다. 우리는 인터페이스와 기능을 구분했다. 당시에도 이걸 왜 이렇게 구분하는가에 대한 의문이 있었고 지금도 이해가 안된다. 결국 기능은 인터페이스로 표현이 되어야하기 때문에 나눌 필요가 있었을까 싶었다. 또한 화면이라는 카테고리로 나누었다는 점도 있다. 우리는 이 문제에 대해 더 따져봐야했고 프리 때와 마찬가지로 기능과 부기능으로 나누는 것이 어땠을까 싶다.
나는 좀 더 의견을 내세웠어야하고 의구심이 있다면 질문을 했어야 했다.
더불어 어떠한 기능을 어떠한 화면에 넣을지 확실하게 정했어야 했다고 생각한다. 마치 지금 정하는 것이 마지막인 것처럼 따지고 따져서 확실하게 컨셉과 기능을 잡고 다음 회의를 했어야 했다.
회원 정보를 조회할 때 작가의 마이페이지, 일반 회원의 마이페이지, 서로가 서로의 마이페이지를 다르게 설정했어야 하는데 이 부분을 나중에 깨달았고 게시물 페이지에도 어떠한 내용을 어떻게 게시할 것인지 자세히 설명되어 있어야한다고 생각한다.
멘토님의 조언
우리는 거의 기본적인 CRUD를 페이지를 만드는 것과 다름이 없었다. 하지만 어느 페이지와 비슷한 수준으로 만들기 위해 다양한 기능들(북마크, 알림, 정렬, 태그) 등을 추가하다 보니 멘토님께서는 기능이 양이 너무 많다고 하셨다. 그래서 우리는 부기능들의 중요도를 낮췄고 주요한 CRUD에 집중하기로 했다.
멘토님이 해주신 피드백은
- 기능이 너무 많으니 포기할 것에 대한 순서를 정해라
- 이력서에 자신이 맡은 부분에 대한 세세한 설명을 할 수 있도록 신경써서 해라
정도로 추릴 수 있는데 우리는 적당히 포기할 건 포기했지만 과연 내가 이력서에 설명할 수 있을 정도로 신경써서 구현한 부분이 있는가에 대한 것은 더욱 생각해 봐야겠다.
결국 구현하지 못했지만 채팅에 필요한 정보도 던저주셨다.
https://github.com/callicoder/spring-boot-websocket-chat-demo/tree/master
https://socket.io/docs/v4/client-socket-instance/
채팅 구현 너무하고 싶다..
유저플로우
https://www.figma.com/file/1aFrodHI4D1K01h97rozJa/Main_25-userFlow?node-id=0-1&t=ehL2I0YKCzmQVcNG-0
주말을 이용해서 유저플로우를 만들었다.
깃허브
이슈, 칸반보드, 마일스톤에 대한 이야기를 처음부터 나눴어야 한다. 우리의 git flow가 옳지 못한 방향으로 나아간 것과 같이 깃허브 또한 제대로 관리하지 못했다. 나는 이것에 빠른 의문을 가졌어야하고 다른 프로젝트에서는 어떻게 관리하고 있는지에 대한 것을 미리 봐뒀어야 한다.
230307 화요일
화면정의서
우리는 아토믹 디자인과 기업들의 디자인 시스템을 충분히 참고하고 화면정의서를 만들었어야 했다. 처음부터 웹을 만든다는 것은 웹디자인도 해야 한다는 것이었고 그걸 생각하지 못했기에 거의 2주 동안 CSS에만 몰두해버렸다.
아무튼 이때는 그 사실을 모르고 화면정의서를 만들었고 일주일 후에 이를 크게 후회하게 되었다. 그리고 화면정의서도 마찬가지로 길지 않은 회의였다
개발환경
우리는 이 시점에서 어떻게 배포를 할 것인지 상의를 했어야 했고 미리 공부를 했어야 했다. 또한 어떠한 기술 스택을 사용할 것인지 확실히 했어야했으며 특히 이후 상태관리 부분에서 오류가 많이 생겼다.
부팀장으로서, 프론트의 팀장으로서 어느 시점에 어떠한 것을 결정해야하는지 어떠한 방식을 통해서 결정을 해야하는지 알지 못했다. 우리는 개발에 들어가기에 앞서 개발환경에 대해 충분한 대화를 나누었어야 하고 나는 그 대화를 이끌 정도로 사용할 기술과 우리 팀원에 대한 이해를 하려고 노력했어야 했다.
업무분담
나는 마이페이지와 커미션 등록 페이지, 헤더 등을 담당했찌만 이후 커미션 등록을 넘기고 리뷰 작성을 담당하게 되었다.
기본세팅
CRA로 기본세팅을 시작했다. prettier, eslint 를 이해하지 못한채로 그냥 프리 때 사용하던 것을 그대로 가져왔고 제대로 적용되었는지 확안도 안했다. 그리고 제대로된 사용법도 아니었다. 나는 좀 더 공부를 하고 사용했어야 했다.
또한 커밋컨벤션과 코드컨벤션에 대해서 충분한 대화를 나누었어야 했다. 커밋컨벤션 또한 프리 때 사용하던 것을 가져왔다. 하지만 잘 지켜지지 않았다. 이에 대해 나는 목소리를 냈어야했다. 코드컨벤션 때문에 무언가 문제가 생긴 것은 아니지만 prettier, eslint의 세팅을 위해 조금 더 대화를 나누었어야 했다고 생각한다.
기본 세팅도 하루 날을 잡고 하는 수준으로 했어야 했다. 서로 코드를 침범하지 않도록 index.js와 App.jsx의 구조를 미리 전부 해놨어야 했다. 그러기 위해선 사전에 충분한 회의가 동반되었어야 했다.
230308 수요일
본격적으로 코드를 작성하기 시작했다.
버튼 컴포넌트
프리 때 재사용할 수 있는 컴포넌트를 못 만들었다는 생각이 들어서 버튼 컴포넌트를 만들게 되었고 세 가지 다른 종류의 버튼을 만들었다. 지금 생각해보면 지금의 방식과 이 방식 두 가지를 적절히 섞어 놨어야 했다.
컨테이너 컴포넌트
import styled from "styled-components";
export const Container = styled.div`
display: flex;
width: 1280px;
height: fit-content;
`;
이후 스크롤을 없애기 위해
overflow-x: hidden;
추가
모든 페이지에서 공통으로 사용될 컨테이너 컴포넌트를 만들었는데 굳이 컴포넌트로 뺐어야하나 생각이 든다. index.css 와 각 페이지 사이에 이 컨테이너 컴포넌트가 끼어 있는 형태인데 각 페이지에 같은 값을 주는 것이 맞나 생각이 든다. 혹은 index.css 만으로 충분히 설정할 수 있지 않을까라는 생각이 든다.
ThemeProvider
공통으로 스타일 관리를 하기 위해서 도입했으나 결국 제대로 사용하지는 못했다. 무언가 참고를 했었다면 좋았을 텐데 그냥 무작정 코드를 짜기만 하니까 더욱 비효율적인 상태가 되었다. 확실히 리팩토링이 필요한 부분이다. 하지만 도입한 것은 좋은 시도였다.
const theme = {
windowSize: {
small: "screen and (max-width: '680px')",
base: "screen and (max-width: '980px')",
large: "screen and (max-width: '1280px')",
},
themeColor: { milkTea: "#ddba9d" },
};
export default theme;
호기롭게 반응형을 할테야 라는 생각으로 이러한 것부터 작성해봤지만..
이후
themeColor: {
milkTea: '#ddba9d',
milkTeaTwo: '#c29567',
lighterGray: '#fcfafa',
lightGray: '#c1c1c1',
darkGray: '#313131',
},
추가
const S_Container = styled.section`
${({ theme }) => {
const lighterGray = theme.themeColor.lighterGray;
return css`
display: grid;
width: 100%;
border: 1px solid ${lighterGray};
`;
}}
`;
이러한 방식으로 어느 때에나 theme을 불러 사용하고 싶었다. 통일성은 생길지 몰라도 코드가 길어지고 스타일 컴포넌트트에서는 특히 길어질 수밖에 없다고 생각이 들었다. 아마 제대로 사용하는 방법을 모르기 때문이라고 생각이 드는데 theme을 제대로 사용하기 위해서 문서를 찾아봐야겠다.
react-icon
아이콘은 리액트 아이콘으로 통일하기로 했다.
favicon
favicon을 노션의 버블티 아이콘은 포토샵을 통해서 svg로 변환시켜서 public에 저장, 그리고 index.html에 적용했다. 결국 나중에는 png로 바꿨지만..
Carousel
어느 홈페이지에 있던 Carousel 기능을 추가하기로 했다.
import { Component } from "react";
import styled from "styled-components";
import Slider from "react-slick";
import "slick-carousel/slick/slick.css";
import "slick-carousel/slick/slick-theme.css";
const S_container = styled.div`
width: 800px;
height: 350px;
overflow: hidden;
align-items: center;
`;
const StyledSlider = styled(Slider)`
.slick-slide {
outline: none;
}
.slick-next {
right: 0px;
z-index: 10;
}
.slick-prev {
left: 0px;
z-index: 10;
}
`;
const ImageContainer = styled.div``;
const Image = styled.img`
display: flex;
width: 700px;
height: 300px;
`;
const imgUrl = require("../assets/shoes1.jpg");
const items = [
{ id: 1, url: imgUrl },
{ id: 2, url: imgUrl },
];
export default class SimpleSlider extends Component {
render() {
const settings = {
dots: true, // 캐러셀이미지가 몇번째인지 알려주는 점을 보여줄지 정한다.
infinite: true, // loop를 만들지(마지막 이미지-처음 이미지-중간 이미지들-마지막 이미지)
speed: 500, // 애미메이션의 속도, 단위는 milliseconds
slidesToShow: 1, // 한번에 몇개의 슬라이드를 보여줄 지
slidesToScroll: 1, // 한번 스크롤시 몇장의 슬라이드를 넘길지
arrows: true,
centerMode: true,
pauseOnHover: true,
};
return (
<S_container>
<h2>Single Item</h2>
<StyledSlider {...settings}>
{items.map((item) => {
return (
<div key={item.id}>
<ImageContainer>
<Image src={item.url} />
</ImageContainer>
</div>
);
})}
</StyledSlider>
</S_container>
);
}
}
일단 작성되어 있던 코드를 그냥 가져왔기 때문에 class-extends, require 같은 es6의 문법으로 작성했고 이를 함수형 컴포넌트로 바꿔야하는데 뒤로 미루었다.
나는 react-slick을 사용해야겠다고 생각했을 때 무작정 코드를 복사해오는 것이 아니라 공식문서를 봤어야 했다. 나중에 공식문서를 보고 더욱 다양한 활용 방법을 알았고 오랫동안 고민했던 부분의 해답을 쉽게 얻기도 했다.
230310 금요일
멘토링이 끝나고 우리는 우리의 부족함을 크게 깨닳았다.
- git flow 버전관리가 되고 있지 않다. - 다른 git flow 예시를 참고하여 하나를 따라서 해봤어야 했다.
- prettier, eslint 를 합쳐라 - 프리티어와 에슬린트를 어떻게 사용하는지 확실히 공부를 했어야 했다.
- 안쓰는 라이브러리 삭제 - 라이브러리를 좀더 신중하게 회의를 통해서 결정하고 인스톨했어야 했다.
- 더미 데이터 서버를 만들어라 - 서로의 페이지에 어떠한 정보들이 넘어와야 하는지 더미 데이터를 만드는 과정에서 파악하고 결정했어야 했다. 이 과정을 통해서 후에 API명세서의 문제점을 빠르게 발견하고 요청할 수 있을 것이다.
- 케러셀을 함수 컴포넌트로 바꿔라
- react portal을 사용해라
- 아토믹 디자인 시스템을 참고해라
- 배포와 로그인방식을 상의해라
- 스펙을 확정해라
https://fe-developers.kakaoent.com/2022/220505-how-page-part-use-atomic-design-system/
에서 아토믹 디자인의 힌트를 얻을 수 있었고 바로 도입하기로 했다.
또한 친구의 도움으로 8px 그리드 시스템을 알게 되었고 도입하기로 했다. 하지만 나는 8px 그리드 시스템에 대해 더 공부가 필요했다. 지금 생각해보니 그냥 뭐든 8의 배수로만 설정을 하면되겠지 하고 시작한 듯하다.
우리 팀은 본격적인 코드 작성에 앞서 이러한 것들을 상의했어야 했다. 하지만 이러한 것들이 필요한지 조차 모르고 있었으니 얼마아 안일한 생각으로 프로젝트를 시작했는지 알 수 있다. 프론트 팀장으로서 나는 이러한 정보들을 어디서 얻고 시작을 했어야했을까? 적어도 구글이나 유튜브에 검색이라도 해봤어야 했다..
230311~230312 토,일요일
피그마를 다시 만들었다. 하지만 이 역시 지금 보면 한참 부족하다. 이 때는 아토믹 디자인에 꽂혀서 이미지, 타이틀 컨텐츠 등이 함께 들어있는 박스를 하나의 컴포넌트로 만들으려고 했다. 하지만 이것은 정말 안일한 생각이었다.
그리드를 도입했다.
또한 이틀동안 혼자서 만든 피그마이기 때문에 상당히 부족했다. 우리는 모여서 함께 공통으로 사용할 컴포넌트를 정했어야 했다.
일 주차 한줄 평
안일한 시작, 부족한 회의, 근거없는 자신감
댓글남기기