[1단계 - 사다리 생성] 에버(손채영) 미션 제출합니다. #316

helenason · 2024-02-22T08:29:20Z

안녕하세요 알렉스!
페어 트레와 사다리 생성 미션을 진행하게 된 에버 입니다. 😁

저희는 TDD 방식을 처음 접해보아서 사이클을 정확히 지켜가며 페어 프로그래밍을 진행해보았습니다.

저와 페어 간 의견을 조율하는 과정에서 리뷰어님의 생각이 궁금했던 부분이 있었습니다.

컨트롤러에서 현재는 뷰만을 파라미터로 주입 받고 있는데, 나머지 두 객체도 인자를 통해 주입받는 게 좋을까?
- GameController 파일에서 InputView와 OutputView를 파라미터로 받아 인스턴스 변수에 저장합니다. 컨트롤러와 뷰는 상관관계가 있다고 생각하여 의존성을 주입하는 형태로 구현하였지만, 이 외에 ErrorHandler 객체에 대해서는 컨트롤러 내에서 새로 객체를 생성하여 저장하도록 구현하였습니다. 사실 두 경우의 큰 차이를 아직 잘 모르겠고, 이 경우 리뷰어님은 어떤 방식의 스타일을 선호하는지 궁금합니다.
뷰와 메시지 리졸버의 역할은 구분하는 것이 좋을까?
- OutputView의 역할을 줄이기 위해 메시지를 출력 형태로 가공하는 리졸버 클래스 MessageResolver를 추가로 생성하였습니다. 역할 분리와 중요 데이터 전달 최소화를 위해 리졸버를 생성하자는 의견과, 해당 역할을 뷰에 부여해도 괜찮을 것이라는 의견이 있었습니다. 이에 대한 리뷰어님의 생각이 궁금합니다.
변환과 검증 로직을 분리해야할까?
```
public Height(String rawValue) {
    this.value = validateNonNumeric(rawValue);
    validateRange(value);
}

private int validateNonNumeric(String rawValue) {
    try {
        return Integer.parseInt(rawValue);
    } catch (NumberFormatException e) {
        throw new IllegalArgumentException("숫자를 입력해 주세요.");
    }
}
```
Height 클래스에서 문자열->정수 변환 작업과 정수 형태가 맞는지 검증하는 로직을 하나의 메서드에 담았습니다. 하지만 이러한 경우 validate의 역할을 갖는 메서드가 변환 및 반환의 역할까지 갖게 되어 역할을 제대로 분배하지 않은 것 같다고 생각됩니다. 변환 및 반환의 역할을 다른 메서드로 분리를 하려고 하였지만 명료하게 두 역할을 나누기도 어려웠습니다. 이 경우,
```
public Height(String rawValue) {
    validateNonNumeric(rawValue);
    validateRange(Integer.parseInt(rawValue));
    this.value = Integer.parseInt(rawValue);
}

private void validateNonNumeric(String rawValue) {
    try {
        Integer.parseInt(rawValue);
    } catch (NumberFormatException e) {
        throw new IllegalArgumentException("숫자를 입력해 주세요.");
    }
}
```
다음과 같이 문자열→정수 변환 로직을 중복으로 사용하여 변환과 검증 로직 분리가 가능합니다.

중복이라는 단점을 감수하고 역할을 분리하는 쪽이 합리적인지, 다중 역할을 갖더라도 중복을 최소화하는 것이 합리적인지 리뷰어님의 생각이 궁금합니다!
사다리에서 Point.CONNECTED가 연속으로 두 번 나오는 경우 에러를 출력한다.의 경우에 대해서 검증 로직 및 테스트 코드를 만들어야 할까?
- 이미 코드에서 왼쪽이 CONNECTED인 경우 오른쪽은 DISCONNECTED로 할당되도록 구현해두었으니 불필요하다는 의견과, 그래도 한 번 더 검증해야한다는 의견이 충돌하였습니다. 이 또한 리뷰어님의 생각이 궁금합니다!

