[1주차] WIL

”한 번의 실수는 배움이, 두 번의 실수는 실력이 된다.”

→ 개선 사항 추적과 리마인드를 통해 동일한 문제나 같은 실수를 반복하는 결과를 만들지 않습니다.

”경험이 없다면 창조도 없다.”

→ 경험한 것을 기록해두면 더 잘 활용하기 위한 방법으로 연결시킬 수 있습니다.

“I may be wrong.”

→ 끊임없는 회고를 통해 자기객관화를 달성하고, 자신의 실수와 잘못을 인정할 줄 아는 용기 있는 사람이 됩니다.

1주차를 돌아보자.

TDD 방식의 개발

TDD 방식으로 처음 개발해보면서, 진행 속도가 너무 더뎠지만 결국 전체적으로 보면 가장 빠른 길이라는 믿음을 가지고 진행하였다.

단위테스트를 짜며 테스트 코드 작성을 방해하는 강결합되는 코드에 대해 인식하게 되었고,

그동안 테스트 종류에 대한 이해나 테스트 어노테이션에 대한 지식이 하나도 없이 샘플 테스트에 맞춰서 구현만 했던 것 같았다.

1주차 과정에서 각 테스트의 존재 의미를 많이 생각해보게 되었고, 테스트 코드를 잘 짜는 법이 곧 구현 코드를 잘 짜게 되는 방법이라는 것을 깨달았다.

단위테스트를 작성하는 데에 있어서 mock은 사용해봐서 어떻게 사용하는지 아는데, stub의 개념을 잘 몰랐다.

이번 1주차 과제에서는 익숙하던 mock으로 개발했지만, 과제 제출 후 stub을 이용한 방식으로도 바꿔보며 stub에 대한 공부를 하였다.

개발 흐름

실무에서 개발할 때, 설계되어 있는 테이블과 API 명세서, 기획서를 보고 컨트롤러에서부터 서비스 로직, DB 호출까지 다 한 다음 통합테스트를 돌려보는 그런 흐름을 가지고 개발을 하고 있었다.

이번 과제를 하며 이런 흐름이 굉장히 어색하다고 느꼈고, 결국 테이블 설계와 API 명세는 서비스 로직에서부터 시작된다는 것을 알게 되었다. 그동안 한창 개발이 진행되는 중에 어떤 것이 더 필요하다거나, 어떤 것이 필요하지 않아졌다거나 하는 경우가 늘 있었다.

테스트를 기반으로 서비스 로직을 작성하며 필요한 것만 알게 되는 과정이 전체 개발 과정을 더 핏하게 만드는 것 같다.

동시성 제어 처리

동시성 제어를 하는 방법을 찾고, 구현하고, 테스트하는 것에 가장 많은 공이 들었다.

동시성 제어를 처리하는 코드를 구현하는 것이 처음이라, 많은 검색을 통해 방법들을 비교했다. 다행히 이번 주차 과제에서는 DB가 설정되지 않아 간단한 구현만 할 수 있는 상황이어서, 간단하게 ConcurrestHashMap을 통해 구현했다.

통합 테스트

오히려 단위 테스트는 한땀한땀 하느라 시간이 오래 걸렸지만, 진행이 답답했던 것은 통합 테스트 작성에서였다.

RestTemplate 라이브러리는 patch api 호출 메서드가 없다는 것을 이번에 알게 되었다. patch 호출을 따로 세팅해서 처리하는 방법을 시도했는데, 생각처럼 잘 되지 않았다. 그래서 새로 RestAssured 라이브러리를 이용하여 테스트하였다.

이번 과정에서의 목표 달성

워낙 내가 개발 지식이 없다고 생각해서,(실제로 그렇다는 것을 느끼는 중이다.)

첫 주차에는 잘 따라만 가자! 모르는 용어에 기죽지 말고 당당하게 배우자! 가 목표였는데 적당히 잘 당당하게 배움의 용기를 실천한 것 같다.

하지만 내가 원하는 나의 모습은 어느 하나에 대하여 깊은 이해를 하기 위해 Dip dive하며 결국에는 동작 원리를 알고 개발하는 그런 모습인데, 아무래도 그런 경험이 없다보니 또 그냥 코드 작성만 한 것 같아서 아쉽다.

다음 과정에서의 목표

~~다음 주차에는 이번 주차에 연습한 TDD를 활용하여 과제를 구현해보고 싶다.~~ 사실 지금 2주차도 다 지났다. 그래서 다음 목표는...2주차 회고에서부터 적어보겠다.

728x90

iwannabarmus