[Android] 2024 드로이드나이츠 - 기록하고 싶은 내용 정리

열리자마자 구매한 드로이드 나이츠
600명이 구매하였고,
열린 지 단 기간만에 매진

가서  포토존도 찍고 ㅎ
담당자 분 완전 친절하셨음

😇👍😇👍

시작 !!

Session 1 : Accessibility in android - 당근

 
더 큰 터치 영역
xmㅣ경우 touchdelegate를 사용하면 뷰의 사이즈 변경 없이 터치 영역 개선이 가능
Compose는 아직 제공하지 X, 커스텀 처리 필요
Compose에서는 터치 사이즈를 강제하는 Material Component가 존재해서 주의가 필요하다.
 
UI 요소 설명
android:lableFor : 텍스트 레이블
 
Acessibility
Espresso 테스트 - 접근성 테스트
 
자주 발생할 수 있는 접근성 문제 해결하기
Grouping : 연관된 콘텐츠를 그룹화하여 효율적으로 정보를 전달할 수 있다.
 
CustomView
 
접근성 가이드라인 - 텍스트 가시성 항상, 더 큰 터치 영역 사용, UI 요소 설명
접근성 검사 도구 - Accessibilty Scanner, Expresso
 
접근성 디자인은, 장애가 있는 사람뿐만 아니라 장애가 없는 사람에게도 유익합니다.
 
 

Session 2 : 시니어와 주니어의 협업 다리 : 온라인 및 오프라인 페어코딩의 통찰 - 네이버 카페

 
 
두 명이 하나에 컴퓨터로 같이 작업 : Pair Programming
- 결함이 준다
- 통합 시간이 줄어든다
 
Driver : 키보드로 직접 작업하는 사람
Navigator : 코드 분석, 아이디어 제시, 오류를 찾기. 
 
주의할 점
동등한 관계(시니어/주니어, 작업자/비작업자), 사전 준비(목표, 작업내용)
적절한 휴식
 
Pair coding Tools
화면 공유 툴(허들, Zoom), code with me, 원격제어 툴(Zoom, chrome)
 
OS 기본 제공 원격제어 툴 
설정 > 일반 > 화면공유
 
 
어떤 작업을 해봤나?
진행 방법 공유, 5분 단위의 역할 교대, offline, 서로 잘 모르는 작업, 잘 아는 작업, 단순하고 지루한 작업, 신규 작업, 회고
 
7회차 : 한쪽에 불편함을 주는 시도
-Driver가아무말도 안하는 경우
-Navigator가 아무말도 안하는 경우
 
어떤 의도로 코딩하는 지 알 수 없어 답답. 오ㅓ를 잘 이해하고 코딩하는 건지 모름.
오더에 의한 코딩
 
가장 중요한 점은 소통 이다.
 
장점
혼자 할 때마다 시간이 줄어 들었다, Review 시간이 대폭 감소되었다. 버그 발생은 30% 줄어들었다.
hotfix, 장애 대응, 페어코딩으로 성장한다. 코드 스타일이 비슷해진다.
 
같은 서비스를 오래 할 수록 효과가 커진다..
단기간에 만드는 서비스라면 비추
 
효율을 높이는 방법
-목표를 정한다 . (~까지 정하고 ~한다.)
-merge 가능할 때까지가 가장 효과가 좋았다.
coidng -> merge
 
페어 프로그래밍에 적합한 일
일정시간이상에 리뷰가 필요
도전적인 과제
신규 작업
2명이상 투입 과제
겹치는 부분이 많은 과제
 
적절한 시간
10분 단위 교대, 5분 단위 교대
2시간까지는 가능
 
전제
시간이 늘어나는 일이다.
단축하는 것을 목표로 하면 안된다.
단기적인 효과를 기대하지는 말자
장기적으로 팀원 역량을 높이기 위해 진행하는 것이 올바르다.
 
 
주니어 입장
시니어의 추론 과정을 지켜볼 수 있음
코드 스타일을 통일 할 수 있음 (로그를 어디다가 찍는 지, 디버깅을 어떻게 하는 지)
다양한 도구 노하우 습득
코드 리뷰에 적응할 수 있음
자신감이 오름
 
시니어 입장
시니어도 성장한다, 암묵지 제거 - json to 코틀린 플러그인(사용)
PR을 하는 사람은 플러그인을 돌린 건지, 직접 쓴 건지.. 이런 걸 확인.
 
소프트 스킬 향상
- 코드 설명, 더 좋은 방법에 대한 설명
- 통찰력, 이해하기 쉽게 말하기
- 성장시키기 기술
 
