[Share] 2주차 토론 내용

[sojeongw]

Topic

2주차 모임에서 오갔던 대화를 기록합니다.

대화 흐름마다 부제목으로 나눴습니다. 대화가 빨라서 놓친 부분도 많으니 참고해주세요.
뭔가 가독성 좋게 만들고 싶은데 잘 안되네요. 다음엔 좀 더 고민해보겠습니다!

Detail

제어의 역전

팩토리 패턴의 장점

현식
테스트 할 때 factory 를 쓰면 좋다. 메소드 안에서 new 하는 일이 많으면 test 짜기 어렵다.

프레임워크에 엮여 있을 때도 테스트 만들기가 어렵다. 안드라면 안드 위에서만 의미를 갖지 PC 위에서는 동작하지 않는다.

그때는 팩토리 패턴을 이용해서 책임을 다른 쪽에서 갖도록 한다. 혹은 파라미터로 받아서 의존성 주입을 한다.

애플리케이션 컨텍스트 생성

현식
애플리케이션 컨텍스트를 생성할 때 daoFactory 외에 더 많은 클래스를 사용하고 싶다면 어떻게 하는가?

민수
컨텍스트를 여러 개 만드는 방법이 있다.

싱글톤 패턴

싱글톤 관리 방식

현식
리소스를 낭비할 가능성이 있어 싱글톤을 쓴다고 했는데, 그럼 싱글톤 관리는 어떻게 하는가?

주형
정확히 모르겠다. 코드를 뜯어봐야 할 것 같다.

의존 관계

현식
의존이 무엇인지 구체적으로 알고 싶다.

주형
우아한 객체 지향 강의를 보니 의존이라는 건 바뀔 때 같이 바뀌는 것이라고 설명했다. 딱 맞는 것 같다.

준희
나는 사용한다는 의미로 이해하고 있다.

현식
의존을 설명할 때 관계 설정의 개념도 있기 때문에 그 설명은 좀 부족한 것 같다.

성재
말이 빨라서 못 적음(혹시 기억나시면 추가해주세요!)

런타임에서의 의존 관계 설정

현식
런타임 클래스에 대한 의존 관계가 나타나지 않는다는 게 무슨 말인가?

주형
런타임 때에 클래스끼리 관계가 설정되고 그 전에 코딩 할 때는 안 되어 있는 것이라고 이해하고 있다.

김준희
코드들이 호출되는 시점이라고 이해하면 될 것 같다.

의존성 주입

준희
setter와 생성자 주입의 차이가 무엇인가?

현식
생성자는 객체를 만들 때 반드시 해야 하니까 setter 보다 강제된다. nullable하지 않은 것은 생성자로 하는 게 좀 더 좋을 것 같다.

그런데 생성자가 너무 많아지면 코드를 읽기가 힘들어진다. 수 많은 파라미터가 뭘 의미하는지 계속 파악해야 한다. 하지만 setter보다는 생성자가 나은 것 같다.

성재
immutable 하지 않은 것 때문에 보통 setter를 쓰지 말라고 하는데 상황에 따라 쓰게 되는 경우가 있다. 생성자에서 필드가 많거나 할 때 빌더 패턴을 쓸 수도 있다.

주형
setter를 왜 안 쓸까 나도 생각해봤다. 데이터를 함부로 바꿀까봐 그런 듯 하다.

현식
다른 클래스에서 마구잡이로 setter를 쓰면 객체 상태를 파악하기 힘들어서 그런 것 같다.

주만
학부생 때 '캡슐화를 해도 어차피 접근 가능한데 왜 이게 은닉이지?' 하는 의심이 있었다. private으로 지정해놔도 어차피 setter로 접근할 수 있기 때문이다. 이렇게 쉽게 접근할 수 있기 때문에 setter를 두지 말라고 배웠던 것 같다.

현식
캡슐화의 핵심이 구현을 숨기는 건데 getter를 쓰는 것 자체가 그걸 해치는 것 같다. 무슨 변수를 쓰는지 다 알아야 하기 때문이다. 그래서 메소드로 상태 변화를 할 수 있게 교체하는 것이 좋다고 들었다.

주형
DDD 책을 보면 클래스 자체가 의미 있는 것이지 필드 하나하나를 다 가져오게 되면 도메인 지식을 해친다고 나와있다. 그래서 필드 하나에 대한 getter를 안 만드는 게 좋다고 한다.

현식
클래스를 구현하는 방식은 다양하다. 하지만 결국 사람이 읽어야 하는 것이기 때문에 관심사를 쪼개서 클래스를 작게 만드는 게 중요한 것 같다. 따라서 굳이 getter, setter를 쓰는 대신 메소드로 내부 상태를 바꾸게 하는 걸 선호한다. 메소드 이름에도 그 기능을 확실히 알 수 있게 명시한다.

빌더 패턴을 쓰는 것도 좋다. 생성자에 원하는 필드를 다 넣게 되면 생성자가 여러 개일 때 순서를 맞춰야 하고 가독성도 떨어진다. 이런 코드를 가독성 좋게 짤 수 있는 방법이 빌더 패턴이다.

