우아한 테크캠프 2주차 - 1

2주차는 팀 프로젝트로 진행되었고 3주차까지 동일한 프로젝트를 진행하게 된다. 협업 프로젝트 과정에서 배운 부분과 수업을 통해 학습한 내용을 정리했다.

1주차의 개인 프로젝트를 마무리하고(조금씩 수정을 해야겠지만) 2주차가 시작되면서 팀 프로젝트가 진행되었다. 페어 프로그래밍이 가능하게 2명으로 팀이 이루어져 프로젝트가 진행되었다. 몇몇의 팀프로젝트를 경험하긴 했지만 안드로이드 개발자와 함께 프로젝트를 진행한 경험은 거의 없었기 때문에 어떻게 협업하여 개발을 진행할 지에 대해 많은 고민이 필요했다. 코딩 컨벤션부터 Git, Github활용과 전략을 정하고 그에 맞게 진행을 해야했다. 다행히도 함께 프로젝트를 진행한 팀원분과의 성향이 일치하는 부분이 많아서 익숙치 않았지만 큰 충돌이나 문제없이 2주차까지 진행하기로 한 부분을 마무리할 수 있었다.

3주차에서는 더 시간을 효율적으로 쓰고 능숙하게 프로젝트를 진행할 수 있도록 2주차를 되돌아보고 점검하는 시간이 필요했다. 사실 매 주 새롭게 배우는 내용과 경험한 부분이 있기 때문에 한 주에 한 번씩 정리를 하는 것을 목표로 했는데 이번 주는 특히 정리할 내용도 많고 협업을 처음 시작한 주차여서 회고와 정리는 꼭 필요하다고 생각했다.

Review

협업

코딩 컨벤션
코딩 컨벤션을 정하고 이에 맞게 코드를 작성하는 것은 협업에서 매우 중요하다. 특히 네이밍 규칙이 중요하다고 생각드는데 일관성있게 코드를 표현하고 다른 팀원 혹은 제3자가 보더라도 단번에 이해할 수 있도록 하여야하기 때문이다. 클래스나 함수에 대한 네이밍뿐만 아니라 안드로이드의 많은 리소스들에 대해 일관되게 이름을 지을 수 있도록 알맞게 규칙을 정하고 이에 위반되지 않도록 주의깊게 코드를 작성하여야 한다.

Git과 Github
혼자 개발을 할 때에도 Git과 Github를 능숙하게 활용하는 것이 좋지만 협업 과정에서 만약 Git과 Github를 통해 버전관리를 하기로 했다면 중요한 명령어와 활용에 대해 이해하고 있는 것이 중요하다. 커밋부터 이슈, 풀 리퀘스트까지 단위를 어떻게 나누고 다른 팀원이 이해할 수 있도록 메세지를 작성하고 코드리뷰 과정을 통해 서로 피드백을 하는 과정은 협업에서 필수적이다. 또한 브랜치 전략을 팀의 상황에 맞게 적절하게 세우는 것이 중요한데 아직 협업 경험이 많지 않은 경우에는 이미 잘 알려진 Git Flow, Github Flow 전략을 바탕으로 브랜치 전략을 세워서 브랜치 관리를 하는 것도 좋은 방법이라고 볼 수 있다. 아직은 Git의 몇몇의 기능밖에 사용을 못하지만 하나씩 늘려나가서 능숙하게 활용할 수 있도록 자주자주 찾아봐야겠다.

풀리퀘스트를 많이 날렸지만 일관성있게, 명확하게 표현할 수 있도록 개선이 필요해보인다

---

OAuth2
OAuth2는 인증을 위한 개방형 표준 프로토콜이다. 써드파티 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공한다. 접근 자격이 있는지 검증하는 단계와 자원에 접근할 권한을 부여하고 리소스 접근 권한이 담긴 Access Token을 클라이언트에게 부여하는 단계를 거쳐 Access Token을 이용하여 리소스를 얻을 수 있다. 아래 주소를 통해 자세하게 확인할 수 있다.

참고 : https://blog.naver.com/mds_datasecurity/222182943542
https://datatracker.ietf.org/doc/html/rfc6749

Github OAuth

• 사용자는 GitHub ID를 요청하도록 리다이렉션됩니다.
• 사용자는 GitHub에 의해 귀하의 사이트(앱)로 다시 리다이렉션됩니다.
• 앱이 사용자의 액세스 토큰으로 API에 액세스합니다.

1. 사용자에게 Github 계정을 요청

• https://github.com/login/oauth/authorize 에 clientID와 redirect_url을 함께 파라미터로 GET으로 보내면 Github에 로그인 하는 웹페이지가 나타난다.
• 안드로이드 내에서 Intent와 ACTION_VIEW 플래그를 통해서 웹프라우저를 호출할 수 있고 이 때 Uri 값으로 위의 주소값을 넣어서 보내면 웹브라우저에 Github 계정 로그인 화면이 나타난다.

2. 기존의 앱이나 사이트 혹은 리다이렉션될 앱이나 사이트로 리다이렉션

• 1번에서 함께 보낸 redirect_url을 통해 해당 앱이나 사이트로 리다이렉션 되는데 이 때 accessToken을 얻을 때 필요한 code 값과 함께 리다이렉션된다.
• 안드로이드에서는 리다이렉션되면 딥링크를 통해 해당 앱을 다시 불러올 수 있고, 이 때 code값을 함께 받기 때문에 code값을 기억할 수 있도록 하여야 한다.

