[3주차/필수과제] 컴포넌트화 및 UI단 설계를 진행한 내용을 적어주세요.

[jihyunniiii]

🎤 토론 과제 - 컴포넌트화 및 UI단 설계를 진행한 내용을 적어주세요.

𝟏. 컴포넌트화 및 UI단 설계를 진행하며 고민한 내용들을 정리해서 남겨주세요.
(노션 및 다른 툴을 이용해서 정리한 후 링크를 첨부하는 것을 추천드립니다.)

𝟐. 컴포넌트화 및 UI단 설계를 진행하며 느낀점 및 어려웠던 점을 공유해주세요.
(어떻게 해결했는지까지 적어주시면 좋습니다.)

[HAJIEUN02]

컴포넌트화 및 UI단 설계

🍄3차 과제 정리

느낀 점

어디까지 컴포넌트로 만들고 어디까지 따로 패키지 분리를 해야 하는지 고민이 되었습니다. 한 Screen에서만 쓰이는 컴포넌트라면 내부에서 컴포저블 함수를 분리하고, 여러 Screen에서 쓰이는 컴포넌트라면 분리된 컴포넌트 패키지에 넣어두는 것으로 생각하고 설계를 시작했습니다. 하지만 2개의 Screen에서 쓰이지만 총 2번만 사용되는 컴포넌트와 1개의 Screen에서 쓰이지만 총 3번 쓰이는 컴포넌트가 있었습니다. 여러 개의 Screen에서 쓰이는 컴포넌트와 단순히 많이 쓰이는 컴포넌트들의 중요성을 어떻게 따져야 할지, 패키지 구조를 어떤 식으로 해야 효율적일지 고민했습니다.
컴포넌트의 의미에 대해 고민한 결과, 1개의 Screen에 종속되어 있으면 다른 Screen에서 해당 컴포넌트를 호출할 때 찾아가기가 어려우며 전반적인 가독성이 떨어지기 때문에 패키지 분리를 하는 것이고, 아무리 많이 쓰이더라도 1개의 Screen에서만 쓰인다면 굳이 분리할 필요가 없다는 결론을 내렸습니다.

MVI를 적용하면서 그때그때 필요한 Event, State, SideEffect를 추가해가며 구현하다보니 더 어렵고 헷갈렸습니다. UiEvent가 정확히 어떤 걸 의미하는지, UiState와 SideEffect가 정확히 무엇인지 먼저 이해한 뒤에 어떤 식으로 구현할지Ui 로직 자체를 미리 생각해보고 설계하는 것이 참 중요하다는 걸 깨달은 과제였습니다.

[jm991014]

컴포넌트화 및 UI단 설계

요기요

느낀 점

이거 될거 같은데? 라는 생각에 컴포넌트화를 진행하다 보면 코드가 너무 비대해져 가독성이 떨어지거나 약간의 차이로 합치는 것이 불가능할 때가 있는데, 이런걸 잘 캐치해서 시간을 과투자하지 않는 것이 중요한 것 같습니다. or 합치는 것이 가능하더라도 효율적이지 못하다면 가끔은 과감하게 넘어가는 것도 좋지 않을까요..ㅎㅎ

또한 UI로직 설계를 진행해보니, 생각만 하고 개발을 들어가는 것보다 미리 한 번 글이나 그림으로 작성하고 들어가는 것이 해당 화면에 필요한 기능이나 애니메이션이 명확히 보여 구현할 때 참 좋은 것 같습니다.

[Roel4990]

컴포넌트화 및 UI단 설계
3주차 과제

컴포넌트화 및 UI단 설계를 진행하며 느낀점 및 어려웠던 점

컴포넌트를 너무 작게 쪼개면 관리가 복잡해지고, 너무 크게 만들면 재사용성이 떨어질 수 있습니다. 저는 공통 컴포넌트를 모아 공통점과 차이점을 찾아서 컴포넌트를 설계했습니다. 초기 설계 시 재사용 가능성을 충분히 고려하지 않아, 후에 코드의 중복이 발생했습니다. 컴포넌트를 만들 때, 일반적인 사용 사례를 먼저 고려하고, Modifier 을 통해 커스터마이징 할 수 있도록 했습니다. 마지막으로 컴포넌트 네이밍에서 재사용성까지 생각해서 만들어야될 것 같아서 고민이 많았습니다. 이 부분은 다른 분들의 꿀팁을 얻고 싶습니다!