친해지는 것도 좋은데 거리 유지 필요
 
 

Session 3 :  Compose UI 설계와 테스트 - 우아한형제들

 
컴포넌트를 나누는 기준
재사용 가능성, 테스트 가능성, 하나의 역할, 변경에 유연함
 
Case 1: 화면 단위 구현 : SessionScreen
Case 2: 컴포넌트 단위 구현  - 특정 컴포넌트에만 변경사항 전파
 
하나의 컴포넌트는 하나의 문제만 해결해야 한다.
작고 간결한 API로 디자인
Compose에서는 선언적으로 작성된 컴포넌트로 쪼개어 설계할 수 있다.
 
React로 살펴보는 선언형 UI 컴포넌트 설계 노하우
 
Best Practies
함수형 컴포넌트
작고 재사용 가능한 컴포넌트
UI와 비지니스 로직의 분리
Atomic Design
 
사례로 알아보는 UI 컴포넌트 설계 팁
컴포넌트의 재사용성
비지니스의 확장과 변경을 고려한 설계
 
중복 제거를 강조하는 DRY 원칙을 과도하게
 
 
1. 재사용 가능한 컴포넌트
2. 결합도를 낮추고 응집도를 높인 설계
3. 객관적인 API 디자인
 
사례로 살펴보는 컴포넌트
자체적으로 상태를 생성/보유/수정하는 Stateful 컴포넌트
자체적으로 상태를 생성/보유/수정하는 Stateless 컴포넌트
 
-> 상태와 상태를 표시하는 UI를 분리하여 Stateless 컴포넌트를 위주로 테스트하자.
 
State Hoisting
상태를 상위 컴포넌트로 옮겨 여러 컴포넌트에서 공유하고, UI의 상태를 쉽게 관리하고 테스트할 수 있다.
 
컴포넌트 테스트 시나리오
컴포넌트 Contract 분석 - 컴포건트 난의 상호작용을 Contract를 통해 정의하는 방식
 
테스트가 필요한 항목 정의
컴포넌트 전체를 한 번에 테스트하기보다, 의미 있는 단위로 쪼개어진 컴포넌트를 각각 테스트한다.

불필요한 테스트 항복 제거 
테스트하지 않아도 되는 항목
불필요한 컴포넌트 내부 구현은 테스트하지 않는다. (이미지 로딩 방식)
Compose UI의 레이아웃 및 스타일에 적합한 테스트 방법
 
예시 
시나리오 : 북마크 아이콘 클릭 시, 북마크 상태가 변경된다.
 
 
1. 테스트 환경 세팅
2. 테스트를 위한 전제 조건 작성 => ex. 북마크 아이콘 클릭 시, 북마크 상태가 변경된다.
3. 테스트 대상 레이아웃 찾기
4. 검증부 (Assertion)
5. 실행 결과 확인
 
컴포넌트 단위의 UI 테스트 사용가능
 
Screenshot Testing : 
UI의 시각적 모습이 예상대로 표시되는지 검증
여러 해상도나 디바이스별 검증에 적합
 
적절한 단위로 쪼개어진 컴포넌트 
 
상황에 따라 Preview만으로도 충분
Compose Preview Screenshot Testing : 쉬운 노력으로 레퍼런스 이미지 생성, 체크할 수 있음
 
어떤 상황에서 테스트를 하던지 현실적인 리소스에 따라서 얼마든지 달라질 수 있따.
적절한 단위의 컴포넌트 분리와 테스트 가능한 설계는 중요하다.
 
 
-> 변경사항에 유연하게 대처, 테스트 가능한 컴포넌트.
 
 

AOSP (Android Open Source Project ) ⭐️⭐️⭐️

android 소스코드 검색 가능, branch 버전별로 확인가능
UI test 코드 확인 가능
이 소스코드를 유지보수 하는 코드를 작성 테스트 코드...
 
이러한 테스트 코드는 단순히 기능을 검증하는 것 뿐만 아니라 어떻게 사용되어야 하는지, 실직적이니 문서 역할을 하기도 합니다.
 
참고한 책
조형우 오브젝트
컨트 벡의 Tidy First 
 
좋은 선언형 UI 테스트 코드를 작성하려면 함수형 프로그래밍 경험을 적용할 수 있다 라는 것.
 
엄청난 패턴과 방법론 고려하기 전에 대처하기 쉽고, 유연한 설계부터 시작하자.
즉, 기본기를 되새기자.
 
 

Chapter 4 : Github Actions로 효율적인 배포 환경 만들기 - 당근

 
구현 단계
- 정적 분석 검사
- 단위 테스트
- 유니 테스트
 
 
구현 - ktlint
 
