메인프로젝트 결과물

펫밀리

메인페이지,Header (내 담당)

로그인 페이지

회원가입 페이지

산책글 작성 페이지

상세페이지 (내 담당)

메인프로젝트의 마지막 회고

이번 프로젝트4주의 시간이 지났다. 이것저것 만들려고는 했지만 짧은 시간과 기술력?의 한계로 원하는 것을 다 완성하지는 못했지만 초기의 기획 한 것 까지는 모두 완성해서 목표를 이룬것 같았다 하지만 멘토님의 코드리뷰와 말씀을 들어보면 우물안 개구리와 같았다.

지금 까지 우리는 시간에 쫓기듯이 마감기한을 지켜서 제출하려고 동작만 되는 코드를 구현했었다. 사실 이렇게 하면 안되는 것을 알면서도 진행해왔었다. 깔끔한 코드를 즉 클린 코드를 작성해야했는데 남들에게 보여지고 평가받는 프로젝트이다보니 겉으로 봤을때 동작이 되는 것을 우선적으로 처리하다 보니깐 이런 사태가 발생한 것 같다. 일단 내 파트에서 몇가지 문제점들을 다시 회고 해보면서 느낀점을 작성하겠다.

새로 고침 문제....

여기서 새로 고침 문제란.

코드를 보면 window.location.reload() 이부분이 말썽이였다. 위 코드는 강아지 산책에 데리고갈 강아지를 골라서 post요청을 보내는 것인데 post요청이 정상적으로 잘 이루어지면 reload()를 해주고 toast알람을 알려주려고 했었다. 하지만 window.location.reload()가 일어나면 새로고침 되어버려서 아예 뒤에잇는 toast 알림이 동작하지 않게 되었다. 이 문제를 해결하기 위해서 usenavigate 를 사용했었는데. 경로가 같은 경로에서 이루어지다 보니깐 usenavigate는 아무런 동작을 하지 않았다.

사실 post요청을 잘 보내진 것인데 화면상에서 아무변화가 일어나지 않아서 유저 입장에서는 usenavigate를 쓰면 댓글이 달렸는지, 펫이 참가했는지 알아볼수가 없었다. 그래서 window.location.reload()를 해줘서 새로고침을 통해 변화를 확인했었는데 이러면 toast알림을 확인 할수 없어서 아쉬웠다.

그래서 지금 현재까지도 다른 방법을 찾아보고있는 중이다. 오류해결 방법을 찾으면 글을 수정할 예정이다.

오류 해결 완료!!

해결전

페이지를 새로고침을해줘야 user 입장에서 바뀌는 것을 확인 할 수 있다.

해결후

새로고침을 하지않아도 참가하기를 누르면 값이 잘 바뀌는것을 확인해 볼 수 있다 .

코드를 이런식을 수정해 주었다 하지만 아직 고칠점이 많은것 같다 일단 새로고침안해도 유저가 확인할 수 있게끔 코드를 수정하였지만 아직도 불피요하게 get요청과 유지보수를 할때를 생각한다면 지금 코드는 아주 문제가 많은것 같다 그래서 메인프로젝트가 끝났지만 하나하나 유지보수를 해 나아갈 예정이다.

알수 없는 오류들과....? 해결!

통합테스트를 하고 알수 없는 오류들이 이것저것 생겨났다. 특히 내파트에서는 참가하기를 누르면 랜덤으로 member가 host로 바뀌고 host 가 member 로 바뀌는 문제점들을 확인할 수 없었다. 그래서 백에서는 동시성 오류( 여러사람이 클릭시에 오류가 발생함)으로 생각해서 동시성 오류 코드부분을 추가 및 수정을 했다. 그리고 다시 테스트하는데 잘동작하였다. 그 이후에 다시 테스트를 하는데 또 host와 member가 뒤바뀌는 것을 확인 할 수 있었다. 우리팀은 멘붕에 빠졌고 나도 다시 내코드를 확인했따. 백 쪽에서 자신의 코드가 이상이 없고 postman으로 확인까지했다며 내 코드를 봐달라고 했고 내 코드에서도 이상한 점을 찾을 수가없었다.

  {index > 0 && (
                <div>
                  {attendee.userId ===
                    (TOKEN_USERID !== null ? parseInt(TOKEN_USERID) : null) && (
                      <FiTrash2
                      className="delete-icon"
                      onClick={(e) => {
                        e.stopPropagation();
                        handleDeleteUser(attendee.id);
                      }}
                    />
                  )}
                </div>
              )}
              <ProfileCard
                src={attendee.imgUrl ?? undefined}
                alt="프로필이미지"
              />
              <Username>{attendee.nickname}</Username>
          <Role>{index === 0 ? 'Host' : 'Member'}</Role>