[jangsjw]

컴포넌트화 및 UI단 설계
https://husky-tangelo-73e.notion.site/3-c46f3fe0f192425ba1a7c65d35d3e5c2?pvs=4

느낀 점
평소 시작하기 전 정리를 잘 하지 않는 타입이라 세분화하는 작업이 어려웠지만, 지금까지 한 과제 중에 제일 재밌었습니다!! 그리고 컨포넌트화를 하면서 확실히 이렇게 한번 정리하면 작업 시에 효율적이겠다는 생각이 들었습니다. 분리하고 공통 컴포넌트를 찾는 과정보다 특히 어려웠던 부분은 네이밍이 가장 어려웠습니다. 아마 각 부분의 역할에 대한 개념이 부족한 것 같아 그렇게 느낀 것 같습니다!

[wjdrjs00]

컴포넌트화 및 UI단 설계
➡️ 과제 링크

• 그동안 앱 전체에서 쓰이는 공통 컴포넌트와 특정 화면에서 공통으로 쓰이는 공통 컴포넌트를 분리해서 구현하는 방식을 선호해왔는데, 이번에 모든 뷰를 보면서 공통 컴포넌트를 추출하는 과정이 아직 익숙하지 않았습니다. 그래서 제가 생각했을 때, 변경 가능성이 높아 추가 작업이 생길 거 같은 부분들이 보여 좀 보수적?으로 진행하며 확실하게 여러 화면에서 공통으로 사용되는 부분들에서만 진행했던 거 같습니다! (이 점은 팀프젝시 적절하게 정해봐야 알 것 같습니다!)
• 또 확실히 UI 로직을 먼저 설계하는 과정이 개발하면서 진행하는 것보다 실수를 줄일 수 있을 거 같다는 생각이 들었습니다.

[SYAAINN]

컴포넌트화 및 UI 설계

노션 정리

느낀점 및 어려웠던 점

Compose에서 "재사용"이라는 개념이 워낙 중요하다 보니,
UI 컴포넌트, 나아가 함수적인 측면에서도 재사용과 추후 유지보수를 염두에 두고 작업하려고 하는 편입니다.
이렇게까지 체계적인 단계의 설계는 처음이였는데 아직은 생각할 부분이 많은거 같아 낯선 부분이 있지만, 이렇게 꼼꼼히 설계를 하고 작업하게 되면 분명 추후 유지보수나 확장성 측면에서 이점을 가져갈 수 있겠다는 생각이 들었습니다.
저같은 경우, 컴포넌트 분리를 일단 비판적으로(?) 바라보고 설계를 하는 편입니다. 왜냐하면 컴포저블로 분리할 수 있는 만큼 최대한 분리를 하게 되면 Screen함수 자체는 깔끔해질지 모르나 추후 UI적으로 수정해야하는 부분이 생기거나, Composable 간의 관계성을 파악하는 데도 리소스가 많이 든다고 느꼈기 때문입니다.
그래서 작업을 할때

• 1개의 스크린 안에서 1번만 사용되는 경우 : 분리 x
• 1개의 스크린 안에서 여러번 사용되는 경우 : 해당 파일 내에서 분리
• 여러 개의 스크린에서 재사용 되는 경우 : 패키지 구조를 통해 가장 상위 패키지 component 경로에 분리

로 진행하려고 생각하고 있습니다. 하지만 이것도 프로젝트 규모나 상세 기능에 따라 항상 유동적으로 적용해야겠다고 되새기고 있습니다.

[MinseoSONG]

컴포넌트화 및 UI단 설계

💡3차 과제

느낀점 및 어려웠던 점

매 프로젝트를 할 때마다 힘들어하고 어려웠던 점이 컴포넌트화와 패키지 분리였는데 이번 세미나와 과제 덕분에 컴포넌트화에 대해 각 잡고 알아볼 수 있어서 좋았습니다.
그동안은 주로 재사용성에 중점을 두고 컴포넌트화를 진행했지만, 코드의 가독성과 유지보수성을 위해서라도 컴포넌트화가 필요하다는 점을 깨닫게 되었습니다. 다만, 과도한 컴포넌트화는 오히려 코드를 복잡하게 만들 수 있으므로 신중하게 접근해야 한다는 점도 깨달았습니다.
이번 기회를 통해 개발 전에 확실하게 UI 단 설계를 거쳐야 개발 중 발생할 많은 사고를 예방하여 시간과 노력을 많이 아낄 수 있겠다는 생각이 들었습니다.