테스트 - Git tag
테스트 - PR comment
테스트 - Firebase App Distribution
 
배포 - 마일스톤 생성, 작업을 추적함.
전제 : 이번 배포에 포함되는 PR이 무엇인지 알기 어려움, 진척상황이나 일정 가시화가 되지 않음
 
 
배포 - 앱 배포
시간 절약, 일관성 보장
 
배포 - 릴리즈 노트 생성
변경사항에 대한 추적이 어려움, 규격화된 릴리즈 노트 생성이 어려움
 

Chapter 5: 당신의 앱 빌드는 안녕하십니까? - 라인 Plus

 
생산성고 앱 빌드 
- 
반복횟수 : 빌드 안정성 -  빌드 결과는 개발자가 의도한 대로 일정하게 나와야 함
빌드시간 : 빌드 성능
 
생산성과 앱 빌드, 빌드 안정성 개선, 빌드 성능 개선, 트렌드 따라가기
 
Repository content filtering - 특정 Repository에서 내려받을 산출물을 지정할 수 있음.
 
빌드 성능 개선
 
on-demand configuration
script 의존적인것만 읽음 -> 시간이 극적으로 줄어들음
 
configuration cache
- use previous calculated configuration
 
Incremental Build
증분 빌드 : 변경된 부분과 그 영향을 받는 부분만 다시 빌드하고, 나머지 부분은 빌드
변경된 소스코드로 부터 영향을 받는 부분  - 참조하던 인라인 가능한 코드 - Inline Function
 
BuildCofig.
Long.valueOf()로 감싸서 빌드시간 단축시키기
각각의 BuildConfigField는 static final modifier를 가집니다.
valueOf()로 감싸면 inline 최적화 가 방지됩니다.
 
최적화가 안되면, 앱 런타임에 서 느려지지 않을까? debug에서는 그럴 수 있지만, release에서는 valueof() 메소드 호출하는 부분에 대해 inline 최적화가 적용된다.
 
Avoiding build cache corrupt
용도에 따라 빌드캐시 격리 - 앱 배포를 위한 release pipeliine에서는 빌드캐시 끄기 + 클린빌드 수행
빌드 결과 모니터링을 할 수 있어야함.
 
빌드 커스터마이징
 
use gradle.properties to customize build
 
트렌드 따라가기
계속 꾸준하게 개선을 해야한다.. gradele milestone : 단기계획, gradle roadmap : 장기계획
 
Kotlin/Jetbrains Issues and Roadmap
KEEP (Kotlin Evolution and Enhancement Process)
 

Chapter 6. Compose Material3 컴포즈 디자인 시스템 구축기 - 컬리

 
KPDS - Kurly Product Design System 
 
UI와 비지니스 로직 분리
컴포넌트 단위로 작성이 가능하다.
Material design guide를 참고.

디자이너가 material 디자인에 맞춰서 피그마 내용을 공유 -> 디자이너도 많이 배우셨다고 함

상단 바 Core-component
 
Design Token (in material)
디자인 속성
성을 저장하는 실체, 색상.글꼴.치수와 같은 스타일 값.
 
KPDS 를 적용하면서 - 트럼블슈팅
recomposition
 
Compose 람다식 
KPDS 방향성 - 디자인과 개발코드는 하나, 아토믹 디자인으로 휴먼오류를 차단, 변화에 쉽게 대응할 수 있음
 
후기 
여태까지 안드로이드 컨퍼런스를 3번 가봤지만, 규모가 제일 컸다 !
내용을 거의 못알아들었다... 아직 갈 길이 멀다
하지만 너무 신기했고,,,
빅테크 기업 안드 개발자들의 발표 너무 멋있으셨다 👍🙇‍♀️
그리고 취준생뿐만 아니라 개발자 분도 굉장히 많이 오신 듯하다

취준생 입장에서 가격이 좀 비싸긴 했지만(?) 재밌었다
그리고 혼자 갔는데, 혼자 오신 분들도 많았다

그리고 compose 개발 공부를 진짜 해야겠다 ... 관련 발 표 주제가 제일 많았고, 연설장에도 사람이 젤 많았다

기능 개발 뿐 아니라, 접근성 테스트, 빌드 테스트, ui 테스트, github action 등등 ..

앱 개발을 하기까지 정말 많은 걸 고려해야 하는 구나 .. 싶었다 !!! 내년에도 또 한다면 가고싶다

두둑한 굿즈들 ... 🧡
너무 귀엽잖ㅇ ㅏ !!!
#드로이드나이츠