정재원
@jjojjo09262343
수강평 작성수
1
평균평점
5.0
블로그
전체 4#카테고리
- 백엔드
2024. 10. 25.
0
인프런 워밍업 클럽 스터디 2기 BE 클린코드 & 테스트 과정- 4주차 발자국
4주차 발자국 회고Presentation Layer 테스트MockMvc 파라미터에 대한 최소한의 검증을 수행한다는 것은 중요하게 생각해 왔지만 해당 부분에 대한 모든 코드는 DTO 객체에서 처리해야만 한다는 생각을 가지고 있었다. 하지만 Validation을 사용해 DTO 객체에서 모든 부분을 확인하는 것은 도메인에 대한 이해를 바탕으로 다른 부분에서 확인해야 할 수도 있다는 코치님의 가르침은 신선하고 흥미로운 부분이었다. 무조건적인 확인이 아닌 좀 더 도메인을 이해하고 그 이해를 바탕으로 검증 시도를 할 수 있는 코드를 작성할 수 있도록 노력해야 함을 느낄 수 있었다.더 나은 테스트를 작성하기 위한 구체적 조언한 문단에 한 주제! 분기에서 나누어지는 모든 상황을 파악하는 것은 하나의 주제라고 생각했지만 그렇지 않았다. 테스트의 제목을 명시하니 그에 대한 이해가 더 크게 다가왔다. 하나의 목적을 두고 그 목적을 저해하지 않는 코드만이 명확한 테스트라는 것은 테스트에 대해 많은 생각을 할 수 있게 된 것 같다.Test Fixture 구성 다양한 테스트를 구성하는데 있어 테스트의 편의성을 추구하고 복잡성을 덜어내기 위해 데이터를 미리 셋업하는 것을 긍정적으로 생각하고 있었지만 자원을 생성할 때 사용되는 파라미터를 중요하게 생각해야 한다는 것은 당연한 말일 수도 있지만 꽤나 충격적이었다. 테스트에 필요한 일련의 객체를 만드는 과정에서 사용되지 않는 즉, 중요하지 않는 파라미터에 대해서는 메서드의 파라미터에서 제외함으로써 현재 진행되는 테스트에서 중요한 것은 무엇인지 읽는 이로 하여금 알려 줄 수 있음을 배운 것은 테스트가 하나의 문서임을 분명하게 깨닫게 해준 것 같다.
백엔드
2024. 10. 20.
0
인프런 워밍업 클럽 스터디 2기 BE 클린코드 & 테스트 과정- 3주차 발자국
3주차 발자국 회고테스트는 왜 필요한가? 테스트 코드 작성에 대한 지식이 없었을 적 불편했던 일들이 코치님이 말하시는 테스트를 작성하지 않았을 때 발생하는 상황과 굉장히 유사했기에 크게 공감하며 이해할 수 있었다. 단순히 알고리즘 문제를 풀 때만 해도 특정 케이스에 대해 잘 못 작성된 코드를 수정하게 되면 올바르게 고쳐졌는지 확인하기 위해 해당 케이스 뿐만이 아니라 기존의 모든 테스트 케이스를 반복해서 돌려봐야 하는 경우가 생긴다. 여러 도메인의 연관 관계가 존재하는 프로젝트에서는 어떠한 영향을 끼칠지 빠른 피드백과 안정성이 필수적이라는 점은 인상 깊게 기억에 남았다.테스트하기 어려운 영역 관측할 때 마다 다른 값에 의존하는 코드가 존재하고 그러한 코드를 테스트 하는 것의 어려움을 이해하고 분리해나가는 과정은 단순히 파라미터 하나 혹은 전역 변수 하나라도 그 위치의 중요성을 고민하게 만들었다. 코드를 작성하는데 있어 단순한 전역변수 하나가 테스트 케이스 구성을 어렵게 만들 수 있다는 것은 신중한 코드 작성 그리고 TDD 방식의 필요성을 직관적으로 이해할 수 있게 도와주었다.Spring & JPA 기반 테스트 Business Layer에 대한 테스트 코드를 작성하는 것은 생각보다 어려움이 많았다. 테스트를 구성하고 해당 테스트가 제대로 동작하기 위해 구체적인 코드를 작성하면서 그에 따라 발생하는 Persistence Layer 테스트를 캐치 하고 새로운 테스트를 작성하는 것은 TDD 방식에 익숙하지 않아 유연하게 따라가기 어려웠던 것 같다. 그렇지만 그렇게 발생한 테스트 코드의 중요성은 깨달을 수 있었던 것 같다. 강의 : Practical Testing: 실용적인 테스트 가이드 (박우빈)
백엔드
2024. 10. 13.
0
인프런 워밍업 클럽 스터디 2기 BE 클린코드 & 테스트 과정- 2주차 발자국
2주차 발자국 회고코드 다듬기좋은 주석?코치님께서 하신 "주석이 많다는 것은 비즈니스 요구 사항을 코드에 잘 녹이지 못 한 것"이라는 이야기는 너무나 충격적으로 다가왔다. 알고리즘 스터디를 진행 해오면서 문제를 풀고 코드를 공유하며 부가 적인 설명 및 이해를 돕기 위한 방법으로 모두 주석을 사용하였는데 지금까지 짜왔던 코드가 읽는 이로 하여금 코드가 아닌 주석에만 집중 하게끔 만든 것이 아닌가 하고 반성하게 되었다.클린 코드 강의에서 주어진 순서에 따라 리팩토링을 하는 과정에서 논리 전개의 과정이 메서드명, 변수명 등을 통해 한 눈이 읽히고 이해되도록 코드를 구성해야 한다는 것을 다시금 반성하고 깨닫게 된 것 같다.리팩토링 연습Day 7 미션지금까지 배워왔던 내용을 바탕으로 주어진 코드를 리팩토링 해보는 것은 굉장히 귀중한 경험이었던 것 같다. 배워왔던 내용들을 직접 적용해 봄으로써 연습하는 것만이 아닌 내가 강의를 들으면서 놓쳤던 부분, 덜 중요하다고 착각 했던 부분을 깨닫게 해줬다. 또한 리팩토링의 여러 관점에 대한 고민을 할 수 있는 넓은 시야를 주었던 것 같다. 처음 미션을 진행할 때는 막연히 중복되는 부분을 쳐내기 바빴지만 그 과정에서 리팩토링의 필요성을 계속해서 고민해 보고 좋은 아이디어를 떠올리기 위해 노력하는 자세를 갖추는 것, 단순히 코드를 고치는 방법이 아닌 개발자로서 꼭 필요한 것을 얻은 것 같았다.강의 : Readable Code: 읽기 좋은 코드를 작성하는 사고법 (박우빈)
백엔드
2024. 10. 06.
0
인프런 워밍업 클럽 스터디 2기 BE 클린코드 & 테스트 과정- 1주차 발자국
1주차 발자국 회고 클린 코드를 추구해야 하는 이유누구를 위한 가독성?사실 처음에는 마음에 크게 와닿지 않았다. 코드를 짜는 방법에 대하여 수 많은 개발자들이 각자의 방식을 통해 공부하였을 것이고 그 방법은 분명 천차만별일 것이기 때문이다. 예를 들자면 어떠한 사람에게는 지저분하고 정리 되어있지 않는 책상으로 보이는 것이 그 책상의 주인에게는 잘 정리된 책상으로 보일 수 있을 것이다. 결국 정말 누구에게나 지저분해 보이는 코드가 아니라면 코드를 짠 당사자에게는 언뜻 가독성이 높을 것이라는 생각이 들었다.하지만 혼자 하는 것이 아닌 이후 새로이 팀에 합류할 사람들 또한 단번에 이해 가능해야 한다는 말에 개발은 혼자 하는 것이 아니라는 사실을 다시금 깨달았다. 많은 경험은 아니지만 프로젝트를 진행할 당시 코드 리뷰를 진행 했던 경험이 있었지만 문제가 될 수 있는 요소를 같이 찾는 과정에 불과했고 각자의 코딩 방식에 서로 개입하지 않았기에 각자 담당한 역할만 잘 소화해낸다면 충분할 거라는 생각을 갖고 있었기 때문인지 나의 코드를 다른 사람이 이어받을 수 있다는 생각을 전혀 하지 못했던 것 같다. 워밍업 클럽이 끝난다면 이전 프로젝트에서 작성하였던 코드를 다시 읽어보며 과연 타인에게도 읽기 좋은 코드였는지 오랜만에 읽어보는 자신에게도 막힘이 없었는지 확인해 보는 시간을 갖고 또 부족한 부분에 대해 파악하고 싶다는 생각이 들었다.추상적 사고 기반의 이름 짓기이름 짓기에 대한 강의는 무척 간단해 보이면서도 굉장히 큰 깨달음을 주는 듯한 내용이었다. 예전부터 변수명, 함수명에 대한 표현의 중요성을 자주 접해왔지만 적절한 예시를 보지 못했기 때문인지 충분히 잘 해내고 있었다고 생각했지만 강의 안에서 차례로 큰 흐름에서 코드의 추상화 레벨을 맞추어 나가는 과정에서 추출해내고 이름을 붙이는 각 함수와 변수들을 통해 이름 짓기가 가독성에 얼마나 많은 정보를 전달 가능한 지 배울 수 있었다.객체 지향 패러다임 관심사'단 하나의 관심사로 책임을 정의 하는 것' 그리고 '그것을 파악하는 눈'에 대한 공부는 굉장히 놀라웠던 것 같다. 단계적으로 관심사를 분리해나가는 과정에서 언뜻 완벽해 보이지만 높은 결합도는 계속해서 발견되었고 그것을 분리해 내는 과정은 인상적이었다. 관심사를 분리해 내는 것은 어떻게든 해낼 수 있을 것 같았지만 그 결합을 발견해내는 것은 어려운 일이었다. 그렇기에 클린 코드를 추구하며 결합도를 보는 눈을 끈임 없이 연습해야함을 느낄 수 있었다." 객체에 메세지를 보내라! "setter의 위험성에 대해서는 수 없이 들어왔지만 getter의 필요성에 대한 의문은 단 한번도 가지지 않았던 나에게는 놀라운 사실이었다. 정말이지 익숙하지 않아 강의 도중 객체의 필드가 필요해 질 때마다 "지금이야말로 getter가 필요한 타이밍인가?"라는 생각이 수 없이 들었던 것 같다. 그리고 나는 개발을 할 때 불필요한, 코치님의 표현에 의하면 객체에게 굉장히 무례한 코드를 남발하였던 것 같다. 항상 왜 필요한 지, 반드시 필요한 것인지에 대한 의문을 제기할 줄 알아야함을 깨달을 수 있었다.SOLID각각의 원칙을 이론이 아닌 상황에 맞춰 직접 실습해 볼 수 있는 것은 좋았지만, 만일 혼자서 코드를 리팩토링하게 된다면 코드를 어떠한 원칙을 기반으로 수정을 해야겠다는 생각이 들었는지 다른 사람들에게 잘 설명할 자신이 없었다...SOLID 원칙을 이해하고 적용하는 것의 중요성과 반복적인 학습의 필요성을 느꼈다. 객체 지향 적용완벽한 설계는 없다. 그 당시의 최선만 있을 뿐 인터페이스, Value Object, 일급 컬렉션, Enum 등의 활용에 대한 많은 것을 배울 수 있었지만, 가장 흥미로웠던 과정은 도메인에 대해 이해하게 되는 과정이었던 것 같다. 객체 지향을 위해 활용하면 좋은 내용들은 많지만 그러한 것들은 결국 도메인에 대해 이해하고 그 필요성을 얻는 과정이 선행되었던 것 같다. 도메인을 설계하면서 생각해낸 개념이 아닌 개발해가는 과정에서 숨겨져 있던 도메인의 개념을 도출하고 그것을 언제든지 받아들일 수 있도록 대비할 수 있는 개발자가 되어야겠다는 생각이 들었다.강의 : Readable Code: 읽기 좋은 코드를 작성하는 사고법 (박우빈)
백엔드
