결정된 사안들에 대한 문서화를 하는 것이 매우 중요했다. 어떤 결정에 도달하기까지 많은 의견들이 오갔다. 명확하고 모두가 수긍하는 결정으로 결론지어지는 경우가 잘 없다보니 각자 결론을 다르게 기억하고 있는 경우도 존재했다. 따라서 문서화를 통해 사소한 것 들 이라도 기록 했던 것이 추가적인 회의시간을 발생시키지 않아 좋았다.
처음부터 jacoco 를 통해 테스트 커버리지를 측정하고, 특정한 테스트 커버리지에 도달하지 않을 경우 빌드 실패 되도록 제한을 두었다.(초반에는 60 퍼센트 정도의 낮은 퍼센트로 설정해두었고 최종적으로 85프로를 목표로 하였다 ) 이를 통해 로직을 가진 클래스들에 대해 유닛테스트를 작성하는 습관을 가질 수 있었다. 평소 시나리오 작성시 성공테스트 하나, 실패 테스트 하나씩 정도 만 작성하고 있었다. jacoco 는 코드 라인 별로 어떤 라인들이 커버되었고 커버되지 않았는지를 알려준다는 특징을 가지고 있었다. 덕분에 성공,실패 하나씩이 아닌, 발생할 수 있는 여러 시나리오에 대한 테스트를 작성하고자 노력하며 테스트를 작성하게 되어 좋았다.
팀원들과의 코어타임과 스크럼을 가졌다. 코어타임을 통해 발생하는 이슈에 대한 즉각적으로 각자의 지식을 나누며 해결할 수 있었고( 사소하게는 나는 git 과 jacoco 나 소나클라우드에 대한 기본 사용 방법도 제대로 숙지하지 않고 있어 어디가 문제인지도 몰랐는데 이런 사소한 일로 시간을 끌 뻔 하던 것도, 부담없이 물어보고 추가적으로 찾아보며 해결할 수 있었다 ) , 스크럼을 통해 어디까지 진행이 되었는지 어려운 부분은 없는지 어려운 부분은 다른 사람에게 부탁하여 너무 오랜 시간을 끌지 않을 수 있어 좋았다.
1차 스프린트 때에는 제약조건을 제외하고 동작하는 API 를 먼저 작성하는 것에 초점을 두었다. 그러다보니 생겼던 문제가 우리 API 를 사용하는 클라이언트(프론트) 측에서 “불친절한 에러 메시지" 를 받게 되는 것이었다. 문제는 우리측에서도 어떤 요청이 들어온지 추적이 되지 않고 있던 것이었다. 따라서 컨트롤러 까지 오는 요청들은 모두 로그로 출력합시다!! 라는 목적으로 로그를 출력했는데 생각해보니 이를 통해 API log 를 추적하고 있는 것이 되었다. 이를 통해 controller 까지 도달하지 못한 요청들(토큰 에러 등)을 추적하고,
많은 것을 문서화 하였지만 대부분의 내용이 “회의록" 에 기록 되었다. 이로 인해, 정책적인 부분이 회의시간에 결정된 것들은 “어느 회의에서 말했더라??” 라고 생각하며 검색하거나 결국 이 내용을 찾는 시간이 더 소모되기도 했다. → 요구사항 명세, 정책에 대한 문서가 좀 더 분리되어 작성하면 좋을 것 같다
상당히 많은 테이블이 엮이고 정렬하는 쿼리가 많았는데 이에 대한 성능 측정이나 튜닝을 하지 못했다. 디비와 관련해서 성능 측정에 대한 지식이 부족했고 이에 대한 쿼리 로그는 어디에서 보아야 하는지에 대해서 알 겨를 없이 급급하게 작성 했었다. → 공식적인 프로젝트 기간을 끝이 났지만, 쿼리 튜닝을 해야 할 필요성이 느껴진다.
로직 자체가 들어있는 쿼리 가 많이 존재한다. ORM 을 사용할 때는, 어플리케이션 코드를 통해 재사용 가능한 것을 생산하는 것이 중요하다고 생각했는데, 결국은 급하게 필요한 요구사항을 만족시키기 위해서는 한 번 사용할 쿼리들을 작성한 경우도 많았다. 이로 인해 도메인도 여러가지가 얽혀 있었고 도메인간의 계층 분리가 제대로 이루어지지 않았다.