감사합니다 알렉스! 가감없이 리뷰해주세요 😊

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

Co-authored-by: takoyakimchi <c4nyou결@gmail.com>

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

yxxnghwan

안녕하세요 에버! 사다리 미션 리뷰하게 된 알렉스입니다!
미션 구현하시느라 수고 많으셨습니다. 많은 고민을 하신 것 같네요!
생각해볼만한 부분들 코멘트 남겼으니 확인해보시고 다시 고민해보면 어떨까 싶습니다!

질문 답변

컨트롤러에서 현재는 뷰만을 파라미터로 주입 받고 있는데, 나머지 두 객체도 인자를 통해 주입받는 게 좋을까?

ErrorHandler의 범위에 따라 역할이 다를 것 같아요. 정의하신 역할이 에러를 캐치해서 뷰에 적절한 에러 형태로 전송하는 역할이라면 View와 같은 레벨인 클래스로 보입니다.

뷰와 메시지 리졸버의 역할은 구분하는 것이 좋을까?

리뷰 코멘트들 확인해보시고 코드 수정해본 후에 다시 고민해보시면 어떨까 싶어요!

변환과 검증 로직을 분리해야할까?

위 답변과 마찬가지로 코멘트들 확인해주세요 🙂

다리에서 Point.CONNECTED가 연속으로 두 번 나오는 경우 에러를 출력한다.의 경우에 대해서 검증 로직 및 테스트 코드를 만들어야 할까?

CONNECTED가 연속인 경우는 무결성이 해쳐지는 케이스네요! 어느 클래스 입장에서 무결성이 해쳐진 것인지 생각해보면 어디에 어떤 식으로 테스트 코드를 추가해볼지 생각해볼 수 있을 것 같아요!

src/main/java/controller/GameController.java

src/main/java/view/MessageResolver.java

src/main/java/domain/Point.java

src/main/java/domain/Height.java

src/main/java/domain/Line.java

src/main/java/domain/Lines.java

src/main/java/domain/Members.java

helenason · 2024-02-24T16:48:54Z

좋은 리뷰 감사합니다 알렉스! ☺️

알렉스의 피드백 반영하여 코드 수정해보았어요.

하지만 여전히 알렉스의 의견이 궁금한 부분이 있어 추가로 코멘트 달아두었습니다.

또한 무결성을 해치는 테스트 케이스인 'CONNECTED가 연속으로 나오는 경우'를 테스트할 방법을 아직 찾지 못하였습니다..🥹

테스트할 수 있다면 더할 나위 없이 좋은 코드이지만,
일단은 비즈니스 로직을 통해 거를 수 있는 케이스이기 때문에
방법을 찾지 못한 채 다시 리뷰 요청 드립니다 😭😭

혹시 알렉스에게 관련 의견이 있다면 언급 부탁드려요!

감사합니다!

yxxnghwan

안녕하세요 에버! 수정할 부분이 많았을 텐데 리뷰 반영 잘 해주셨네요!
질문주신 부분들은 최대한 코멘트로 답변 달아봤는데 확인 부탁드리고 이해가 안가는 부분이 있다면 언제든 슬랙으로 DM 주셔도 좋습니다!

무결성을 해치는 테스트 케이스인 'CONNECTED가 연속으로 나오는 경우'를 테스트할 방법을 아직 찾지 못하였습니다..🥹

현재 Line의 생성자에서 이전 이 CONNECTED면 고정으로 UNCONNECTED 아니면 랜덤뽑기 하는 로직이 있는걸로 보여요! 이부분을 바깥으로 빼보면 어떨까요? Line에선 CONNECTED가 연속으로 들어왔는지에 대한 검증만 해볼 수 있지 않을까요?