생성자로 넣는 방식을 메소드로 따로 뺐다고 생각하면 될 듯 하다. 빌더를 쓰는 이유 중 하나는 immutability를 유지하기 위함이다. set은 상태가 바뀌는데 빌더는 새로운 객체를 만들어서 사용한다. 빌더 함수 안에서 new를 하기 때문에 상태를 지킬 수 있다. 빌더를 쓰면 유틸리티적인 기능도 넣을 수 있다.

유닛 테스트

테스트 단위의 범위

주만
유닛의 범위가 다양하다고는 하지만 거의 메소드로 돌아간다고 보면 된다.

TDD의 실효성

주만
테스트도 결국 코드다. 하다 보면 '굳이 짜야 되나' 라는 생각이 드는 상황도 많다.' 어차피 통과하는 게 당연한 코든데 왜 짜야 하나' 이런 생각이 든다. 공수가 너무 많이 드는 느낌. 다른 사람은 어떤지 궁금하다.

현식
같은 생각 많이 했는데 짜다 보니 테스트가 스펙이면서 시스템이 되는 느낌이 든다. 의존 관계 때문에 잘 되던 부분이 나중에는 테스트를 실패하는 경우가 있다. 다른 사람의 수정 사항 때문에 내가 영향을 받을 수 있기 때문에 하는 게 좋은 것 같다. 억지로 유닛 테스트를 깔끔하게 짜려고 하다보면 코드 질도 좋아지는 것 같다.

주만
tc를 먼저 짜고 개발을 하면 tc가 깨지고 다시 개발을 하고 이렇게 반복 되더라. 계속 많이 바꾸게 된다. 공수가 너무 많이 든다. 500줄을 개발하니까 너무 번거롭더라.

성재
테스트를 먼저 짜본 적은 없는데 테스트 코드의 의도만 맞추면 되는 것 같다. 코드가 엄청 길면 테스트를 짜야 한다고 생각한다. 바로 깨질 확률이 높기 때문이다. 의존성 등등을 다시 확인할 수 있는 기회다.

어느 새 '내가 기계적으로 코드를 위한 tc를 짜고 있구나. 의미 없는 테스트를 하는구나' 를 많이 느꼈다. 경험적으로 많이 느껴봐야 하는 것 같다.

현식
구글 개발자는 어떻게 테스트하는가 라는 책을 봤는데 전체 코딩 시간의 70%를 tc에 쓴다고 한다. 시간을 많이 쏟는 건 맞는 거 같다. tc를 먼저 짜는 건 엄청 엄격한 규칙인 것 같긴 하다.

준희
주만이 계속 고치게 되는 게 힘들다고 했는데, 그래도 tc를 하려고 했기 때문에 더 어디를 바꿔야 할지 알게 된 게 아닌가 생각한다.

주형
이번에 프론트 tc를 짜게 되었다. PR을 올려놓으면 세세하게 못 볼 때가 많은데 테스트가 그걸 다 잡아줘서 좋더라. 협업할 때 좋았다. 변화를 안 깨지게 하고 코드 품질이 좋아지는 듯 하다. 나도 tc 고치는 것에만 2/3를 쓴다.

테스트로는 테스팅 라이브러리 라는 걸 쓰고 있다. 겉으로 보이는 행동을 테스팅해서 빠르게 테스트가 가능하다.

근원
나도 주만님에 동의했다. 좀만 수정해도 다 깨지니까 의미가 있는 건가 생각이 들었다. 최대한 일부러 어려운 상황을 만들어서 테스트 하면서 만족해왔다.

그런데 준범이 권용근님의 어떻게 테스트 할 것인가 무엇을 테스트 할 것인가 강의를 추천해주더라. 준범이 인터페이스가 될 수 있는 부분을 잘 테스트해야 된다고도 조언했다. '내가 쐈을 때 뭐가 온다' 그런 부분에 집중한다고 한다.

주만
그래도 토비의 스프링은 정말 대단하다. tc에 대한 회의감이 컸는데 토비를 읽고 다시 해보려는 생각이 들었다. 정리 부분이 정말 주옥 같았다.

mocking

현식
앱에서 터치할 수 있는 부분은 다 눌러보는 '몽키 테스트'나 mock 서버라는 게 있다. mock 서버는 response만 정해놓고 cli로 request를 줘서 테스트한다.

주형
mock 서버의 귀찮은 점은 클라이언트가 바뀌면 json 양식 등 서버도 함께 바꿔줘야 한다는 것이다.

[junbeomlee]

재밌네요 ㅋㅋㅋ
주옥 같았다..

[hihiboss]

토픽별로 대화한 내용을 엮어서 책으로 내도 재밌을듯... ㅋㅋㅋ
감사합니다 도던님 :)

[ttkmw]

진짜 최곱니다 너무 좋네요! 감사합니다

[boohyunsik]

제가 투머치토커네요...