베이스캠프 Sprint5

21.02.15부터 21.02.19까지 베이스캠프 Sprint5를 진행했다.

개발만 진행한 Sprint였다. 개발하면서 당연히 많은 이슈들이 있었고 당연히 힘들었지만 역시 배운게 많은 한 주였다. 여러가지 이슈들 중에서 큼직했던 것들만 이 글에 적어보려한다.

검색 기능 구현

• maven querydsl 설정

  이 설정이 정말 나를 힘들게 했다. 구글링도 엄청 해보고 멘토님께도 질문하고 운영진 방에도 질문드리면서 여러가지 해결책들을 전부 적용해봤는데 해결이 안됐다. 결국 포기하는 마음으로 intellij를 껐다켰더니 잘 됐다… pom.xml에 명시한 항목 중 일부 클래스가 intellij에서 로드가 안되었던 것이다… 긍정적으로 생각하자면 덕분에 querydsl에 관련된 의존성과 maven의 pom.xml에 대해서 자세히 공부하게 되었다. 이 이슈가 없었다면 아마 pom.xml을 자세히 들여도 볼 일은 없었을 것 같다.

• JPQL fetchcount()

  내가 작성한 JPQL 쿼리에 대해서 페이징을 구현하기 위해 fetchcount()가 필요했는데 정상 작동이 안됐다. 구글링 해보니 복잡한 쿼리에 대해서는 fetchcount() 가 정상 작동이 안되니(단순히 select를 count로만 바꾸는 방식으로 구현되어 있다고 한다) count 쿼리를 따로 작성해줘야한다는 결론까지만 찾았고 별 다른 대안을 찾지 못했다. 이 부분은 좀 더 찾아보고 싶다.

• FlightDTO 공통 구현

  검색 결과 페이지와 마이 페이지에서 항공편에 대한 정보를 보여주기 때문에 개발에 있어서 공통부분이 있을 것 같다는 의견하에 마이페이지를 구현하는 팀원과 논의를 통해 공통 부분을 구현했다. 공통부분을 Abstract class로 정의하고 실제 구체화된 클래스에서 이를 상속받아 각자 필요한 부분을 덧붙여서 구현하는 방식을 채택했다. (사실 검색 결과 페이지에서 사용하는 클래스는 abstract class의 필드를 그대로 사용해도 돼서 후에 abstract 속성을 해제하여 구체화된 클래스로 사용했다.) 객체 지향 원리 중 상속을 실제로 이용하여 개발을 진행한 경험이라 신기하기도 하고 뿌듯했다.

메인 페이지 구현

• css

  기존에 하나도 적용이 안되어 있던 페이지에 css를 적용하면서 flex box에 대한 이해를 할 수 있었다. 하지만 css는 여전히 마음대로 안되고 티가 나는 것에 비해 시간이 너무 많이 들어서 나한테 있어서 가성비가 너무 안좋았다. 그리고 정말 시간도둑이었다. 운영진에서 많은 시간을 쏟지 말라고 말씀하신 이유를 알게 되었다. Toast-ui도 적용해보았는데 생각보다 api 문서가 친절하지 않아서 적용하는데 시간이 좀 걸렸다. 사실 html이나 js에 대한 기초지식이 부족해서 그런 것 같기도 하다. API 문서에서 당연히 알만한 부분이라고 생각하여 생략한 부분을 몰라서 헤맸던 것 같다.

검색 결과 페이지 구현

• Http Session

세션과 쿠키에 대한 이해를 할 수 있었다. 처음에 쿠키로 정보를 넘기려다가 쿠키가 스트링밖에 전달이 안됨을 깨닫고 객체 자체를 넘기고 싶어서 쿠키 대신 세션을 사용하고자 했다. 원래는 DTO 객체에 담긴 내용을 객체 통째로 넘기고 싶어서 세션으로 구현을 했다. 하지만 막상 구현하고보니 꼭 필요한 정보가 몇개 되지 않아서 쿠키에 스트링으로 저장해도 됐을 것 같고 혹은 그냥 url에 파라미터로 넘기는 방식이 오히려 나을 것 같다. 추후에 수정할 예정이다.

후기

어떻게든 결과물을 만들어 내긴 했지만 시간에 쫓겨서 마무리한 점이 아쉽다. 물론 기술교육에서 의도한 바도 어떻게든 듀에 맞춰서 서비스 배포까지 마치는 걸 목표로 하는 것 같았다. 좋은 코드 필요없다고 하셨고 그 시간에 기능 하나라도 더 구현하라고 하신 말씀이 생각난다. 좋은 코드를 만들어내는 건 아마 이후의 sprint에서 진행할 것 같다.

처음에는 좋은 코드를 작성하기 위해 노력을 했던 것 같다. 테스트도 짜면서 코드 개발을 했고, 같은 기능을 구현하기 위해서 여러가지 있는 방법들 중에 best를 선택하기 위해 검색도 많이 하면서 개발을 진행했다. 그러다 보니 결국 나중에는 시간에 쫓겨서 주어진 기능조차 다 개발하지 못할 것 같다는 생각이 들었다. 그래서 결국에는 좋은 코드보다는 어떻게든 동작하게끔 하는 코드를 “빠른 시간 안에” 개발하는데 집중했던 것 같다.

그리고 시간에 쫓겨서 아쉬웠던 점은 다른 팀원이 PR을 올렸을 때 코드 리뷰를 다 하지 못한 점이다. 사실 나는 PR에 올라오는 모든 코드를 읽어보고 리뷰를 하고 싶었다. 내가 이해 안되는 부분은 반드시 짚고 넘어가고 내가 개선사항을 제시할 수 있는 부분은 제시하고 싶었다. 그래야 프로젝트 전반에 대해서 각 기능들이 어떻게 구현되어 있는지를 내가 알고 있을 수 있고, 다른 사람의 코드를 읽는 데서 성장을 많이 할 수 있다고 생각했기 때문이다. 그래서 기능 구현이 급하지 않을 때는 다른 팀원들의 코드를 한줄한줄 읽어보고 리뷰를 남기기도 했지만 모든 PR에 대해 그렇게 하지는 못해서 아쉽다.

추가적으로 배포 관련된 설정은 아직 완전히 이해하지 못해서 혼자 내 개발 서버에 띄우는 실습을 진행해봐야 할 것 같다.