[ThirFir]

https://marsh-supply-dc3.notion.site/3-131ccbd9b92880eda6d2c9e65c9b4e49?pvs=4

느낀 점

코드를 작성하는 것보다 설계를 하는 것이 훨씬 어려웠습니다. 아무래도 한 번도 이런 식의 설계를 해본적이 없다보니, 어떻게 시작하고 어디까지 나누고 세분화하는지가 가장 어려웠던 것 같습니다.
또 저는 컴포넌트를 이전 주차들에서 이미 만들고 시작을 했다 보니, 답을 정해두고 설계를 하는 느낌이 들어 효율적인 설계를 해내진 못한 것 같았습니다. 하지만, 처음부터 이렇게 설계를 하고 시작한다면, 어떤 기능을 챙겨야 할 지가 명확해지고, 구현 단계에서 확실히 시간을 덜 쓸 수 있을 것 같았습니다.

[tunaunnie]

컴포넌트화 및 UI 설계
3주차 과제

느낀 점 및 어려웠던 점
아직 MVVM 구조에 대해 익숙하지 않아서 각 화면을 Model, ViewModel, View로 분리하는 작업을 진행 중입니다..! 컴포넌트화는 너무 지나치게 자잘한 기능들을 묶으면 유지보수가 어려워지고, 너무 느슨하게 할 경우는 코드의 전체 길이가 길어져서 충분히 고민한 다음 진행해야 하는 작업인 것 같습니다. 그리고 컴포넌트의 이름을 정하는 것도 컨벤션이 있나요? section1, section2 이런 식으로 이름을 붙여두긴 했는데 나중에 유지보수의 편리함을 위해 이름을 수정해야 할 것 같습니다!

[Hyobeen-Park]

3차 과제

느낀점
저는 1,2차 과제 때 나름 컴포넌트를 만들면서 구현을 했는데요! 이미 개발을 하고 나서 설계를 하려고 하니 뭔가 문서화만 하는 느낌이 들고 좀 효율적인 설계를 못한 것 같은 생각이 드네요..!! 그리고 다시 한번 느끼지만 개발하는 것보다 설계하는 것이 훨씬 훨씬 어려운 것 같습니다 어디까지 컴포넌트로 만들어야 할지 고민이 많네요! 그래도 확실히 설계를 하고 개발을 하는 것이 나중에 편해지기 때문에!!! 계속해서 연습해야겠다고 생각했습니다.

여러번 재사용되는 부분들은 최대한 컴포넌트로 분리하려고 했습니다. 그리고 한 번만 사용되는 뷰들도 해당 뷰가 딱 분리되는 느낌이 들면 컴포넌트로 만드는 편이에요!(ex. 탑바) 근데 이 경우는 오로지 저의 느낌으로만 판단하는 경향이 있는 것 같아서 명확한 기준을 정하는 것이 중요할 것 같네요!!

그리고 패키지 분리를 할 때 여러 Screen에서 사용되는 컴포넌트는 core/designsystem/component 패키지에, 1개의 Screen에서 사용되는 컴포넌트는 Screen 내부에 component 패키지를 만들어서 분리했습니다! 모든 컴포넌트를 한 곳에 모아두는 것도 가독성이 떨어지고 불필요한 종속성을 가지게 되는 것 같아서요!

저도 설계쪽은 완전 감자라😅 다른 분들은 어떤 기준을 가지고 설계하시는지 궁금하네요!!

[serioushyeon]

3차 과제 노션 링크

---

느낀점
UI를 보고 여러 화면에서 재사용되는 컴포넌트의 경우 분리하는 것이 확실하지만, 여러번 쓰이지 않으나, 추후에 쓰일 만한 것은 컴포넌트 분리를 시키는 게 좋다고 생각했습니다! 하지만 그 기준을 어떻게 세울 지에 대해 고민이 되었습니다.
한 화면에서 한번만 사용되는 컴포넌트를 분리시키거나, 너무 작은 단위로 컴포넌트화를 시키면 오히려 관리가 복잡해질 수 있고..
한번만 쓰이더라도 해당 컴포넌트가 복잡한 코드를 가진다면 분리하는 것이 가독성 측면에서 좋을 수도 있기 때문에 고민이 많이 되었습니다.
이러한 고민을 해결하고자 저는 컴포넌트 분리 우선순위를 세워봤습니다.

