[JUSTCODE] FAST-FIVE 기업과제 프로젝트 회고록

프로젝트 기간

2022.12.12 ~2022.12.27

사이트의 성격

패스트파이브에 입주해있는 회사들의 정보를 확인할 수 있으며, 권한에 따라 회사소개 글을 작성할 수 있다.

팀원소개

Front-end
한혜선, 박성아, 오다원

Back-end
김지수, 송인찬

기술 stack

Front-end : React, Sass, TypeScript
Back-end : Node Express, Mysql, AWS, TypeScript

컨벤션

패스트파이브 기업과제 사이트 url

http://13.231.5.51:3000/

협업방식

Notion에서 칸반보드를 이용하여 티켓으로 일정 관리
Daily stand up meeting(AM 11:30) : 어제 작업한 사항, 오늘 해야할 사항 공유
Slack : 공지사항 전달
vscode liveshare : 실시간 코드 공유 및 피드백
git/github, zoom, google meet : 실시간 코드 리뷰, 함께 에러 해결

내가 담당한 부분

게시물 수정/등록 페이지

• 업종 이중 카테고리 : 카테고리를 클릭할 시 하위 상세카테고리가 존재할 때만 상세 카테고리가 생성됨.
• 회사이름 가져오기 : default value로 cms상 회사이름을 불러옴(수정가능)
• 글자수 세기 : 글자를 입력할 때마다 글자수가 카운트되고, 100자 혹은 1000자 조건에 따라 해당 제한 글자수에 도달하면, 영역이 빨간색으로 변경되며, 더이상 입력되지 않음.
• 필수 항목 : 필수 항목을 입력하지 않았을 때 밑에 alert이 뜸.
• 주력 업무분야 5개 제한 : 주력 업무 분야에 5개 이상 입력하면 밑에 alert창이 뜸.
• 파일 : 내 컴퓨터 내의 파일을 업로드 할 수 있음.
• 필수항목 미입력 체크 : 필수항목을 1글자 이상입력했거나, 체크 박스 동의를 완료하는 등의 조건에 따라 등록 fetch가 작동.
• 버튼 조건부 렌더링 : 게시물 상세 페이지 내 수정 버튼 누르고 들어오면 수정하기 버튼 노출, 회사소개하기 버튼 누르고 들어오면 등록하기 버튼 노출

header/footer/side bar 레이아웃

게시물 수정/등록 페이지

onChange={e => setCompanyLogo(e.target.value)}

---

필수값 체크를 보다 간단하게!
처음에는 필수값 체크를 위해 boolean형의 useState를 만들고, 필수값을 체크하는 함수를 만들었는데, 이 방식으로 하니 통신할 때 받아온 값을 세팅하기위한 fetched 세터 함수를 또 만들어야했고, 결국엔 useState가 너무 많아져서 코드가 불필요하게 길어지고, 복잡해졌다.
이것을 어떻게 해결할까 생각하다가 e.target.value를 함수에서 체크하지 말고, 바로 onChange에 걸어버리면 어떨까?하는 생각이 들었고, 실제로 위 코드와 같이 작성해보니 fetched 세터 함수를 또 만들어줄 필요없이 굉장히 코드가 줄어들었다.

formData 넌 대체..
이번 프로젝트에서 정말 아쉬웠던 점은 바로 formData를 해결하지 못해서 통신을 하지 못했다는 사실이다.
파일(jpg)이 존재하기 때문에 이것을 백에 보내줄 때 formData형식을 사용해야했다. 처음 사용해보는거라 어떻게 써야하는지 몰랐기에 구글링을 계속 하면서 진행했는데 백에 자꾸 '//c://fakepath//파일이름.jpg' 이러한 형식으로 보내지는 것이다. 담당 백엔드 분이 파일이름만 오게 수정해달라고 하셔서 나는 하루, 이틀동안 계속 수정해보려 애썼지만, 결국 고치지 못했다. 그렇게하여 통신이 안된, 미완성으로 프로젝트를 제출하게 된 것이다.
나중에 질문을 커뮤니티에 올려보니, 저 형식은 백에서 지정하는거라 프론트와는 아무 상관이 없다고 했다. 해답을 알게된게 너무 늦어서 아쉽지만, 그래도 무언가 실마리를 찾았다는 것이 좋았다.
프론트와 백 모두 아직 많이 부족하기에 발생한 문제였다. 앞으로 성장하여 나는 이와같은 문제는 발생시키지 않으리라.

---

기업과제는 어려워

기획서를 보고 구현해보는 것의 의미

지금까지 저스트코드에서 진행한 프로젝트들은 모델링할 사이트를 보고 디자인을 차용하여, 어떻게 기능을 구현할지 생각하는 방식이었는데, 이번에는 기획서가 우리에게 날아왔다. 기획서에는 기능구현에 대한 설명이 상세하게 되어있었기에 이를 통해 어떻게 기능을 구현할지 고민을 많이 해봤던 것 같다. 하지만, 디자인에 대한 상세한 설명은 부족했기에 우리가 자체적으로 생각을 해야했고, 색을 정하는 것부터 시간을 조금 더 많이 할애해야했다.
기획서를 팀원들과 분석하면서 설명에 대한 각자의 해석이 다를 수 있음을 알게되었고, 기획서가 조금 더 상세해야하는 이유에 대해서도 알게되었다.
짧은 경험이었지만 이를 통해 기획서를 보고 개발로 풀어나가는 법을 배웠고, 실무 개발자에 한걸음 더 가까워질 수 있었던 것 같다.

타입스크립트를 적용해본 소감

타입스크립트 세션을 들었을 때 나는, '뭐야 그냥 뒤에 :하고 타입만 붙이면되네?' 라는 안일한 생각을 했다. 프로젝트가 시작하고 나서야 잘못된 생각이라는 것을 알게되었다. 타입을 주는 방법이 ':타입'으로만 해결되는 것이 아니었고, 자바스크립트로 할 때는 에러가 나지 않았던 것들에서 에러가 발생하니, 작업속도도 더뎌지고 힘들었다.
하지만, 지금 이런 에러들이 자바스크립트에서는 나지 않으니 나중에 어디서 어떤 에러가 나서 해결하기 어렵게 될지가 예상이 갔다. 그래서 미리 에러를 방지해주는 타입스크립트가 아직은 불편하지만 매우 필요한 것이라는 것을 깨달았다.
아직은 많이 부족하지만 앞으로 타입스크립트에 대해 더 많이 공부해서 능숙하게 쓸 수 있는 날까지 나, 화이팅이다.