[Project Retrospect]230320~230326 3주차
230320 월요일
이때 쯤 이었을 것이다. 주말 동안 CSS를 리팩토링을 했는데도 끝나지 않았고, 프론트엔드분들의 질문, 백엔드와의 소통 등에도 지치기 시작했다. 내색은 안했지만 현타가 강하게 왔었다. 그리고 조금 잘못 걸렸다… 라는 생각까지 들었다.
나는 프리 프로젝트 때 정말 못하는 편이었다. 특유의 어떻게든 되겠지라는 생각으로 학습을 게을리했고 분명 비전공자는 따라가기 벅차다, 다른 지인들로부터 나는 이렇게 빡세게 공부했다.. 등등 얘기를 들었음에도 불구하고 당장 나에게는 비상이 걸리지 않았다.
하지만 프리 때 같은 학습프로그램을 했음에도 불구하고 다른 팀원들과 나의 격차는 심했다. 나는 대화에 따라가기도 벅찬 상태였다.
메인 프로젝트 때는 솔직히 내가 에이스였다. 그들의 코드를 봐주고 수정해주고 해결해주었다. 처음에는 조금 좋았다. 분명 못하던 나인데 여기서는 잘하는 편이라는 생각이 들었기 때문이다. 근데 현타가 오고나니 버거워졌다. 놓고 싶어졌다. 점점하기 싫어졌다. 부족한 부분을 내가 좀더 하지뭐~ 라는 생각으로 하긴 했지만 나는 그 정도의 실력을 가지고 있지 않았고 그런 부지런함도 없었다.
그래서 월요일에는 거의 아무것도 하지 않았던 것 같다.
230321 화요일
toast UI Editor
우리팀은 Editor로 toast UI Editor를 사용했다. 하지만 문제가 꽤 많이 있었는데 리액트 17까지만 호환이 된다는 점, 강제로 설치는 할 수 있고 사용은 할 수 있지만 터미널에서 오류 메세지가 뜬다는 점이다.
한번 사용해 봤기 때문에 선택을 했지만 나는 어떠한 에디터를 사용하는 것이 좋았을까? toast 말고 어떠한 에디터가 더 있으며 다른 에디터를 사용하면 무엇이 달라지는가? 한번 다른 에디터로 실험해보고 싶다는 생각이 들었다.
또한 멘토님께서는
를 참고하여 현재 발상해는 문제를 해결하라고 하셨는데 끝내 하지 못했다.
다시 한번 읽어보고 적용해봐야겠다.
CSS
전체적인 CSS를 내가 다 건드렸다. 그리드에 대한 개념이 박혀있지 않아서 무작정 그리드를 사용해서 만든 것들을 다시 flex로 바꾸었고 텍스트는 Typography 컴포넌트를 버튼은 Button 컴포넌트를 적용했다.
캐러셀의 현재 image를 state로 하여 백그라운드에 표시될 수 있도록 만들었고 태그 컴포넌트 또한 이 때 만들었다.
통일성을 지키기 위해 나 혼자서 CSS를 뒤집었지만 처음에 규칙을 잘 세웠으면 할 필요 없었던 일이었다. 여전히 theme 사용법은 잘못되어서 Typography나 Button 컴포넌트가 하드코딩한 것과 다름이 없었다.
하지만 반응형은 최대한 지키기 위해 고정된 width 값을 다 빼고 max나 퍼센트로 표시되도록 만들었다. 이 부분은 꽤 만족스러운 리팩토링이었다.
여전히 CSS는 갈아 엎어야할 수준이다.
230322 수요일
memberId
우리가 회원조회를 할 때 사용하기로 한 API URL은 members/{memberId} 였으나 memberId를 알 수 있는 방법이 없었다. 로그인할 때 response로 받아와서 저장한 후에 회원조회를 원할 때 memberId를 사용한다는 방식으로 하려했지만 이 역시 소통이 부족했으며 나는 백엔드에서 어련히 해주겠지라고 생각했고 또한 API명세서를 제대로 보지 않았기 때문에 이 부분이 잘못되어있다는 사실도 이제야 깨달았다.
총체적 난국인 상황이었으며, 이러한 memberId를 저장하고 회원조회 때 사용하자 라는 방식도 잘못되었다. 멘토님께서는 stateless를 지켜야한다고 말씀하셨다.
우리는 회원조회를 어떠한 방식으로 할 것인가 조금 더 회의하고 찾아보는 시간을 가졌어야 한다. 그리고 그때 못한 방식을 찾아보고 적용해보고 싶다.
이 시점이 프로젝트 끝나기 일주일 전인데 해놓은 것은 css까지 그리고 완벽하지 않은.. 이 정도 였다. 초반에 헛짓했던 일주일을 생각보더라도 진전이 너무 느렸다. 원인은 무엇이었을까?
너무 css에만 매달렸다. 처음부터 확실하게 하지 않은 것들이 너무 많았다. 기본 색상, 폰트, 이미지 비율, 버튼 등 우리는 디자인 시스템에 대해 공부를 했어야 했고 그렇지 않다면 차라리 과감하게 css의 통일성은 버리고 각자 페이지를 독립적으로 만들었어야 했다. 본래의 협업과 거리가 멀어지지만 만약 그렇게 했다면 우리는 더 많은 기능을 구현할 시간은 있었을 것이다. 그리고 css는 나중에 리팩토링을 하면 된다.
230323 목요일
Axios
이때 쯤부터 제대로 API 연결을 하기 시작했다. 사실상 데이터를 가져오는 것은 어렵지 않은데 사이드이펙트처리, 비동기에 대한 개념이 부족했고 그 부분에서 애를 많이 먹었다.
우리는 결국 상태관리와 사이드이펙트 모두 React로 처리하기로 했다. 처음에는 Redux, 나중에는 Recoil을 고려했지만 다른 무언가를 첨가하기보다 지금 그나마 할줄 아는 것에 집중해야 했기 때문이다.
Link
Link로 화면전환을 하던 코드를 전부 useNavigate로 변환하였다. 이 둘의 가장 큰 차이점은 useNavigate는 함수이기 때문에 조건에 따라서 다른 페이지로 이동이 가능하다는 점이다.
따라서 모든 Link 컴포넌트를 useNavigate로 바꾸는 것은 그렇게 효율적인 선택은 아니었다.
Folder
이때 쯤 폴더 이름을 조금씩 바꾸기 시작했다. 주로 첫 글자를 대문자로 바꾸기 위해서였는데 그냥 rename으로 바꾸었고 또 깃이 엉망이 되는 시발점이었다.
나는 git에 대한 충분한 공부가 필요했다. 적어도 git은 어떻게 파일을 구분하며 폴더 이름이 변경된다면 git에서는 이를 어떻게 아는가? 에 대한 것은 봤어야 했다.
컴퓨터는 애다. 하나부터 열까지 다 알려줘야한다. 나는 당연하게도 알거라고 생각하고 git을 사용해왔다. 멘토님에게 듣기로는 git mv를 사용해야 renamed를 보다 정확하게 파악한다.
https://kwoncheol.me/posts/git-rename-inference
230324 금요일
API 모듈와
API URL을 이용해서 데이터를 가져오는 커스텀 훅을 만들었다. 이것 또한 훅으로 봐야하는지 잘 모르겠지만.. 일단 특정 커미션에 대한 정보를 GET하는 코드는
import { instance } from "apis/utils";
export const getCommission = async (id) => {
try {
const res = await instance.get(`/commission/${id}`);
console.log(res.data);
return res.data.data;
} catch (err) {
console.log(err);
}
};
이러하다
커미션이 표시되어야 하는 페이지의 코드는
function Post() {
const [commission, setCommission] = useState(null);
const params = useParams();
useEffect(() => {
const fetch = async () => {
const data = await getCommission(params.id);
setCommission(data);
};
fetch();
}, [setCommission]);
이러했다.
각 페이지 혹은 불러오는 api마다 useEffect를 사용해서 비동기로 불러오는 형태이다.
지금보니 상당히 충격적이긴하다. 당시에는 자각을 잘 못하고 있었는데 진행이 너무나도 느리다. 이에 대한 계획도 세웠어야 했다. 해야할 일을 나누고 일정을 정해서 일정 안에 계획을 완수하는 느낌으로 프로젝트를 진행했어야 했다.
230325~230326 토, 일요일
24일에서 25일로 넘어갈 때 카페에서 밤을 세우고 있었다. 평소에도 계속 그래왔지만 다른 분들과 함께였고 이 때까지도 프론트엔드 다른 팀원 한분의 코드를 같이 봐주면서 하고 있었다.
다른 한분은 회원가입과 로그인으로 꽤 오랜시간 시간을 잡아먹었고 솔직히 이러한 상황이 상당히 버거웠다.
customHook
이때부터 커스텀훅을 사용하기 시작했다. api 모듈화, 커스텀훅 사용으로 페이지나 모듈의 코드는 짧아졌고 폴더가 구분되어서 보기 좋아졌다. 그리고 다른 팀원에게 이를 알렸고 같이 사용해주길 바랬다.
나는 이 또한 코드를 작성하기 전부터 필요성을 느꼈어야 했고 팀원들과 소통을 하고 결정했어야 했다. 프로젝트가 끝나기 직전에 도입을 하는 것은 문제가 있다.
mui
mui의 도움을 조금 받기로 했다. mui에 있는 alert을 활용하기로 한 것이다. 프로젝트 초반에 mui를 봤었을 때보다 mui와 코딩에 조금 더 알게된 후에 보니 mui가 어떤 역할을 하고 어떤 도움을 주는 지 더욱 명확하게 알 수 있었고 mui를 활용해서 리팩토링해보고 싶단 생각이 들었다.
imgInstance
저번 프리 때는 안해봤지만 이번에 해보는 것 중에 가장 이질적인 것 중에 하나가 바로 이미지를 업로드하는 것이었다.
이미지 업로드를 위한 Axios instance를 하나 더 만들었고 그것이 바로 imgInstance다.
export const imgInstance = axios.create({
baseURL: "http://~~",
headers: {
"Content-Type": "multipart/form-data; boundary=[{boundary_term}]",
},
withCredentials: true,
});
기존과 가장 다른점이라하면 헤더에 있는 Content-Type인데 여태까지 application/json 만 사용해왔기 때문에 Content-Type에 대해 잘 알지 못했는데 물론 지금도 잘 모르긴하지만 이걸 계기로 한번 공부해야겠다는 생각이 들었다.
아무튼 이미지를 업로드할 때는 multipart/form-data를 사용하며 boundary의 역할은 멀티파트가 있을 시에 데이터의 영역을 구분하는 것인데 우리는 이미지만을 서버로 전달하고 있으니 구분은 딱히 필요하지 않았다.
그리고 구분할 필요가 없을 때는 저렇게 사용하는 것이 맞나? 에 대한 것도 찾아봐야겠다.
https://stackoverflow.com/questions/3508338/what-is-the-boundary-in-multipart-form-data
컴포넌트 이름
react를 할 때 또는 함수를 만들 때 고민되는 부분 중에 하나가 네이밍이다. 정해진 네이밍 방식은 없지만 다른 기업에서 사용하는 방식이나 유명한 방식은 분명 존재할 것이다. 우리는 이 역시 고려하지 않았고 네이밍이 방식이 재각각이었다.
나는 이러한 것들이 마음에 들지 않았으나 돌이키기에는 너무 늦어버린 시점이었기 때문에 기초적인 부분만 다듬기로 했다.
sourcemap 제거
CRA에서 빌드시 sourcemap이 생긴다. 하지만 배포할 때는 빼줘야 한다. 그렇기 때문에
"build": "set \"GENERATE_SOURCEMAP=false\" && react-scripts build",
빌드 코드를 고쳐서 빌드했다.
그냥 안돼서 찾은 방법이고 자세히 알려고 하지는 않았다. 회고 후에 공부가 필요한 부분이다.
배포 S3
S3로 배포를 했다.
유어클레스에 있는 내용 그대로 했으며 배포하는 과정에서 어려움은 없었으나, 배포를 하고 난 뒤에 발생되는 이슈가 너무 많았다. 로컬에서 실행시킬 때와 다른 순서로 서버에 접근한다는 느낌이 들었다.
삼 주차 한줄 평
나는 내가 할 일에 더욱 집중했어야 했다.
댓글남기기