3. AccessToken 얻기

• https://github.com/login/oauth/access_token 에 2번에서 전달받은 code와 OAuth 앱에 대해 Github에서 받은 clientID와 clientSecret을 함께 POST 방식으로 보내면 그에 대한 응답으로 AccessToken값을 받을 수 있다.
• 안드로이드내에서도 해당 주소로 code,clientId,clientSecret 을 POST 방식으로 보내어서 응답으로 AccessToken을 받을 수 있다. HTTP 통신을 위해 Retrofit과 OkHttp 라이브러리를 사용하여 요청을 하고 응답을 받을 수 있다.

4. AccessToken을 통해 API에 액세스

• Authorization헤더를 AccessToken값으로 설정하면 Github에서 제공하는 API에 요청할 수 있다.
• 안드로이드 내에서 OkHTTP라이브러리에서 제공하는 Interceptor를 통해 Authorization헤더에 AccessToken값을 설정하여 보낼 수 있다. Interceptor는 응답 시에도 처리를 할 수 있는데 해당 코드가 만료되는 등 401에러가 떴을 경우 다시 Github Login을 유도하는 화면을 나타내게 할 수 있다.

참고 : https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps

딥링크
사용자를 앱의 특정 콘텐츠로 바로 연결하는 URL이다. 안드로이드에서 인텐트 필터를 추가하고 수신 인텐트에서 데이터를 추출하여 딥 링크를 설정할 수 있다. Manifest에서 인텐트 필터를 추가할 수 있는데 action, data, category 태그에 속성값을 설정하여 추가한다. Github OAuth를 통해 로그인 처리를 할 경우 미리 설정한 Url과 리다이렉션하는 Url 그리고 data의 scheme와 host를 일치시키는 것이 중요하다.
참고 : https://developer.android.com/training/app-links?hl=ko

리포지토리 패턴
리포지토리 패턴은 데이터 레이어를 앱의 나머지 부분에서 분리하는 디자인 패턴이다. 데이터 레이어는 데이터와 비즈니스 로직을 처리하는 부분을 말하며 나머지 앱에서 데이터 레이어에서 처리한 데이터를 통해 UI에 표시할 수 있다. 로컬 DB를 통해 데이터를 처리할 수도 있고 네트워크 통신을 통해 데이터를 처리할 수 있는데 UI 레이어에서는 어디서 데이터를 가져왔는지 알 필요가 없기 때문에 리포지토리는 보통 Remote Data Source와 Local Data Source를 나눠 데이터를 처리하여 UI 레이어 특히 뷰모델에서 데이터에 액세스하도록 한다. 현재 진행중인 프로젝트에서는 로컬 DB를 통한 데이터 처리가 없기 때문에 따로 Data source를 두지 않고 리포지토리에서 처리하도록 구현하였다.

참고 : https://developer.android.com/codelabs/basic-android-kotlin-training-repository-pattern#3

ViewModel 생성
뷰모델을 생성할 때 여러가지 방법이 있다. 우리 팀은 ViewModelProvider를 사용했는데 ViewModelProvider.Factory을 구현하고 ViewModelProvider.Factory 내에서 뷰모델이 어떤 컴포넌트에서 생성되는 지에 따라 달라지는 파리미터에 맞게 인스턴스를 생성하도록 구현하였다. 파라미터가 있는 경우와 없는 경우에 따라 구현 방법이 조금씩 차이나기 때문에 적절하게 사용하는 것이 중요하다. Android Ktx를 사용하면 더 간단하게 뷰모델을 생성할 수 있다.

참고 : https://readystory.tistory.com/176
https://black-jin0427.tistory.com/389
https://developer.android.com/kotlin/ktx?hl=ko#fragment

ViewTreeObserver
ViewTreeObserver를 통해 ViewTree의 변경을 감지할 수 있다. 컴포넌트의 생명 주기에 따라 뷰가 그려지는 시점이 달라지기 때문에 뷰가 다 그려지고 난 뒤를 감지한다거나 뷰의 포커스가 변경이 됐을 때 등 뷰가 변경되는 것을 감지하여 원하는 작업을 처리할 수 있도록 한다. 팀원분이 스피너를 사용할 때 이 ViewTreeObserver를 사용하여 처리한 부분이 있어서 새롭게 알게 됐고 뷰를 처리하기 어려운 경우가 있을 경우 ViewTreeObserver 사용을 고려해봐도 좋을 것 같다.

참고 : https://leveloper.tistory.com/167
https://onemask514.tistory.com/53

inline과 reified
인라인 키워드는 자바에서는 제공하지 않는 코틀린만의 키워드인데 코틀린에서 고차함수를 사용하면 패널티가 발생한다. 람다를 사용할 때 각 함수는 객체로 변환되어 메모리를 할당받기 때문에 페널티가 발생한다고 하는데 inline functions는 내부적으로 함수 내용을 호출되는 위치에 복사하며 그런 Runtime overhead를 줄여준다.
reified는 일반적인 제네릭에서 타입 T는 컴파일 타임에는 존재하지만 런타임에서는 접근할 수 없다. reified 키워드를 함께 inline 함수를 만들면 추가적으로 Class<T>를 넘겨줄 필요 없이 런타임에서 타입 T에 접근할 수 있다.

참고 : https://velog.io/@miot2j/Kotlin-Inline-Funtions-과-Reified-사용-이유
https://sungjk.github.io/2019/09/07/kotlin-reified.html