우테코 안드 8기 "칸반 보드 태스크 - 컴포즈 기초" 리뷰 정리 2차

1차 리뷰에 이은 2차 리뷰, 3주? 전 내용인데 3주 전의 나와 지금의 나를 비교하니 많이 배우긴 한 것 같다는 생각이 든다. 이 당시에는 컴포넌트를 어디까지 분리해야 하는지 기준을 세우지 못했고 컴포넌트에 너무 많은 역할과 책임을 부여했었다. 물론, 지금이라고 완벽한 건 아니지만 어느 정도 기준은 세웠기 때문에 그 기준에 따르고 있다. 기억에 따르면 다음 리뷰에서 컴포넌트 분리 기준을 얘기할 것 같다.

PR: woowacourse/compose-kanban-board-task#1

리뷰어: ㅋㄹ

---

1. FlowRow 후속 답변

KanbanBoard.kt

• Q: 잘 찾아보셨습니다. 질문주신 부분은 제가 답변드리지 않아도 미션을 진행해나가면서 스스로 답을 찾으실 수 있을 것 같아요. Column이라는 컴포저블 함수가 있지만, LazyColumn이 또 있는 이유가 무엇일까요? Lazy는 왜 붙었을지 생각하며 차이점을 비교해보셔도 도움이 될 것 같아요.

  이 질문은 답변을 잊어버린 것 같다;; 지금이라도 답변해보자면, LazyColumn은 한번에 모두 로딩하지 않는다. 그래서 Lazy라 호칭한다고 생각한다. "게으른 칼럼"이기에 기존의 Column처럼 모든 요소를 한번에 로딩하는 게 아니라 필요할 때마다 로딩을 통해 요소를 가져온다. 보통, 구매 내역, 상품 목록 등이 이런 구조를 가지고 있다.

  이렇게, 많은 요소를 가지고 있는 칼럼을 한번에 로딩하려면 로딩하는 시간도 길 것이고 많은 컴포넌트를 한 번에 보여줘야하니까 성능적 문제도 생길 수 있다. 이 문제들을 LazyColumn을 통해 해결 할 수 있다.

---

2. emptyList() vs listOf() / tagList 기본값

KanbanBoard.kt

• Q: 이전 코멘트에 이어지는 내용인데, 내부 값이 없는 리스트를 만들 때는 listOf()보다는 emptyList()를 쓰는 것이 직관적으로 느껴지는데 어떻게 생각하시나요? 그리고 tagList만 기본 값을 지정해주는 이유는 무엇인가요?
• A: 내부 값이 없는 리스트를 만들 때에도 똑같이 listOf()를 사용한 이유는, emptyList()랑 동일한 기능을 하기 때문에 그대로 사용하였습니다. 그런데, 생각해보니 emptyList()를 사용하는 게 말씀하신대로 다른 사람이 보기에 더 이해가 쉬울 것 같습니다. 이전에 KanbanBoardCard에 @Preview가 설정되어 있을 때 tagList 이외에도 기본값을 설정해주었었는데 @Preview를 옮기면서 지우는 과정에 누락되었던 것 같습니다. 지우도록 하겠습니다.

---

3. 시스템 폰트 크기 설정 관련 후속

KanbanBoard.kt

• Q: 시스템 폰트 크기 설정에 따라 글씨 크기가 바뀌지 않아야 하는 이유가 무엇인가요? 사용자들은 앱에서도 자신이 사용하는 일반적인 글씨 크기를 원할겁니다. 이를 무시하고 고정된 크기로 보여준다면 사용에 이질감을 느끼지 않을까요?

이것도 답변을 잊었다. 지금은 어떤지 모르겠지만, 지인의 지인이 당근 개발자였는데 시스템 폰트 크기 설정을 고려하지 않기 위해 폰트 크기를 고정해놓고 UI를 짠다고 했다. 나도 현업에 있을 때 시스템 폰트 크기 설정 때문에 레이아웃이 어긋나서 문제가 되었던 적이 있는데 그 이후로 폰트 배율을 고정해놓고 작업했던 기억이 난다. 물론, 사용자는 설정한 시스템 폰트 크기대로 나오고 레이아웃도 그에 맞춰서 변형되는게 베스트 케이스겠지만, 그 당시에는 시간이 부족해서 그렇게 작업했었다.

---

4. Preview만으로 개발한 것에 대해

README.md

