[Project Retrospect]230327~230402 4주차
230327 월요일
겨우 배포를 끝내고 느낀 것은 아.. 수정할 때마다 배포를 다시 해야겠구나.. 그리고 CI/CD를 이래서 하는 구나.. 싶었다. 한번 도전해 봐야겠다.
솔직히 왜 이렇게 API 연결에 오래 걸렸나 싶다.. 공부를 안했던 탓일까? 그냥 게을렀던 탓일까? 막상 크게 달라진 코드는 없지만 오래 걸렸다.
naming
네이밍에 대한 고민은 계속하지만 컴포넌트라면 파스칼 케이스인 것이 맞고 컴포넌트가 들어있는 폴더명도 파스칼 케이스로 변경했다.
파일명을 수정했음에도 반영이 되지 않는 경우
https://kangdanne.tistory.com/148
를 참고했다.
이날 새벽 내가 다른 팀원의 코드까지 네이밍을 건드리는 바람에 상당한 오류가 생기고 말았다.
특히 마이페이지 폴더는 mypage와 Mypage 두 개가 존재하게 되었다. 어떻게 해결을 했는지 기억은 안나는데 아마 github에는 mypage로 올라가 있고 Mypage로 다시 머지가 되는 바람에 꼬인 것 같았다. 무언가 수정을 하면 존재하지 않아야할 mypage에 있는 컴포넌트도 같이 수정이 되었고 같이 status에 올라갔다.
또한 에슬린트 설정이 다른 분들과 다르게 적용되고 있는 것 같았다.
jsconfig.json
{
"compilerOptions": {
"baseUrl": "src"
},
"include": ["src"]
}
로 기본 경로를 src로 설정하고
.eslintrc.json
"settings": {
"import/resolver": {
"node": {
"paths": ["src"],
"extensions": [".js", ".jsx"]
}
}
}
로 import할 때 기본 파일 속성을 설정한다
로 알고 있는데 잘못된 건지.. 왜 다들 ../../을 사용하고 뒤에 .jsx를 붙이는 건지 이해가 되지 않았다. 공부가 부족하다 그냥 복붙만 하는 건 혼자할 때나 하는 방법이라는 것이었다. 프리티어와 에슬린트에 대한 공부가 더욱 필요하다.
230328 화요일
get
마이페이지에는 4개의 모듈이 있다.
- 커미션 신청
- 프로필
- 커미션
- 채팅
그 중 커미션 신청의 경우(작가 기준)에는 일반 유저가 작가에게 커미션을 신청하면 해당 커미션의 정보, 신청폼의 정보, 신청 유저의 정보 까지 세 가지의 다른 정보들이 필요하다. 그리고 우리의 response data 안 에는 그것들을 전부 담고 있지 않았기 때문에 다 따로 불러주어야만 했다.
커미션의 경우 커미션 목록을 조회하는 reponse data 안에 memberId가 들어가 있지 않았기 때문에 email로 조회를 해야해서 조금 번거로웠고 또한 모든 커미션 목록을 불러와서 email을 비교해서 그에 맞는 커미션 정보들만 불러오는 방식이 맞는가에 대한 생각도 들었다.
import { getCommissionsFn } from "./getCommissionFetch";
export const getMemberCommissionFn = (email) => {
const commissions = getCommissionsFn("commissionId");
if (commissions) {
return commissions.filter((el) => el.memberEmail === email);
}
return;
};
배포
멘토님이 말했던 것처럼
S3 -> cloudfront -> route53 의 방법으로 배포를 시도했다
S3는 정적 배포, cloudfront는 속도향상, route53은 도메인과 https 설정을 담당하기 때문에 이렇게 많이 사용한다고 한다. 배포는 성공했다. 하지만 백엔드에서 https 설정이 안되어 있는 바람에 기껏 샀던 도메인을 사용하지 못했고 다시 S3로만 배포를 하는 것으로 하게 되었다.
이에 대한 회의도 충분히 나누었어야 하지만 필요한지조차 나는 알지 못했다..
230329 수요일
내가 담당한 mypage 조차 끝내지 못하였고 하기로 했던 채팅은 도전도 하지 못했다. 다른 팀원을 도와줄 시간에 내것을 하고 그들에게 스스로 찾아볼 수 있는 기회를 주어야 했다. 나는 내가 코드를 알려주는 것이 가장 빠른 길이라고 착각했고 그렇게 미완성인 채로 마지막날을 맞이하게 되었다.
이후로는 거의 충돌과 오류를 해결하는 데에만 집중하고 배포하고 화면에 나오게 하는 것에 집중했다.
원래의 날짜는 29일까지지만 그래도 계속 리팩토링을 하고 기능을 추가했다.
우리는 각자 맡은 페이지에 어떤한 기능이 필요하고 추가할 것인지 확실하게 정하고 깃헙의 이슈로 만들어 놨어야 한다. 나중에 추가하는 건 의미 없었다. 페이지를 하나의 이슈로 하여 페이지 자체를 구현하고 페이지와 페이지를 연결하는 작업은 나중에 했어도 됐다.
그런 기본 설계가 안되어 있기 때문에 29일이 지난 후에야 안되는 부분을 찾아내기도 하고 다른 팀원이 담당한 부분을 보며 짜증을 내기도 했다. 해야하는 모든 것들을 미리 파악하고 작성해놨으면 이런일이 벌어지지는 않았을 것 같다.
회고 후기
회고를 적으면서 초반에 후회를 다 하는 바람에 용두사미의 형태가 되었다. 또한 일부러 코드에 대한 회고는 많이 하지 않았는데 같은 페이지나 컴포넌트라도 계속 바뀌었기 때문에 코드는 따로 회고를 하는 게 낫다고 판단했다.
전체적으로 후회로 가득한 회고다. 옳게된 부분이 거의 없고 후회로 가득하다. 하지만 이러한 실수를 바탕으로 더욱 나은 개발자로 거듭나고 싶다. 다시는 이러한 실수들을 반복하기 싫다.
코딩을 만만하게 생각했고 사전 계획 설계는 더욱 만만하게 생각했다. 코드를 작성하는 것보다 계획이 더욱 중요하고 규칙이 더욱 중요하다. 이것들이 잘되어야 코딩이 편하고 효율적이게 된다.
댓글남기기