부제 : 개발자의 비판적 사고와 설득 방법

테스트 코드를 작성하는 데 데이터를 다룰 때면 초기화가 필요한 상황이 생깁니다. 이때 명시적으로 데이터를 초기화를 해주는 방법과 @Transactional 을 사용해서 테스트가 끝나면 데이터를 초기화해주는 방법이 있는데 이 두 가지 방법에 대해 세분의 의견에 대한 글이 있어 공유합니다.

사실 저도 테스트 데이터 초기화 방식에 대해서는 @Transactional보다는 명시적으로 데이터를 초기화해주는 방법을 선호하긴 합니다. 이 글의 저자분께서 예를 들어주신 것처럼 @Transactional의 특성으로 인해 제대로 된 테스트가 이루어지지 않을 수 있기도 하고 무엇보다 테스트 코드는 코드만 봐도 명시적으로 이해할 수 있어야 한다고 생각이 들어서인데요. ('이해', '명시적'이라는 단어가 사람마다 다르겠지만 결국 팀에서 추구하는 가치에 수렴하지 않을까 생각합니다.)

이 글을 공유하는 이유는 테스트 데이터의 초기화를 어떻게 해야 할까라는 관점보다는 개발자가 문제를 바라보는 비판적 사고와 어떤 식으로 접근을 하며 설득을 해야 하는가에 대해 더 이야기하고 싶었기 때문입니다.

이 글에서 나오는 세분 모두 방식이 대체적으로 비슷합니다. 자신의 생각을 이야기하고 → 그 이유를 말하고 → 이유에 따른 근거를 밝히고 (실제 구현을 해본다거나, 관련 사례를 이야기한다거나) → 반대 의견을 수용하지만 문제점을 조심스레 이야기하는 호흡. 저도 요즘 노력하는 개발자 커뮤니케이션의 기본이라 생각이 드는데 어쩜 세분 모두 이야기하는 방식이 비슷하셔서 놀랬는데요. 자신의 과거 경험을 토대로 해보니까 문제없다는 "자신이 곧 근거"가 되는 형태의 이야기나 상대방의 의견을 수용 못하고 기존에 방식대로 따라가려는(변화를 싫어하는) 자세, 더욱이 서로가 설득이 되지 않아 다수결로 방법을 채택하려는 흐름은 썩 좋지 못한 조직을 만들어가는 지름길이 되지 않나 생각을 해봅니다.

개발자는 코드로 이야기해야 하는 사람입니다. 감에 의존한다면 그 선택은 얼마 못가 잘못된 선택이 될 확률이 높죠. 물론 개발은 언제나 그랬듯 정답이 없습니다. 이 세분의 이야기처럼 말이죠. 다만, 설득의 근거가 뚜렷하고 장점과 단점 중에 팀의 기준에 맞춰 선택을 하는 과정이야말로 개발자가 가져야 할 덕목이 아닐까 싶습니다.

https://jojoldu.tistory.com/761