코드를 보면 처음 apidocs를 만들때 api에 무조건 참가하는사람은 host가 되어야한다고해서 애초에 글을 작성할때 작성자가 무조건 host가 되어야해서 index > 0 보다 클때 즉 0
보다 큰사람들은 모두 member 가 되게 끔 코드를 작성하였다. 코드상에는 문제 가 전혀 없어 보였다. 혹시나해서 host.id와 ateedees.id(참가하기를 누를id즉 member의 id)를 비교하는식으로 작성하려고 수정을 하려고 했다.

코드를 수정하기 전에 문제점을 발견했다. 뭔가의 패턴대로 참가하기의 순서가 바뀌는 것이였다. 알고보니 참가하기를 나열할때 백에서 userid의 순서로 나열을 하게끔 로직을 짜서 이런 오류가 발생되고 있는 것이였다. 사실 내코드를 수정하기 귀찮아서 심혈을 기울여 찾다보니 문제점을 찾아내었다.ㅎㅎ 결국 내가 제시한 문제점이 맞았고 해결할것 같지 못했던 오류를 해결하게 되었고 팀원들에게도 칭찬을 받게 되었다.

오류를 해결하면서 느꼈던 점은 혼자할때는 내가 무슨코드를 작성했고 어떤 원리로 코드가 돌아가는지 아니깐 문제를 해결하기 쉬운데 팀적으로 활동할때는 각자의 코드를 합치는 거기때문에 오류를 발견하기 어렵다는 것을 느꼈따. 그래서 기획을 할때 서로 이러한 엣지케이스들을 잘 정해야겠다고 느꼈고 앞으로 현업에서 일을하게 될텐데 이러한 과정들이 앞으로의 현업에서 있을 문제점을 해결하는데에 도움이 될것 같다는 생각을 가지게 되었다.

반응형 웹 만들어보기

지금 현재 만들어진 웹 사이트를 보면 반응형을 하나도 적용하지 않은 것을 볼 수 있다. 현재 우리는 시간에 쫓기다 보니일단 큰 사이즈에서 만들어 놓고 그 다음에 시간이 여유가 되면 반응형으로 바꿔보자 했다. 수강을할때 반응형에대해서 강의내용은 없었고 우리가 직접 공부하고 해야되기 때문에 후순위로 밀었다 그러나 페이지를 콘솔창을여거나 페이지가 줄어들었을때 버튼과 navbar 들이 보기 좋지 않게 찌그러지고 구겨지는 현상을 볼수있었다. 수정해야지....수정해야지... 말만하고 시간이 부족하다는 핑계만대고 완성본으로 제출 하였다.. 팀끼리 회고를 할때도 이부분에대해서 리팩토링을 하면서 반응형으로 만들어보자고 의견이나왔고 메인프로젝트가 끝난지금도 반응형으로 만들려고 각작 공부중이다 . 이것도 수정되면 글을 업데이트 하겠다.

메인프로젝트를 하면서 느낀점

프로젝트를 들어가기전에는 겁을 엄청 많이 먹고 있었다. 타입스크립트도 처음이고 여러가지 기술을 사용할 자신이 없었다. 사실 axios 요청 을 보내는 것도 익숙치 않았었다. CRUD 도차 제대로 작성하지 못한상태였다. 하지만 이번 프로젝트를 하면서 많이 배우고 깨닫게 되었다.

일단 프로젝트를 할때 코딩만 주구장창 하는 줄 알았는데 큰 오산이였다. 화면정의서, 사용자 요구 정의서 백엔드와 API DOCS 까지 정해야 될게 많았다. 거의 4주의 기간동안 2주동안은 끊임 없는 회의와 수정을 거쳐야 했다. 회의를 하면 할수록 수정해야될 것과 추가해야 될것이 점점 늘어갔고 이에 대해 갈등도 생겨 나아갔다. 전에 회고를 했을 때 의견 갈등이 있었을때 해결해 나아가는법 상대방의 의견을 존중하고 나의 의견을 제시해 팀원들이 생각했을때 목표에 부합하는 의견을 다수결로 정하면서 프로젝트를 진행 하였다.