개인적으론 꼭 테스트하지 않아도 된다고 생각하긴 합니다! 연속으로 CONNECTED가 절대 생성되지 않는다 정도만 테스트해도 괜찮다고 생각해요!

테스트 하는 방법에 대한 힌트는 고민해보시면 좋을 것 같고, 반영할지 말지는 에버의 생각을 주로 해서 결론내보면 좋을 것 같아요! 아직 이 PR에서 고민해보면 좋을 것들이 남아있는 것 같고, 미션 시간도 많이 남은 것 같아서 한번 더 RC드릴게요! 💪

src/main/java/controller/GameController.java

yxxnghwan · 2024-02-25T06:51:32Z

src/main/java/controller/GameController.java

+    private String requestNames() {
+        return inputView.readNames();
+    }
+
+    private Members makeMembers(String rawNames) {
+        return new Members(rawNames);
+    }
+
+    private String requestHeight() {
+        return inputView.readHeight();
+    }


꼭 필요한 메소드 분리일까요?

이전에 주셨던 코멘트가
메서드 분리를 의도하신 것이라고 판단하였습니다.

다른 방법을 고민해보겠습니다!

알렉스가 주신 코멘트 두가지를 정리하면 아래와 같습니다!

하나의 메서드가 입력 로직과 객체 생성 로직 두가지를 수행하는 것은 역할이 많다.

각각을 메서드로 분리하는 작업이 꼭 필요할까?

제가 역할을 분리하기 위해 선택했던 방법이 메서드 분리였습니다.
메서드를 분리하지 않고 역할을 분리하는 방법은 찾지 못하였습니다..

메서드 분리가 아닌 방법으로 어떻게 역할을 분리할 수 있는지 궁금합니다! 🥹

이전 메소드는 입력 + Members생성까지 같이 한다고 생각해서 많은 역할을 가진다고 생각했던 것 같아요!
이번 케이스에선 new Members()라는 코드 한줄을 호출하는데 굳이 makeMembers라는 함수가 필요할까란 생각이 드네요!
생성자 자체로도 이미 Members를 생성하는 로직인게 잘 드러나는 것 같아서요! 메소드로 래핑하지 않고 그냥 바로 생성자를 호출하지 않은 이유는 무엇인가요?

사실 이유가 없었습니다..
메서드의 역할이 많다는 알렉스의 코멘트를 제 나름대로 반영하려고 하다보니
오히려 더 좋지 않은 구조의 코드가 된 것 같아요 ㅠㅠ
다른 방법을 더 고민해보겠습니다! 🥲

src/main/java/domain/Connection.java

src/main/java/domain/Game.java

src/main/java/view/MessageResolver.java

src/main/java/domain/Line.java

src/main/java/domain/Lines.java

yxxnghwan · 2024-02-25T07:08:26Z

src/main/java/view/MessageResolver.java

