export const __getSpots = createAsyncThunk(
"getSpots",
async (payload, thunkAPI) => {
try {
const querySnapshop = await getDocs(collection(db, "spot"));
const spotsData = querySnapshop.docs.map((doc) => ({
id: doc.id,
...doc.data(),
}));
return spotsData;
} catch (error) {
console.log("error :", error);
return thunkAPI.rejectWithValue(error);
}
}
);
코드의 재활용성을 극대화 하였다. 여러 컴포넌트에서 파이어베이스를 읽어와서 화면에 뿌려주는 부분, 전역적으로 사용하는 코드는 따로 두어서 관리하며 코드의 간결성을 유지 시키는 점이 좋았다.
프로젝트 시간동안 매우 집중도 높은 시간을 가지며 실시간으로 의사소통하는 시간도 많았으므로 어려웠던 점과 문제점을 소통하며 해결했던 점이 팀원들의 강점 이었다.
프로젝트 기간 동안 매일 최소 2번의 소통시간을 정해두었었는데 그 외에도 문제점을 의논하는 시간을 자연스럽게 가져감으로써 프로젝트 기간동안 시간을 많이 절약 할 수 있었다.
현역 퍼블리셔 경험자와의 연계를 바탕으로 요구사항에 맞춰 화면을 구현하는 시간을 가졌으며 요구사항에 맞춰서 구현했으며 원활한 의사소통을 했던 점이 실력적으로 큰 이점으로 다가 온 것 같다.
설계를 할 때 놓치는 부분도 있었다. 필수요구사항,와이어프레임, 사용기술, 개발환경, 디렉터리구조, 코드컨벤션, 깃전략은 가져왔지만 코드구현설계에 대해 정확하게 정하지 못했던 점이 아쉬웠다. 가장 먼저 기능 부분에서 전역상태 관리를 설정을 하여 전역적으로 사용되는 코드들을 관리하여 좀 더 체계적으로 구현했어야 하는 아쉬움이 있었다.
매일매일 스케줄을 설정하고 데드라인을 정한 상태로 진행해야 체계적일 것 같다. 이 점이 없었떤 것이 스케줄 관리에 있어서 아쉬웠다.
계획을 설정 하고 코드를 진행 할때 팀원들이 코드컨벤션이나 깃 컨벤션을 확실하게 지킬 수 있게 좀 더 체계이고 가독성이 좋게 코드를 구현해야겠다. 코드컨벤션을 확실하게 지키지 못했던 아쉬움이 있었다.
계획이 프로젝트의 반이다 생각을 하며 신중하고 디테일하게 계획을 새울 예정이다.
기능적인 부분에 목적성을 확실히 하며 코드에 대해 어려웠던 점과 느낀점을 인터뷰 하며 차근차근 진행 할 예정이다.
트러블 슈팅에 대하여 어디서 어떻게 문제인지 알려면 코드를 한줄 단위로 확인하며 작업해야 트러블 슈팅의 체크사항 범위가 늘지 않는다, 다음 프로젝트에는 설계단계에서 트러블 슈팅에 어떻게 대처할 것인지 팀원들과 깊은 대화를 나눌 예정이다.