느끼는 건데..
제발 java랑 javascript 공부 좀 하자.. C python 해서 뭐할래
객체지향 프로그래밍도 더 깊게 공부해야 할 것 같다.
일에 바로 투입되지는 못하고.. 공부만 하고 있는 게 좀 죄송했다.
모두가 엄청 바쁘게 일 하는 상황에서 나만 1인분을 못하고 있었기 때문이다.
'로그인-앱 등록-펫 등록' 이 짧은 흐름 하나를 구현해놓고
피드백을 받아가며 여러 방식으로 고쳐나갔는데 뭘 하고 있는 건지 티도 안났다.
근데? 오늘 처음 구현했던 코드를 보고 지금 코드를 보니
실무 바로 들어가서 AI 써재꼈으면 진짜 큰일났겠다 싶었다!
일단 하루 30분 할애해서 코드 보면서 피드백 해주시고..
어떤 식으로 생각해야 하는지, 어떤 패키지들을 적용해볼 수 있는지 하나하나 짚어주시는 게
사실 자원을 엄청 쓰고 있다는 걸 알고 있어서 공부를 열심히 하려곤 했다.
근데 베이스가 너무 부족해서 힘들고 학습이 되긴 하는 건지 몰랐는데
좋은 코드가 어떤 건지 보는 눈과 짜임새 있게 코드를 구성하는 사고력이 생겨가는 것 같다.
물론 지금도 코드 쓰는 걸 버벅이고 생각의 흐름이 매끄럽지 못해 AI에게 많이 배우고 있지만..
진짜 뭣도 모르면서 AI에게 거의 모든 걸 맡겼던 내가 얼마나 잘못된 방식을 선택했는지 깨닫는다.
주니어 개발자 내 자신 화이팅...
오늘 한 내용
1. 레이어 구조 정리
- 전체 구조를 UI → Cubit → Repository → DataSource 로 명확히 분리
- UI에서 Repository를 직접 호출하던 부분 제거
- Cubit이 비즈니스 로직과 데이터 접근을 전담하도록 구조 개선
→ 상태관리·의존성·테스트 용이성이 크게 향상됨
2. 상태 클래스 개선
- 모든 상태 클래스를
sealed class + final class로 재구성 switch표현식 사용 가능- 모든 상태 분기를 컴파일 타임에 강제할 수 있어 안정성 확보
3. GoRouter 실험
- pageBuilder 방식: 부모 페이지(Page)가 실제로 생성되는 구조
- redirect 방식: 부모 페이지 없이 자식 경로로 곧바로 이동
- AI는 redirect 방식이 URL 구조·뒤로가기 스택에 유리하다는데 뭐가 더 좋은지는..
4. MainScreen 구조 정비
- 메인 화면을
StatefulWidget → StatelessWidget으로 변경 - 상태·데이터 로드를 담당하는 MainScreenCubit 신설
- 로그인 상태 변화에 따라 Cubit이 사용자·펫 데이터를 자동 재로딩
→ UI는 “상태만 읽는 구조”로 단순화됨
5. 자동 새로고침 로직 정비
1) 수동 refresh 방식 사용해봄
- 등록 완료 후 UI 쪽에서
refreshUser / refreshPets직접 호출 - print 디버깅으로 호출 시점·rebuild 문제 확인
2) Stream 기반 자동 동기화 사용해봄
- Repository에
StreamController.broadcast()추가 - 데이터 변경 시
stream.add(userId)로 이벤트 발행 - MainScreenCubit이 stream을
listen()하여
같은userId일 때 자동으로refreshUser / refreshPets실행 - 구독은
StreamSubscription으로 관리, Cubit close에서 취소
→ 수동 refresh 불필요, 화면 자동 동기화 완성
6. 사용자 정보 수정 플로우
- 메인 화면에 유저 정보 수정 버튼 추가
- 기존 등록 플로우(닉네임 등 입력 화면)를 수정 모드로 재사용
- 기존 데이터가 TextField에 자동 세팅
- 수정 완료 시 stream 이벤트 → 메인 자동 새로고침
7. 디버깅 및 개념 정리
- Repository stream과 흐름 이해
- Repository를 전역 Provider로 두는 이유:
- 의존성 주입
- Stream 공유
- 테스트 및 Mock 용이
피드백 받은 내용 한 번에 정리
1. 로딩/실패 상태 처리
- 새 데이터가 도착했을 때 Cubit이 로딩 중이거나 실패 상태라면 기존 데이터를 어떻게 유지/대체할지 타이밍을 고민해야 함
2. ReactiveX/Subject 개념
- 기본 Stream 외에
BehaviorSubject같은 RX 개념도 존재. 마지막 emit 값을 캐싱해 두고 새 구독자가 즉시 현재 상태를 알 수 있어 UI 초기화에 유리
3. sealed class 대안
- sealed class를 쓰지 않고
MainState.loading,MainState.success처럼 상태를 한 객체 안에 묶는 패턴도 있음 - 더 immutable하게 만들고 싶다면
freezed같은 코드 생성 패키지를 검토
4. 실제 API 콜 테스트
- 실제 REST API를 호출하는 플로우도 한번 테스트해 보자
- 간단한 서버를 띄우거나, 테스트용 HTTP 서비스를 이용해 보고, Retrofit 같은 REST 클라이언트도 경험해 보라고 권장
멋있는 사람이 되는 게 꿈입니다