+        return stringBuilder.toString();
+    }
+
+    public String resolveLines(Lines ladder) {


변수명과 타입이 매치가 안되는 것 같아요! 의도하신 부분일까요?

해당 메서드가 Lines 클래스에서 lines 변수를 꺼내와야 하는 상황이라,
변수명 중복을 피하기 위해 ladder 라는 이름을 사용하였습니다!

src/main/java/domain/Line.java

yxxnghwan · 2024-02-25T07:18:46Z

src/main/java/domain/Line.java

+
+public class Line {
+
+    private final List<Connection> points = new ArrayList<>();


변수 이름도 변경되어야하지 않을까요?

PointStrategy와 RandomPointStrategy 클래스가 존재하여
변수명은 points로 유지하자는 생각으로 변경하지 않았습니다.

하지만 지금 다시 생각해보니 두 단어를 혼용하는 것은 혼돈만 줄 것 같네요..
관련 클래스 및 변수명 모두 Connection 단어를 사용하도록 수정하겠습니다!

helenason · 2024-02-25T18:57:33Z

연속으로 CONNECTED가 절대 생성되지 않는다 정도만 테스트해도 괜찮다고 생각해요!

위 테스트를 작성하면 무결성이 100% 보장됨을 확인시킬 수 있네요...!
관련 테스트를 추가하는 방향으로 결정하였습니다.

연속으로 CONNECTED가 나오는 경우를 테스트하는 방법은
알렉스가 주신 힌트를 바탕으로 계속 고민해볼게요!

피드백 바탕으로 코드 수정하였습니다.
혹시 더 수정이 필요하다 생각되시면 얼마든지 RC 주세요! 😊

yxxnghwan

안녕하세요 에버! 늦은시간까지 리뷰 반영해주셨네요! 고생 많으셨습니다!🙂
1단계 진행하시면서 충분히 많은 부분들을 고민하신 것 같습니다!
간단한 코멘트 몇 가지 남겼고 다음 단계에서 반영해주시면 될 것 같아서 이만 머지하도록 할게요!
다음 단계도 화이팅입니다!💪

yxxnghwan · 2024-02-26T15:45:54Z

src/main/java/controller/GameController.java

+    private Members makeMembers() {
+        return errorHandler.readUntilNoError(() -> {
+            String rawNames = inputView.readNames();
+            return Members.from(rawNames);
+        });
+    }


입력 + Members 생성까지 해서 너무 많은 역할을 한다고 피드백 드렸었는데, 이번엔 메소드 역할에 에러 핸들링까지 추가되었어요!
어떻게 변경해보면 좋을까요?

yxxnghwan · 2024-02-26T15:51:23Z

src/main/java/domain/Height.java

+public class Height {
+


테스트에서만 사용하는 클래스가 되었네요! 이제 안쓰는 클래스일까요?

리팩토링하는 과정에서 Height 클래스 내의 로직들을 외부로 넘기다보니 무의미한 클래스가 되어버렸네요...
해당 클래스는 삭제했습니다!

yxxnghwan · 2024-02-26T15:54:56Z

src/main/java/domain/Members.java

+    }
+
+    public static Members from(String rawNames) {
+        List<String> names = StringParser.splitByDelimiter(rawNames, DELIMITER);


이 객체의 역할이 맞을까요? input이 ,으로 split할 수 있는 형태로 들어온다는건 어떤 객체의 책임이 적절할까요?
현재는 만약 UI가 console 이 아니라 Web이고 각 이름을 개행으로 구분해서 입력한다면 이 도메인까지 수정되어야 할 것 같은데, view와 비즈니스 로직이 분리되었다고 볼 수 있을까요?

헉 그러네요. 구분자가 변경될 경우 Members 클래스가 수정되어야하는 상황이 발생하네요.
그렇다면 도메인보다는 컨트롤러의 책임이라고 생각됩니다.
생각 반영하여 코드 수정하겠습니다!

yxxnghwan · 2024-02-26T15:56:28Z

src/main/java/domain/Members.java

+    private static List<Member> makeMembers(List<String> names) {
+        List<Member> members = new ArrayList<>();
+        names.forEach(name -> members.add(new Member(name)));
+        return members;
+    }


Suggested change

private static List<Member> makeMembers(List<String> names) {

List<Member> members = new ArrayList<>();

names.forEach(name -> members.add(new Member(name)));

return members;

}

private static List<Member> makeMembers(List<String> names) {

return names.stream()

.map(Member::new)

.toList();

}

yxxnghwan · 2024-02-26T16:00:05Z

src/main/java/strategy/RandomConnectionStrategy.java

+        return Connection.DISCONNECTED;
+    }
+}


파일 끝에 개행이 빠졌네요! EOF!

yxxnghwan · 2024-02-26T16:03:15Z

src/test/java/domain/NameTest.java

+    void test_exception_moreThanFiveLetters(String name) {
+        assertThatThrownBy(() -> new Name(name))
+                .isInstanceOf(IllegalArgumentException.class)
+                .hasMessageContaining("자의 이름만 허용합니다.");


에러 메시지도 검증하고 계시네요! 메시지를 검증할 때 문구보단 몇자 이하로 들어와야하는 지가 잘 노출되는게 좀 더 중요하지 않을까요?

알렉스 의견에 동의합니다! 제가 놓친 것 같아요.
앞으로는 더욱 꼼꼼히 체크해야겠네요. 감사합니다!

helenason and others added 30 commits February 20, 2024 14:24

docs: 구현할 기능 요구사항 작성

88b71e0

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

docs: 참여자 이름 관련 요구사항 수정

63efb03

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

test: 참여자 이름 테스트 코드 작성

d6d3437

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

test: 비어있는 이름에 대한 에러메시지 수정 및 문법 관련 에러 해결

b9ae327

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 참여자 이름 도메인 생성

50bb66e

Co-authored-by: takoyakimchi <c4nyou결@gmail.com>

test: 참여자들 테스트 코드 작성

dba6496

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

test: 참여자 테스트 코드 작성

2460723

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 멤버 도메인 생성

df6505e

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 참여자 이름 가져오는 메서드 추가

dbb5bf6

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

test: 참여자들 테스트 null 입력하는 경우 추가 및 에러 메시지 검증 제외

d862bce

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 참여자들 도메인 생성

960163e

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

test: 가로줄 테스트 코드 작성

7f82f81

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 가로줄 도메인 및 가로줄 생성을 위한 전략 인터페이스 생성

afd6d85

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

test: 가로줄 테스트 도메인에 맞게 수정

6f309ff

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

test: 사다리 높이 도메인 테스트 코드 작성

b902809

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 사다리 높이 도메인 생성

63aff0e

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

test: 사다리 전체 도메인 테스트 코드 작성

6ed33af

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 사다리 전체 도메인 생성

7a2b7f4

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 사다리 높이 도메인 getter 추가

b9fc1f8

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

test: 사다리 전체 도메인에 맞게 수정

8fd9449

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: view 클래스 생성

e8d008c

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 출력 로직 구현

416a256

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 참여자들 도메인에 데이터 반환 메서드 추가

1215174

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 게임 실행 도메인 생성

e198c19

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 컨트롤러 생성

bd00b5d

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: main 메서드 생성

4cd2c8c

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

style: 공백 정리

fec15a1

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 에러 발생 시 재입력받는 로직 추가

2917f27

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

refactor: 출력 문자열 개행 제거

8bd7344

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

feat: 사다리 연결 여부 Enum 클래스 구현

a8b502e

Co-authored-by: takoyakimchi <c4nyou@gmail.com>

helenason changed the title ~~[1단계 - 사다리 게임 구현] 에버(손채영) 미션 제출합니다.~~ [1단계 - 사다리 생성] 에버(손채영) 미션 제출합니다. Feb 22, 2024

yxxnghwan requested changes Feb 23, 2024

View reviewed changes

takoyakimchi mentioned this pull request Feb 24, 2024

[1단계 - 사다리 생성] 트레(이충렬) 미션 제출합니다. #317

Merged

helenason added 10 commits February 24, 2024 21:33

refactor: String 덧셈 연산 StringBuilder 사용하여 불필요한 객체 생성 과정 제거

9dd66ca

refactor: 사용하고 있지 않은 isConnected 변수 제거

7c79b51

refactor: 사다리의 연결 상태를 나타내는 클래스 직관적인 이름으로 변경

bb9e0cc

refactor: 다음 포인트의 연결 여부를 생성하는 메서드 연결 클래스로 역할 분리

f22fe8a

refactor: 문자열 가공 역할 StringParser 클래스로 분리

057fd7a

refactor: 컨트롤러의 파라미터를 통해 에러 핸들러 주입

44fa207

refactor: 이름 입력 역할과 객체 생성 역할 다른 메서드로 분리

1a91b97

refactor: Height 객체가 해당 객체를 사용하는 객체 내부에서 생성되도록 수정 및 파싱 로직 책임을 외부로 이전

d4efe94

style: 불필요한 공백 제거

c4e12b4

refactor: 사다리 연결 여부와 출력 형태 매칭 로직을 리졸버로 이동

24a26bd

yxxnghwan requested changes Feb 25, 2024

View reviewed changes

helenason added 11 commits February 26, 2024 00:42

refactor: MessageResolver 클래스 OutputView로 통합

011baed

style: 불필요한 주석 제거

84619c4

refactor: 출력되는 문자열 상수로 처리

cb3e036

refactor: 테스트에서의 재사용을 위해 상수의 접근제어자 변경

fdff455

test: 도메인 생성 실패의 경우 에러메시지 검증 로직 추가

5183c25

refactor: point와 connection 혼용하던 방식 connection으로 통일

74b7287

refactor: 메서드의 길이를 줄이기 위해 추가 메서드로 분리

25dbd20

test: 절대 연속으로 사다리가 연결될 수 없음을 확인하는 테스트 추가

7abb36c

refactor: Lines 클래스 정적 팩토리 메서드 도입

a076bae

refactor: Members 클래스 정적 팩토리 메서드 도입

c4ae098

refactor: Line 클래스 정적 팩토리 메서드 도입

332b757

yxxnghwan approved these changes Feb 26, 2024

View reviewed changes

yxxnghwan merged commit 654d675 into woowacourse:helenason Feb 26, 2024

helenason mentioned this pull request Mar 1, 2024

[2단계 - 사다리 게임] 에버(손채영) 미션 제출합니다. #408

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[1단계 - 사다리 생성] 에버(손채영) 미션 제출합니다. #316

[1단계 - 사다리 생성] 에버(손채영) 미션 제출합니다. #316

helenason commented Feb 22, 2024 •

edited

Loading

yxxnghwan left a comment •

edited

Loading

helenason commented Feb 24, 2024 •

edited

Loading

yxxnghwan left a comment

yxxnghwan Feb 25, 2024

helenason Feb 25, 2024 •

edited

Loading

helenason Feb 25, 2024 •

edited

Loading

yxxnghwan Feb 26, 2024

helenason Mar 1, 2024

yxxnghwan Feb 25, 2024

helenason Feb 25, 2024

yxxnghwan Feb 25, 2024

helenason Feb 25, 2024

helenason commented Feb 25, 2024

yxxnghwan left a comment

yxxnghwan Feb 26, 2024

yxxnghwan Feb 26, 2024

helenason Feb 29, 2024 •

edited

Loading

yxxnghwan Feb 26, 2024

helenason Feb 27, 2024

yxxnghwan Feb 26, 2024

yxxnghwan Feb 26, 2024

yxxnghwan Feb 26, 2024

helenason Feb 29, 2024


		public class Line {

		private final List<Connection> points = new ArrayList<>();

[1단계 - 사다리 생성] 에버(손채영) 미션 제출합니다. #316

[1단계 - 사다리 생성] 에버(손채영) 미션 제출합니다. #316

Conversation

helenason commented Feb 22, 2024 • edited Loading

yxxnghwan left a comment • edited Loading

Choose a reason for hiding this comment

질문 답변

helenason commented Feb 24, 2024 • edited Loading

yxxnghwan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

helenason Feb 25, 2024 • edited Loading

Choose a reason for hiding this comment

helenason Feb 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

helenason commented Feb 25, 2024

yxxnghwan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

helenason Feb 29, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

helenason commented Feb 22, 2024 •

edited

Loading

yxxnghwan left a comment •

edited

Loading

helenason commented Feb 24, 2024 •

edited

Loading

helenason Feb 25, 2024 •

edited

Loading

helenason Feb 25, 2024 •

edited

Loading

helenason Feb 29, 2024 •

edited

Loading