전체 글

현재 프로젝트에 의존성 주입을 위해 Hilt를 사용하고 있다. Hilt는 Android에서 Dagger를 쉽게 사용할 수 있게 만들어주는 매퍼 라이브러리이다. 필자는 Hilt를 도입하면서, 제대로 알지 못하고 사용하여 많은 문제를 겪었다. 1. Hilt Scope 리뷰처럼, 필자는 코드의 유스케이스를 Hilt Scope Annotation을 처리하였다. 단순히 매번 호출할 때마다 인스턴스 생성하는 것을 방지하기 위함이였다. 리뷰를 통해 레퍼런스를 찾아보다, Hilt Scope를 잘못 사용하면 메모리 누수를 발생시키고 더 나아가 성능 저하까지 일으킨다는 내용이 많았다. 아무래도 생명주기와 연관있다 보니, GC에 수집되지 않는 부분이 가장 큰 것 같다. 2. Hilt Component ActivityComp..

필자는 현재 프로젝트에 KtLint를 도입하고 있다. 이번 포스팅에서 KtLint 소개, KtLint 사용하고 있는 방법에 대해 소개하고자 한다. 포스팅하는 이유 프로젝트 초기 설정을 하면서 자연스럽게 린트 검사에 대한 이야기가 나왔고, KtLint를 잘 알지 못한 채 무작정 도입했다. 그 결과 이슈가 발생했다. 이전에도 크게 제대로 적용하지 못한 경험이 있는데, 이러한 경험도 돌이켜보면, 제대로 알고 쓰지 못해서 발생했던 것 같다. 그래서 이번에 KtLint에 대해서 공부해보고, 포스팅하면서 정리하고자 한다. 또한, 가만히 프로젝트 하다가 PR Failed를 당한.. 팀원에게 소개하고자 글을 쓰는 것도 있다. 린트의 장점 사실 이전의 프로젝트는 하나 빼고 KtLint를 적용하지 않았다. 왜냐하면, 계속..

이전 포스팅을 이어서, 이번에는 실제로 프로젝트에 Github Action을 적용한 사례를 소개하고자 한다. 현재 진행하고 있는 프로젝트의 협업 도구는 메세지로는 디스코드, 이슈 트래킹 및 칸반의 용도로 지라를 사용하고 있다. 이번 포스팅에서는 Github Action을 통해, 자동으로 Discord로 Github Event를 전송하는 방법과 이슈 생성시 자동으로 Jira Issue를 생성하는 방법을 소개한다. 그전에, 받았던 질문에 답을 기록하고자 한다. 1. Github Webhook에 Discord Webhook을 등록하면, 자동으로 알림 서비스를 받을 수 있는데요? Github Webhook을 사용하지 않고, 따로 Github Action을 사용하는 몇가지 이유가 있다. 첫번째로 메세지 커스텀이 ..

이번 새롭게 시작하는 프로젝트에서 CI/CD를 도입하고자 한다. 이번 포스팅에서는 CI/CD에 대해 공부한 내용을 소개하고, Github Action을 통해 Android Project CI/CD를 구축하는 방법에 대해서 소개한다. CI/CD 어플리케이션 개발에서부터 배포까지 자동화를 통해 더 효율적으로, 더 자주 사용자에게 배포하는 방법이다. 자동화를 통해 개발에 집중할 수 있도록 도와주며, 더 빠르고 자주 배포할 수 있게 만들어 주는 것이 특징이다. CI : Continuous integration 버그 수정이나 새로운 기능을 빌드되고 테스트되고 공유되는 레포지토리에 통합하는 방법이다. CI는 다음과 같은 특징을 가지고 있다. 코드 변경사항을 주기적으로 빈번하게 머지해야 한다. 새로운 기능보다 머지 ..

현재 진행하고 있는 프로젝트에서, 기존 모놀리틱 구조를 다중 모듈 프로젝트로 마이그레이션 하였다. 마이그레이션을 하면서, 종속성을 관리하기 위해 VersionCatalog를, 플러그인을 관리하기 위해 Custom Convention Plugin을 도입하였다. 필자는 다른 레퍼런스를 확인하며 구현하였지만, 제대로 알고 쓰지 않는 것 같았다. 따라서 이번 포스팅을 통해 Custom Convention Plugin을 정리하고, 소개하고자 한다. Task 컴파일된 코드를 실행가능한 파일로 변환하는 작업을 빌드라고 한다. 안드로이드로 가정하면, 컴파일된 코틀린 파일을 aab, apk와 같은 실행가능한 파일로 만드는 작업을 의미한다. 이러한 작업은 우리가 정의한 Gradle 파일에서 Task 단위로 수행되며, Ta..

필자는 최근에 진행중인 프로젝트를 리팩터링 하였다. 기본 패키지, 파일 네이밍부터 핵심 로직 수정까지 거의 모든 파일을 수정할 정도로 많은 작업을 수행했다. 그렇다 보니, 내가 수정한 작업이 정말 이전과 같이 잘 동작하는지 파악하기가 정말 어려웠고, 시간도 많이 걸렸다. 수정한 로직에서 문제가 발생하여, 디버깅을 하면서 문제를 탐색하고 고민하는 시간이 정말 많았다. 테스트에 대한 시간 투자가 아까워, 계속해서 미루었던 나는, 이번에 테스트에 대해 공부해보고, 실제 프로젝트에 도입하려고 한다. 테스트를 왜 작성해야 할까? QA보다 더 훨씬 효율적으로 점검할 수 있다. 필요할 때 마다, 규모가 커지면 커질 수록 QA에 의존하는 것은 힘든 일이다. 자동화된 테스트는 앱의 확장가능성을 더욱 높여준다. 좋은 설계..