• Q: 현재 앱을 실행하면 기본 화면인 Click Me만 보이고 있습니다. 단순히 Preview만을 보면서 개발하셨던건가요?
• A: 맞습니다. Preview만 보면서 개발하였습니다. 실제로 실행가능하여야 한다는 언급이 없어서 그대로 놓아두었습니다. 2단계 제출 때 수정하여 실행해서도 보일 수 있도록 만들겠습니다.

---

5. 함수 책임 분리

KanbanBoard.kt

• Q: 하나의 함수가 너무 많은 일을 하고 있다고 느껴지진 않나요? 적절한 책임을 부여해서 함수를 나눠본다면 어떤 장점이 있을까요?
• A: KanbanBoardCard 안에 제목, 내용, 태그 로우(CustomChip), 수평구분선, 담당자 정보 로우(아이콘, 담당자명)를 포함하고 있어 작은 함수는 아니라고 생각합니다. 만약 여기에서 더 분리한다면 태그 로우와 담당자 정보 로우를 분리하겠습니다.
  • 여기에서 의문이 드는 점: 제목과 내용 같은 경우에는 하나의 Text 컴포넌트로 표시하고 있습니다. 이렇게 하나의 자식을 가진 요소도 분리하는 게 맞을까요? 저라면 제목이나 내용 정도는 놓을 것 같습니다.
  • 적절한 책임을 부여해서 함수를 나누면 재사용성이 생기고 변경범위가 줄어들 것 같습니다. 다른 컴포넌트를 생성했을 때 재사용할 수 있을 것이고 변경범위 축소는 KanbanBoardCard 함수를 전부 읽지 않고 해당 컴포넌트만 확인하고 수정하면 되어서 편의성이 올라갈 거라 생각합니다.

---

6. Composable의 관심사 / 태그 제한 로직

KanbanBoard.kt

• Q: 태그는 5개까지 글자 수는 5글자까지 라는 제한을 함수 내부에서 직접 진행하고 있는데요. Composable의 관심사는 어디까지라고 생각하시나요? 화면에 따라 태그를 다르게 보여줘야 한다면, 글자 수를 변경해야 한다면 어떻게 대응할 수 있을까요? 변화를 가장 줄이면서 대응하는 방법은 어떤 것들이 있을까요?
• A: 아래와 같이 정리했습니다.
  • Composable의 관심사: UI 처리에만 한정해야 한다고 생각합니다. 즉, 레이아웃, 스타일링 등이라고 생각합니다. 코드에서 5글자 제한을 substring을 통해서 처리하고 있는데 이러한 처리는 컴포저블의 관심사 밖이라고 생각합니다. KanbanBoardCardData 처럼 도메인 모델에 분리하는 게 맞다고 생각합니다.
  • 화면별 대응: 도메인 모델에 글자 수 제한 로직을 분리하고 글자 수 제한을 매개변수로 받아 출력되는 글자 수를 바꾸도록.
  • 변화 최소화: 분리라고 생각합니다. 컴포넌트 함수가 너무 커서 분리하였고, 이 분리를 통해서 변경범위를 줄일 수 있으리라고 생각합니다.

---

7. KanbanCardData와 KanbanBoardCard 파라미터 일치

KanbanCardData.kt

• Q: KanbanBoardCard 함수가 받는 파라미터들과 정확히 일치하네요.
• A: 맞습니다. 어떻게 하면 좀 더 깔끔해 보일지 고민하다가 KanbanCardData로 변경하였습니다. 혹시 이와 같은 경우에는 굳이 class로 분리하지 않는 게 맞을까요?

---

8. data class 선택 이유

KanbanCardData.kt

• Q: data class를 선택한 이유는 무엇인가요?
• A: 단순하게 매개변수를 묶는 용도로 사용하고 있기 때문에 데이터 구조화와 전달에 최적화된 클래스인 data class를 사용하는 게 맞다고 생각했습니다. 현 시점에서는 데이터 구조화 이외에도 비즈니스 로직을 담고 있기 때문에 data class가 아닌 class로 수정했습니다.

---

9. Preview 가시성

KanbanBoard.kt

• Q: Preview는 외부에서 사용되나요? 외부에서 사용하지 않는 친구들의 가시성은 어떻게 해줘야할까요?
• A: 외부에서 사용하지 않고 해당 범위에서만 사용하기 때문에 private 가시성을 붙이는 게 맞다고 생각이 듭니다. private나 public을 잘 사용하지 않다보니 아직 손에 익지 않아 빠뜨렸네요. 유념하겠습니다.