1. 여러 화면에서 재사용이 일어나는 컴포넌트 분리 (파일 분리, 추후 재사용이 필요해지면 그때 분리해도 큰 문제가 되지 않기 때문에, 초기에는 지나치게 작게 컴포넌트를 분리하는 것보다 명확하게 재사용이 필요한 부분만 분리)
2. 하나의 컴포넌트가 여러개의 역할(기능)을 맡는다면, 그 역할을 기준으로 컴포넌트 하나가 최대한 하나의 역할을 맡도록 분리 (단일책임원칙)
3. UI 컴포넌트가 너무 복잡한 코드일 때 분리, 내부에 나눌 수 있는 것은 작은 컴포넌트로 분리 (가독성을 위함!!, 파일 내부에서 분리, 너무 작은 단위는 오히려 관리가 복잡할 수 있으니 유의하기)

이와 같은 기준을 가지고 분리를 한다면 조금 더 가독성과 재사용성, 유지보수성을 고려하여 관리할 수 있을 것 같습니다. (하지만 이것도 실제 환경에서는 좀 융통성 있게 해야할 것 같아요..!! (ex: 처음에는 한 파일에 합쳐놨다가 필요 시 분리)

[boiledEgg-s]

설계 기록

3주차 과제 노션

느낀 점

구현 전 설계를 자세하게 선행한 적이 없었는데, 이번 과제를 통해 제 코드를 다시 한번 돌아보며 재사용성과 유지보수성에 대해 많이 고민해보고 연습하는 시간을 가질 수 있었습니다!

컴포넌트화에선 무엇보다 이름에 대한 고민을 많이 했던 것 같아요.. 특정 화면에 대한 코드를 볼 때, 어떤 컴포넌트가 무슨 동작을 하는지 이름만으로 파악이 가능해야 이해가 빨리 될 것이라고 생각했습니다! 근데 아직까지도 이름들이 좀 거슬리네요ㅎㅎ

이번 과제같이 세부적인 설계를 처음부터 하고 코드를 구현했다면 지금보다 훨씬 깔끔하고 덜 복잡한 결과물이 나오지 않았을까 싶었습니다,, 그만큼 설계가 시스템을 만드는 과정에서 중요하다는 것을 깨닫게 된 과제였습니다!

[kangyein9892]

설계 기록

3주차 과제 노션

느낀 점

항상 무작정 개발에 들어가고 이렇게 설계를 하나하나 세부적으로 한 적은 없는 것 같은데 다시 한번 저의 개발 습관? 행동에 대해서 돌아볼 수 있던 것 같습니다. 컴포넌트화를 했지만, 아직도 많이 부족한 것 같다는 생각이 듭니다. 다른 분들을 보고 많이 배워야할 것 같아요 !
컴포넌트를 어디서부터 어디까지 해야할지 그런 기준들을 세우는 게 아직은 어려운 것 같습니다. 이번 과제를 하면서 반복되면서 사용되는 것들 뿐만 아니라 최대한 다른 화면에 사용될 것 같은 부분들은 컴포넌트 화하려고 노력했습니다. 아쉬웠던 건 아예 설계를 하고 시작했다면 더 깔끔하게 하지 않았을까라는 아쉬움을 많이 느꼈습니다.

[hyoeunjoo]

[노션링크]
https://rightful-narwhal-db9.notion.site/3-131037058d208073a5f1c9db0bcb5073?pvs=4

[느낀점]
컴포넌트 분리릏 하면서 가장 고민했던 부분이 TopBar였습니다. 로그인과 회원가입 화면은 중간에 꼭 텍스트/이미지가 있는 형태라서 묶었는데 홈 화면은 중간이 비어있고 padding값도 앞 두 케이스와는 다르기 때문에 따로 뺐습니다. 또한 텍스트 필드도 show/hide를 담고 있는 pw를 기존 email 텍스트 필드와 분리했습니다. show/hide 기능까지 넣어서 한 번에 처리하기엔 하나의 컴포넌트가 너무 많은 역할을 담당하고 있다는 생각을 했기 때문입니다. 사실 제 기준으로 한 것이라서 맞는 분리인지 아직까지도 확신이 없네요.

지난번 앱잼 때 겹치는 컴포넌트들이 굉장히 많았는데 구현하기에 급급하다보니 이런 컴포넌트/뷰스케치 부분에 신경을 많이 못썼던 것이 아쉬움으로 남아있었습니다. 이번 과제 좋은 경험 및 로직을 배운 것 같습니다. 이를 토대로 곧 있을 합동세미나때도 처음부터 기반을 탄탄히 다지며 확장성 있고 효율적인 코드를 짜는 경험을 쌓아나가고 싶습니다.

[0se0]

1. 재사용성과 일관성 고려

• 기존 코드의 중복된 부분들을 HorizontalContentRow와 HorizontalPosterRow 컴포넌트로 분리하면서, 재사용 가능한 컴포넌트 설계의 중요성을 느낌
• 컴포넌트 구조를 잡을 때 generic을 활용하여 다양한 타입의 아이템을 처리할 수 있도록 유연하게 설계
• 모든 컴포넌트에서 일관된 패딩과 간격을 유지하도록 하여 UI의 일관성 확보

2. 책임과 역할 분리

• 각 컴포넌트의 책임을 명확히 분리하는 것이 중요했음
• HorizontalContentRow: 기본적인 가로 스크롤 레이아웃 제공
• HorizontalPosterRow: 포스터 이미지에 특화된 레이아웃 처리
• ImageWithRank: 순위가 있는 이미지 표시에 특화
• 이를 통해 코드의 가독성과 유지보수성이 향상됨

3. 직면했던 문제들

• LazyRow에서 repeat 사용 시 아이템 간격이 제대로 적용되지 않는 문제 발견
• 이미지 크기를 고정값에서 비율로 변경하는 과정에서 레이아웃 조정의 어려움
• 적절한 패키지 구조 설정(modifier vs component)에 대한 고민

4. 개선된 점

• 코드 중복 제거로 유지보수성 향상
• 일관된 UI 패턴 적용으로 사용자 경험 개선
• 컴포넌트의 재사용성 증가로 개발 생산성 향상
• Edge-to-edge 디스플레이 대응을 위한 패딩 처리 개선

[jihyunniiii]

설계 내용도 같이 넣어주시면 좋을 것 같습니당!

[chrin05]

https://aboard-spoonbill-aed.notion.site/SOPT-3-131b106cd7d580e09401c3597cd9b8fc?pvs=4

느낀점
컴포넌트화를 조금씩은 써오고 있었지만, 이번 과제를 통해 공통 컴포넌트를 찾고, 뷰스케치 하며 한 번 정리하고 작업을 진행하면 구현 속도가 빨라질 거 같다는 걸 느꼈습니다. 그러면서 UI 분석하는 것의 중요성을 많이 깨달았던 거 같습니다. 그리고 과제를 하면서 컴포넌트 분리를 어디까지 해야할지 고민을 많이 했던 거 같습니다. 세미나에서 배운 내용을 바탕으로 꼭 굳이 재사용성이 높지 않더라도 가독성을 높이기 위해 적절히 컴포넌트화했던 거 같습니다. 나중에 프로젝트를 진행할 때에도 유지보수 측면이나 재사용성을 고려해서 컴포넌트화와 UI단을 잘 설계하여 진행해보고 싶습니다!

[beom84]

https://www.notion.so/3-13099c2ffa5680369416fbaad41efbaa?pvs=4

느낀점

---

저는 평소에 개발을 할때 생각없이 일단 부딪히는 스타일인데, 항상 개발하다 아맞다 이거! 하고 다시 돌아가서 고치는 경우가 다반사였습니다. 어떻게 고치지하다가 이번에 세미나에서 배운 내용을 보니 이런식으로 하면 개발 시간도 단축되고 효율적인 코드를 짤 수 있다고 느꼈습니다.
공통 컴포넌트를 고려하는 과정에서 이거까지..? 하는 경우가 너무 많았습니다.사소한 거까지 신경쓰다 보니 오히려 가독성이 안 좋아질 수 있겠다고 생각했습니다.
또한 컴포넌트화를 하며 네이밍이 정말 중요하다고 느꼈는데 이부분은 다른 분들의 네이밍을 보고 배워야겠다고 생각했습니다!

[imtaejugkim]

3주차 과제

느낀점
이전 개발까지는 컴포넌트화의 중요성을 크게 알지 못했는데, 이번 과제를 통해서 정말로 편의성을 많이 느낄 수 있었습니다. 사실 과제를 시작하면서 어느 부분까지 설계를 해야하나 많은 고민을 했었는데, 코드로 옮겨와 재활용할 때에 정말 편하게 구현할 수 있었던 것 같습니다.
어려움으로는 설계단위가 많이 어려운 것 같습니다. 이렇게 설계를 하고 진행하자 라고 하다보면, 개발 중에 아, 이것도 컴포넌트화 시킬걸 이라고 생각드는 부분들도 있었습니다. 이런 부분들도 리팩토링간 추가하여 다시 고려해보고 싶습니다.

[angryPodo]

컴포넌트화 및 UI 설계

---

https://www.notion.so/mindots/3-131b97a976b480b5b7ebf9edd3345cc6?pvs=4

느낀점

---

컴포넌트화와 UI 단 설계를 진행하며, 컴포넌트 범위와 패키지 구조 설정이 큰 고민이었습니다. 한 Screen에서만 쓰이는 컴포넌트는 해당 Screen에 내부적으로 분리하여 사용하고, 여러 Screen에서 사용되는 컴포넌트는 별도로 관리하는 것이 합리적이라는 결론을 내렸습니다. 그러나 애매한 기준에 놓인 컴포넌트들이 있어 재사용성과 관리 용이성을 고려하여 상황에 따라 적절히 분리하는 것이 중요하다는 걸 느꼈습니다. 특히, MVVM 패턴을 적용하면서 UiEvent, UiState, SideEffect의 역할을 명확히 이해하고 설계하는 것이 필수적이라는 걸 깨달았습니다.

또한, 컴포넌트를 너무 작게 쪼개면 관리가 복잡해지고, 너무 크면 재사용성이 떨어질 수 있다는 점이 문제였습니다. 이를 해결하기 위해 공통 컴포넌트를 찾아 커스터마이징이 가능하도록 설계하고, 네이밍과 재사용성을 고려한 설계를 진행했습니다. 이번 과제를 통해 컴포넌트화는 단순히 재사용성뿐 아니라 가독성과 유지보수성을 위해서도 중요하다는 점을 깨달았으며, 개발 전 UI 설계를 통해 코드의 비대함과 중복을 방지하는 것이 필요하다는 생각이 들었습니다.

[yskim6772]

3주차 설계 과제 노션

느낀점
이번 뷰 스케치 및 구현의 전반적인 설계를 진행하면서, 구현 전 설계의 중요성을 확실하게 알 수 있었던 것 같습니다. 이에 따라 설계를 미리 하고 구현에 들어갔으면 시간도 단축되고 처음부터 잘 짜인 구조 내에서 개발을 할 수 있기 때문에 훨씬 더 효율적일 것 같았습니다.
생각보다 컴포넌트화 할 부분이 많았고, 겹치는 요소가 많은 컴포넌트들 또한 합쳐서 하나의 컴포넌트로 묶는 것의 중요성도 알 수 있었습니다.
TextField 같은 경우에, 비밀번호 텍스트필드에는 show, hide 속성만 추가된 것이기 때문에, 이를 하나의 textfield 컴포넌트로 묶어보면서 이 과정을 겪게 되었습니다.
저번 앱잼을 했을 때에도 뷰 스케치를 진행했었는데, 이런 식으로 초반에 더욱 더 세세하게 설계를 하고 들어갔으면, 나중에 유지보수 하는 데에 있어서 더 수월했을 것 같다는 생각 또한 들었습니다.

[1971123-seongmin]

느낀점
UI 설계를 이정도로 자세하게 해본적은 없었는데, 이번 과제를 하면서 제 코드를 다시 보며 재사용과 유지보수성, 어떻게 컴포넌트화 해서 화면을 구성할지 공부해볼 수 있었습니다.

컴포넌트화 할 때 네이밍을 어떻게 해야할 지, 어느정도로 쪼개야 할지에 대해 고민을 많이 했습니다. 컴포넌트화를 제대로 했는지는 좀 애매한 부분들이 있는 것 같습니다. 무리하게 컴포넌트로 만들면 추후 세미나에서 활용할 때 문제가 생기지 않을까 고민을 많이 했습니다. 그래도 컴포넌트화를 하고나서 보니 코드가 훨씬 간결하고 깔끔해서 가독성이 좋았고 편했습니다.

어려웠던 점

• 높이 비율 설정
  • 가로는 주로 fillMaxWidth를 활용해 padding을 주면 되지만 높이를 비율로 설정하는 부분이 어려웠습니다. FillMaxHeight(1f) 형식의 코드를 사용했는데 맞는 방법인지 모르겠습니다.
• 화면 전체를 어떻게 구성할지
  • 전체를 LazyColumn으로 감싸서 했는데 Column을 활용해 Scroll하는 방법과 둘 중 어떤 방법을 써야할지 어려웠습니다.

[jihyunniiii]

설계하신 내용들도 넣어주시면 좋을 것 같아요!

[t1nm1ksun]

컴포넌트화 및 UI단 설계

AND-SOPT-ANDROID/minseok-shin#6 (comment)

느낀점

처음에는 구현에 급급하여 필요할 때마다 해당 컴포넌트를 즉흥적으로 만들어내는 방식으로 진행했습니다. 이로 인해 프로젝트 규모가 커지거나 추후에 변경사항이 생겼을 때 비효율적인 상황이 발생했습니다. 예를 들어, 동일한 UI 요소를 여러 번 구현하게 되면서 코드 중복이 심해지고, 유지보수가 어려워졌습니다.
하지만 미리 설계하고 공통 컴포넌트화를 진행하니, 뷰를 구성할 때 매우 효율적이었습니다. 공통 컴포넌트를 활용함으로써 코드의 일관성을 유지할 수 있었고, 새로운 기능을 추가할 때도 기존 컴포넌트를 재사용하여 시간과 노력을 절약할 수 있었습니다.
또한, UI 로직을 사전에 충분히 고민하고 설계하니, 세부적인 부분까지 미리 고려할 수 있었습니다. 예를 들어, 사용자 경험을 개선하기 위해 각 컴포넌트의 상태 관리와 이벤트 처리를 명확히 정의할 수 있었습니다. 이러한 사전 설계 덕분에 구현 과정에서 발생할 수 있는 혼란을 줄일 수 있었고, 결과적으로 가독성과 재사용성이 크게 향상되었습니다.
어려웠던 점은 초기 설계 단계에서 모든 요구사항을 완벽히 반영하기가 쉽지 않았다는 것입니다. 아무리 세세한 내용까지 미리 설계를 해두려 해도 놓치는 부분이 생기기도 하였습니다. 그래도 미리 설계를 해두는것과 안하는것은 큰 차이가 있었습니다.
결론적으로, 컴포넌트화 및 UI 단 설계는 프로젝트의 효율성을 높이고, 유지보수성을 개선하는 데 큰 도움이 되었습니다.

[hwidung]

3주차 노션 컴포넌트
ui 관하여 코드를 작성하고, 실행시켜보면 항상 수정 사항이 생깁니다. 그럴 때마다 관련된 ui, 비슷하게 했던 ui 모두 찾아가 다 수정을 해줬었는데, 컴포넌트화를 하니까 정말 신세계 🤩 재사용성이 너무 좋아서 하면서 재밌었습니다.
앞으로 파라미터로 뭘 넣어야할까? 고민을 더 세심하게 해야 할 것 같습니다.
어디까지 쪼개야 하는지, 또 쪼갠걸 다시 뭉치는 컴포넌트가 있을 수 있는지, 이런 부분에 대해 개념이 크게 잡혀있지 않아 구글링을 많이 했습니다. -> 합성 컴포넌트 라고 하네요 ..

[hyeeum]

𝟏. 컴포넌트화 및 UI단 설계를 진행하며 고민한 내용들을 정리해서 남겨주세요.
https://lively-sweater-80a.notion.site/SOPT-3-131854da242080a7a99ed6a89b9fbf6e?pvs=4

𝟐. 컴포넌트화 및 UI단 설계를 진행하며 느낀점 및 어려웠던 점을 공유해주세요.
사실 컴포넌트를 만드는 것을 좋아해서 이번 과제를 하면서 크게 어렵거나 했던 점은 없던 것 같습니다..! 화면을 다시 확인하고 설계하는 과정을 거칠 수 있었고 다시 한 번 생각 정리를 하는 느낌이라서 좋았어요 :)
다시 보면서,다른 사람들을 코드도 한 번씩 확인하면서 제가 이전에 작성했던 컴포넌트를 또 어떤식으로 분리할 수 있을지 생각하는 과정이 재미있었고 다양한 시야를 가질 수 있었던 것 같았습니다.
앞으로 어떻게 해야 더 재사용성이 높은 컴포넌트가 될 수 있을지 보다 깊게 탐구해보고 싶습니다!

