코드스쿼드 첫 번째 프로젝트 회고

2022년 4월 4일부터 4월 15일까지 2주간 진행했던 프로젝트에 대한 회고 글입니다.
2주차 프로젝트 데모 시간에 발표한 내용을 기반으로 글을 작성해보았습니다.

협업

이번 프로젝트의 핵심 키워드는 협업이었다. 아무래도 팀 프로젝트가 처음이다보니 협업을 연습해본다는 생각으로 협업에 제일 먼저 생각하게 됐다. 감사하게도 함께 프로젝트 하게 된 쿠킴도 같은 생각이어서 안드로이드 팀원인 우기와 정박과 함께 프로젝트 초기에 앞으로 어떤 방향으로 프로젝트를 진행할 지 많은 대화를 나누게 되었다.

쿠킴이 주도해주신 덕분에 공유 notion 을 만들어서 매일 팀 스크럼과 회의 내용을 기록하고, 프로젝트에 앞서 그라운드 룰을 도입할 수 있었다. 그라운드 룰에는 프로젝트에 집중하는 시간, 브랜치 전략, 커밋 컨벤션, Github 의 Projects, Issues, wiki, PR, 디렉토리 구조를 어떻게 할 건지 협의를 거쳐 내가 속한 팀만의 룰을 만들었다.

Github 의 프로젝트, 이슈, 마일스톤을 활용하였는데 api 설계하고 이슈에 어떤 개발을 할 지 등록하여 개발해보니 개발 진행 상황을 공유할 수 있어 좋았고, 역할을 분담하기에도 수월했다.

 

Notion 을 이용한 프로젝트 관리

 

그라운드 룰

 

 

 

 

쿠킴과는 그 날 구현한 것에 대해 PR 리뷰를 함께 보내고 리뷰어가 리뷰한 내용을 함께 논의했다. 이렇게 리뷰어가 리뷰한 내용을 함께 학습하고 이해가지 않는 부분은 리뷰어에게 다시 질문도 하며 이 과정에서 많은 학습을 할 수 있었다.

PR 리뷰 받은 것 중 하나의 PR

테스트 기반의 개발

이번 프로젝트를 하며 기술적인 도전으로 테스트를 기반으로 한 개발을 해보았다. 인수 테스트를 작성하며 개발할 API 가 어떤 흐름으로 개발하게 될 지 볼 수 있어 요구사항을 파악하기 좋았다. 또한 테스트 코드를 기반으로 한 개발이다보니 코드를 수정하게 되었을 때 빠르게 확인할 수 있었고, 내가 작성한 코드에 신뢰가 생기는 느낌을 받을 수 있었다. 하지만 테스트 코드를 작성함에 있어 부족함이 있다보니 엣지케이스를 잘 파악하지 못하였고, 그러다보니 시간 데이터에 대한 에러가 발생하였는데 확인해보니 시간 데이터에 대한 테스트가 없었다. 테스트 코드 엣지케이스를 포함한 여러 케이스에 대한 테스트가 필요하다는 걸 느꼈다.

아래는 작성한 인수 테스트의 일부분

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
@DisplayName("API /api/todos/* 인수 테스트")
class TodosApiAcceptanceTest {

    @LocalServerPort
    int port;

    @BeforeEach
    @Sql({"/testDB/schema.sql", "/testDB/data.sql"})
    void setUp() {
        RestAssured.port = port;
    }

    @Test
    void 특정_투두리스트_조회_성공() {
        given()
            .accept(MediaType.APPLICATION_JSON_VALUE)

        .when()
            .get("/api/todos/1")

        .then()
            .statusCode(HttpStatus.OK.value())
            .assertThat()
            .body("id", equalTo(1))
            .body("title", equalTo("Github 공부하기"))
            .body("contents", equalTo("add, commit, push"))
            .body("user", equalTo("sam"))
            .body("status", equalTo("doing"));
    }


    @Test
    void Todo의_타이틀_수정_요청시_수정된_Todo를_반환한다() {
        JSONObject requestBody = new JSONObject();
        requestBody.put("title", "블로그에 포스팅 꼭~~~~하기");

        given()
            .accept(MediaType.APPLICATION_JSON_VALUE)
            .header("Content-type", "application/json")
            .body(requestBody)

        .when()
            .patch("/api/todos/2")

        .then()
            .statusCode(HttpStatus.OK.value())
            .assertThat()
            .body("id", equalTo(2))
            .body("title", equalTo("블로그에 포스팅 꼭~~~~하기"))
            .body("contents", equalTo("*Github 공부내용 \\r\\n *모던 자바스크립트 1장 공부내용"))
            .body("user", equalTo("sam"))
            .body("status", equalTo("todo"));
    }

    ...
}

개발 환경, test 환경, 배포 환경 영역 구분

개발 환경, test 환경, 배포 환경 영역을 구분해보았다. 개발과 배포 데이터베이스는 MySql 에 연결하여 사용하고 있었고, 테스트 코드는 h2 에 연결하여 사용하고 있었는데 구분하지 않을 땐 데이터베이스 연결을 매번 바꿔야하는 어려움이 있었다. 이 영역을 나누고나니 따로 연결을 바꿀 필요가 없어 수월하게 개발할 수 있었다.

구분된 개발 환경과 테스트 환경

config 관리

반복되는 코드를 config 설정을 통해 코드 중복을 피할 수 있었다. @RequestMapping 어노테이션을 contorller 마다 붙여줘야했지만 config 파일에 설정하게 되면 이렇게 컨트롤러 패키지 내에는 자동으로 /api path 가 적용될 수 있었다. 또한 todo 의 create time update time 과 같은 시간 데이터가 생성되었는데 이 데이터를 클라이언트 개발자와 협의된 포맷으로 보내주기위해 각각의 코드마다 포맷을 설정해주던 걸 config 파일을 통해 따로 설정해주지 않아도 되는 용이함이 있었다. null 을 빈 문자열로 바꾸는 설정을 시도했지만 여러 삽질 끝에 구현은 하지 못해 이것은 아직 숙제로 남아있다.

 

이번 프로젝트를 통해 팀 프로젝트는 정말 협업이 중요하다는 걸 느꼈다. 소통과 배려라는 단어를 계속 떠올리게 됐다. 이번 2주간의 경험을 바탕으로 앞으로 있을 프로젝트를 더 잘 할 수 있도록 노력해야겠다.