✍️ 일주일 회고

[일주일 회고] 5월 2주 차 (2일 ~ 10일) + 감사한 글쓰기 모임

유정주 2024. 5. 8. 19:23
반응형

한 일 (2일 ~ 7일)

홈 화면 카테고리, 도전기록 리스트 표시

잘한 점

리스트를 표시할 때 CompositionalLayout Enum을 정의하여 작성했어요. (관련 PR)

CompositionalLayout은 item, group, section이 필요하고, 각 요소에 각각의 속성을 설정해야 합니다.

기존에는 각 속성들을 모두 파라미터로 전달받아서 메서드가 비대하다는 문제가 있었습니다.

이를 개선하기 위해 고민했고, 각 요소를 구조체로 정의하면 객체의 역할과 의미가 명확해지고 편의성도 챙길 수 있었습니다.

기존 코드에서 불편한 점을 느끼고 개선했다는 점에서 moti 2.0의 목표를 조금씩 이루고 있는 거 같아 기분이 좋네요.

 

아쉬운 점

코드가 아직 만족스러울 정도로 깔끔하진 않은 거 같아요.

예를 들어,

let item = CompositionalLayoutItem(
    size: itemSize,
    contentInsets: NSDirectionalEdgeInsets(top: inset, leading: inset, bottom: inset, trailing: inset)
)

이 코드에서 contentInsets로 전달하는 객체가 너무 길죠?

이런 경우 Constant로 빼도 좋지 않을까 생각이 들었습니다. 최소한 별도의 변수로 빼면 가독성이 좋아질 거 같아요.

아직 개인 프로젝트에는 Constant 처리가 부족하다고 느꼈어요.

 

개선 방향

- 아쉬운 점 수정하기

- 전체적으로 한 번 더 검토하기

 

직접 느낀 ViewModel의 InputOutput 패턴의 장점

잘한 점

테스트를 작성하면서 ViewModel의 InputOutput 패턴 장점을 느끼고 있습니다.

테스트 메서드를 input, output을 기준으로 작성하면 ViewController가 무엇을 input 했을 때 ViewModel이 무엇을 output 하는지 구현부도 상상이 가능했습니다.

또한, 입력과 출력이 명확하니 테스트의 통과 조건도 명확해지고, 테스트의 구조도 일관성 있어진다는 것을 느꼈습니다.

이론으로만 간접적으로 알았던 InputOutput 패턴의 장점을 직접 느낄 수 있어 뿌듯했습니다.

 

아쉬운 점

아직 input과 output에 어떤 개념이 들어가야할지 확립되지 않았어요.

예를 들어, input에는 반드시 동작(viewDidLoad, selectedItem 등)만 들어가야 하는 건지? output에는 명사나 Bool만 들어가야 하는 건지? 다른 게 들어가도 되는 건지 등 Input과 Output subject를 추가할 때마다 고민하는 거 같아요.

개념 공부로 확립이 가능한 영역인지, 경험이 쌓여야 하는건지 애매하지만 최선을 다해 고민하고 적용해보려고 해요.

 

개선 방향

- 고생하면서 배우는 디자인 패턴

- InputOutput을 쓴 외부 깃허브 레파지토리 염탐하기

- 테스트 코드를 작성하면서 어색한 점이 느껴진다면 메모하기

 

직접 느낀 테스트 자동화의 장점

잘한 점

이번 주 개발 과정에서 프로젝트 전역에 수정사항이 생긴 작업이 있었습니다.

이미 관련된 테스트가 있었기 때문에 든든한 마음이 들었습니다.

기존에는 앱을 하나하나 동작시키면서 잘 돌아가는지 확인해야 했는데요.

테스트 코드가 작성되어 있으니 딸깍 한 번이면 관련 로직을 모두 확인할 수 있었습니다.

테스트와 테스트 자동화의 장점을 직접 느끼니 테스트 작성의 동기 부여가 확실히 되었어요.

 

아쉬운 점

의미 있는 테스트 코드를 작성하기 위해 고민하고 있습니다.

그런데 어렵네요.

예를 들어, 현재 UseCase의 역할은 Repository의 데이터를 ViewModel로 전달하기만 하는데요.

UseCase에 RepositoryStub을 주입하니 단순 return 테스트가 되었어요.

이런 테스트는 과연 의미가 있는 것일까 고민이 되었습니다.

아직 마땅한 결론을 못 내린 점이 아쉬웠어요. (함부로 결론을 내리는 것도 위험하지만요.)

UseCase 내부에 특별한 로직이 생긴다면 의미가 생기겠지만, 그러면 그때 쓰면 되는 거 아닌가 라는 생각도 들고..

작업을 할 때 테스트도 함께 작성하는게 좋다는 생각도 들고 복합적인 생각이 드네요.

 

개선 방향

- 꾸준히 고민하기

- 개발 과정에서 테스트 관련 느낀 점을 PR에 기록하기 (note Label 할당)

 

깃허브 Note Label 생성

잘한 점

PR에 고민 과정을 작성하고 있습니다.

나중에 이 고민 기록을 쉽게 찾기 위해 note라는 Label을 생성하여 할당하고 있습니다.

지금 이순간 회고를 작성할 때 너무 큰 도움이 되고 있어요.

원래 잘한 점으로 쓸 계획이 없었는데 충동적으로 추가하여 작성합니다 👍

 

개선 방향

- 관성적으로만 작업하지 말고 꾸준히 발전하기 위해 생각하기

 

 

할 일 (8일 ~ 10일)

JDCornerRadius 적용

내용

개인 프로젝트의 cornerRadius 일관성을 위해 JDCornerRadius를 정의하여 사용할 예정입니다.

small, medium, large 세 가지 case를 정의하고, View가 쉽게 적용할 수 있도록 extension 메서드를 구현할 계획입니다.

 

최소 목표

JDCornerRadius 정의하기

moti 2.0에 JDCornerRadius 적용하기

 

최대 목표

View가 쉽게 적용할 수 있도록 메서드, extension 구현하기

 

Firebase 회원가입, 로그인 구현

내용

Firebase로 애플 로그인을 할 수 있도록 구현합니다.

 

최소 목표

Firebase로 애플 로그인 연동하기

 

최대 목표

신규 유저가 회원가입하면 기본 카테고리를 생성하도록 구현하기

 

Firebase 카테고리 저장

내용

Firebase로 애플 로그인 후 카테고리를 추가하면 정해진 구조로 데이터가 쌓이도록 구현합니다.

 

최대 목표

카테고리가 정해진 구조로 쌓이도록 구현

 

TMI. 감사한 글쓰기 모임

이번 주에는 글쓰기 모임에서 10번 째 글을 썼습니다.

1월부터 지금까지... 얼마 안 지났다고 생각했는데 벌써 10개의 글을 썼네요.

하나하나 즐겁게 작성했던 거 같아요.

바쁘고 힘든 회사 생활에서 꾸준히 즐겁게 해주는 활동입니다.

입사하자마자 모임에 초대해준 동료분, 반갑게 환영해준 동료들, 그리고 덥썩 문 저에게 참 감사한 날입니다.

 

감사합니다.

반응형