[kamja0510]

컴포넌트화 및 UI단 설계

노션 정리

어려웠던 점 및 느낀점

네이밍이 생각보다 어려웠던 것 같습니다. 공통 컴포넌트라서 지어놨을 때 하나의 스크린에서 쓰일 때는 이름이 어색한 경우가 많았었던 것 같습니다.
또한 차지하는 사이즈가 부모 요소의 영향을 많이 받다 보니 그것들을 설계하는 측면에서 되게 어려웠던것 같습니다.
마지막으로 폴더링(?)도 애매한 부분이 많았습니다. 어떤 요소는 지금은 여러 화면에서 안쓰이지만 나중에 쓰일 것 같으면 따로 뺄 지 고민이 되고, 많은 스크린 중에 딱 2개에만 중복으로 쓰이는 컴포넌트면 또 따로 빼야할 지 둘 중 한 곳에 넣을 지 고민이 되었습니다.

이렇게 해보면서 느낀점은 어려운 점이 많은 대신 설계를 잘 할 수 있는 능력이 된다면 복잡하게 구현한 후에 나누는 것이 아닌 처음부터 중복되는 부분에 퍼즐처럼 끼워넣는 재미를 느낄 수 있을 것 같습니다. 또한 후에 협업하는 사람들과도 코드를 보며 효율적인 소통을 할 수 있겠다고 생각 했습니다.