3~4 주차가 되자 각자 코딩하는 시간이 많아지게 되었고 각자 작업에만 몰두하게되었다. 돌이켜 보면 여기서 큰 아쉬움이 많이 느껴졌다. 시간에 쫓겨 각자의 코드를 리뷰하고 어디까지 작업을 했는지 공유를 하지 않았었다. 그래서 프로젝트가 끝나서야 각자의 코드를 설명하고 들으면서 여러가지 감정을 느꼈따. 특히 팀원분 한분이 "예훈님은 왜 이렇게 작성하셨나요? 이렇게 꼭 작성하셨던 이유가 있나요?" 라는 질문을 했을때 순간 머리가 새 하얗게 변했다. 그 순간에는 내가 왜 이코드를 이렇게 썼지? 뭐지? 라는 생각 들었다. 지금 생각해보면 그 코드는 해결하지 못해서 구글링과 GPT를 참고하면서 작성해서 내 머리속에 크게 각이 되지 않았던 것이였다. 그래서 많은 반성을 하게 되었고 잠시 시간을 갖고 자신의 코드를 다시 정리해서 코드리뷰를 해도 되겠냐고 질문을 드렸었다. 코드를 다시한번 정리하고 생각하면서 내가 왜 이때 이런 코드를 짰지? 라는 생각을 하면서 다시 한번 복기해 나아갔다. 그리고 다음 코드리뷰가 있을때 같은 질문이 들어오면 나의 생각을 잘 정리해서 말씀드릴 수가 있었고 팀원들이 코드 리뷰를 할때 상대방의 코드가 왜이렇게 작성되고 어떤 생각을 가졌는지 진짜 궁금해서 질문들을 던지기 시작했다. 코드리뷰를 할때마다 스스로 작성한 코드의 자신감을 가지게 되었고 스스로 생각하는 과정과 상대방의 코드를 분석하고 탐구하는 자세를 기르게 되었다.

다른 팀 프로젝트 탐방후 느낀점

데모데이때 같이 6개월간 함께했던 기수들이 우리의 프로젝트를 보고 피드백 해주는 시간이 있었다. 기능이 다 구현되었다고 느낀 우리조는 생각 외로 사람들이 회원가입할때 불편함을 많이 느껴서 다른기능들을 잘 볼수 없다고 피드백을 주었었다. 그래서 우리조는 급하게 회원가입 로직들을 수정하고 나서 다른 팀들의 프로젝트를 구경했다. 생각했던 것보다 다른팀들도 좋은 퀄리티의 프로젝트들을 작성하였고 깃브랜치 전략, 폴더 파일 구조 등 코드등을 살펴보았다. 각자 팀마다 다른 전략들을 사용하였고 어떤 팀들은 코드를 잘 읽어보지 못하겠는 코드도 있었고 어떤 코드들을 책을 읽듯이 이해할수있는 코드들도 있었다. 즉 클린코드의 중요성을 배우게 되었다.

그리고 다른 프로젝트들을 보면서 서비스 및 분석 피드백을 주는것이 상당히 재미있고 흥미가 있었다. 고객입장이 되어보면서 버튼이 불편하지는 않는지? 화면을 줄였을때 기능들을 잘 동작이 되는지? 버튼을 많은사람들이 한꺼번에 눌러보면서 문제는 없는지 등 다양한 피드백을 주고 받았다.

피드백을 주고받다보면서 소프트웨어 QA 라는 직업에 대해 알아보게되었고 흥미 있는 직업이였던거 같았다. 꼭 정해진길이아니라 다양한 경험을 해보면서 내게 맞는 일을 찾아야겠다고 느껴지게 되었다.

이제 앞으로 취업 을 하기 위한 많은 고난과 역경이 존재하겠지만 앞으로 실패를 하더라도 멀리 나아가는 양분을 삼아 앞으로도 멀리 더 높게 나아갈 예정이다. 지금 모든 순간들을 후회하지 않고 나중에 소주한잔 하며 얘기하며 웃어 넘길 수 있는 그런 순간들을 만들기 위해서 노력해야겠다고 생각된다.