[yihwanggeun]

AND-SOPT-ANDROID/hwanggeun-yi#6
https://lydian-resonance-7ed.notion.site/SOPT-3-1375851195b0807ab9dedf7f8a4fb3df

공통 컴포넌트중에 InputField랑 PasswordInputField랑 나눠놨는데 그 이유가 Password는 Show Hide도 있어서 이렇게 구현을 했었어요
근데 형태만 비슷하면 Parameter로 받을 애들만 받게 하면 되는 걸 생각해서 공통되게 InputField로 구성을 했습니다!

그리고 최근에 XML을 할 때 CustomVIew를 사용한 경험이 있어요. 이때 ListRowV1을 사용해서 왼쪽이 UnVisible되는 방식으로 다양하게 사용할 수 있더라구요
그래서 최대한 공통되게 만든 다음 그 컴포넌트 안에서 커스텀을 잘 하면 충분히 활용을 할 수 있을 것 같습니다!

[gitsuhyun]

노션 정리

지금까지는 피그마를 보면서 바로 디자인 작업에 들어갔는데 미리 쓰이는 컴포넌트를 정리하고 설계하는 과정을 통해 더 빠르고 네이밍도 헷갈리지 않고 컴포넌트를 수월하게 정리할 수 있었습니다. 앞으로 UI 작업을 할때는 최소한 자주 쓰이는 컴포넌트를 정리하여 네이밍을 사전에 정하는 것이 시행착오를 줄일 수 있을 것 같다는 생각을 하였습니다.

[sayyyho]

컴포넌트를 만들 때 어떤 이름을 붙여야 할지에 대해 고민했습니다. 설계를 하면서 직관적으로 만들려고 했지만, 쉽지 않아서 계속 고민했습니다.
또 어떤 기능을 컴포넌트로 분리할지, 얼마나 세분화해야 할지에 대한 고민을 했는데, 너무 코드가 난잡해져서 이 부분도 고민을 계속 하게 됐습니다.

이런 어려움이 있었지만 컴포넌트화 작업을 통해 코드가 깔끔하게 정리돼서 가독성 및 기능 분리가 용이해졌습니다. 각 컴포넌트의 역할이 명확하게 돼서 유지보수성도 향상되었다고 느꼈습니다.

[jihyunniiii]

설계 내용도 넣어주시면 좋을 것 같습니다 !