티스토리 뷰
(제목은 대충 이제 시작했다는 말ㅎㅎ)
오늘 처음 프로젝트의 일부에 Jectpack Compose를 도입했다!
국내기업의 대표적인 Compose 도입 사례로는 우아한형제들, 네이버제트, 무신사의 사용이 꼽힌다.
FAANG도 일부를 시작으로 슬슬 Compose를 도입하고 있다.
얼마전 GDG Korea의 주관으로 Compose의 진입장벽을 낮출 수 있도록 6주간의 Compose Camp가 진행되기도 했다. 매주 토요일 마다 모각코에 참여하는 형태로 참여하면 좋았겠으나.. 달콤함을 택하여 이제서야 혼자 고군분투를 시작했다.
나는 Google에서 유도하는 그 어떤 권장사항을 대체로 따르려고 하는 편이다. 늘 도입하는 시기가 문제지 따라가야 한다는 강박?도 가지고 있다. (지금도 시도 조차 못한 몇가지 리스트가 가슴 한 켠에서 바로 튀어나온다..)
Compose가 가장 대표적인 학습 투자시간의 문제로 "도입해야하는데.. 하는데.." 하며 마음 한 켠의 불편함으로 남아있던 최상위 목록이었다. 그러나 막상 무턱대고 몇 개의 텍스트와 버튼을 그리는 것을 시작으로 하니 눈앞이 캄캄했다.
xml value의 key값을 새로운 선언형태로 호출만 하면 될 줄 알았는데, 전혀 그렇지 않다. 완전히 새로운 언어를 배우는 것과도 같았다.
돌이켜보면 길지 않은 경력임에도 IDE를 바꿔서 사용해야하는 일을 한 번 경험했고 어느 순간 아예 새로운 언어로 개발해야했다. 또 각기 3가지의 Architecture 타입을 분석하고 프로젝트에 적용했다. UI 사이드에서는 ConstraintLayout이 나왔을 때, 처음 적용하며 이전 보다 개발 속도가 현저하게 줄어드니 재미도 없고 스트레스 받기도 했었다.
플러그인 지원 자체를 종료해버린 IDE의 변경 외에 다른 것들은 어찌보면 선택사항임에도 그것들을 학습하고 프로젝트에 안정적으로 적용해야하는 부가적인 노력이 계속해서 필요했다. 하나의 프로젝트에서 중요한것이 '빠르게 개발을 완료' 하는 것이라면 전혀 필요 없을 노력일 수 있는데 과연 큰 학습곡선을 감수하더라도 꼭 새로운 언어와 패턴, 개발 방법을 수용해야할까?
그렇지만 나는 반드시 수용하는 편이고 그래야 한다고 생각하는 큰 이유는 다음과 같다.
첫번째 :
이미 최고의 리소스들로 정확한 검증을 수백번도 빠르게 거친 후 일것이다. 처음에 좀 고생하면 훨씬 더 좋은 성능을 보장받는 것인데 쓰지 않을 이유가 없다고 생각한다.
UI 사이드만 예를 들어도 처음 RelativeLayout, LinearLayout을 통해 화면을 짤 때에는 배치를 위해 필요한 parent view를 추가하고 하위 요소들을 배치하며 기분좋게 키보드를 마구마구 두들겼다. 그러다가 스크롤 속도라도 느려질 참에는 그제서야 부랴부랴 불필요한 parent view를 하나하나 제거했다. 재밌는 사실은 정말로 개발과정에서는 진짜로 그 불필요한 parent view가 필요했다. (분명 필요해서 넣었는데 나중에 보면.. 그게 될까 싶은데 시간을 들여 제거하면 제거가 되더라. 그러니 그 화면을 완성하게 되는 시간에는
[처음 xml을 짰던 시간 + 문제를 겪어 당황하는 시간 + parent view 삭제 전략을 세우는 시간 + 삭제했다 원복했다 도저히 안돼서 남겨놓기로 결정하는 시간]으로 적지 않은 공수였다.)
그러나 그런 문제들을 거의 갓-벽하게 해결해줬던 것이 바로 ConstraintLayout 이었다. 비록 처음에는 조금 헤맸을 지언정.
두번째 :
유능하고 머리가 신선한 후배들과 일하기 위해서이다.
선배 개발자들이 가끔 "어셈블리어 해본적은 있나?" 묻는다. 나는 그냥 어셈블리어라는 언어가 있다고 학부시절 책에서 보고 넘어갔다. 그렇게 대답하면 선배들은 마치 "90년대생이 어떻게 30대냐!" 라고 외치는 듯한 반응을 한다.
90년대생으로서 우리도 이제 할비 할미인데 어찌 아직도 저런 반응을 하실까? 싶은 리액션들이다.
1-2년 후의 신입 개발자들은 java로 하나의 앱을 개발해본 적이 과연있을까? 학부시절외에 java를 써본 적이 없을 수도 있다.
그런 후배들과 같은 방법으로 같은 짜릿함을 계속해서 공유하며 개발하고 싶다.
계속해서 OS버전에 따른 정책 변경에 의해 강제로 전환되어야하는 라이브러리들이나 정책 대응의 방법에 대한 팔로업과 대응은 지속가능한 서비스 개발을 위해 너무도 당연히 진행해야 하는 것들이니 이러한 사항들은 개발자들의 숙명이라 언급할 필요도 없겠다.
처음 개발을 시작할 때에는 딱 10년만 잘 버티면 그간 숙달된 기술로 현재보다 훨씬 덜 공부하며 가뿐하게 개발할 줄 알았는데
어중간한 연차가 되니 오히려 앞날이 두렵다.
- Total
- Today
- Yesterday
- Kotlin
- DexArchiveBuilderException
- databinding onclick not working
- Hilt
- custom getter
- annotaion
- android
- AndroidManifest
- import aar
- com.android.build.api.transform.TransformException
- custom setter
- The requested URL returned error
- AAR
- decomplie
- Cannot create an instance
- aar import
- How to import android AAR file
- Make onClick event in Android databinding
- Please use a personal access token instead
- GitHub
- viewmodel
- android aar
- android aar library
- databinding onClick
- android launch mode in manifest
- launchemode
- android databinding
- Effective Kotlin
- module-info is missing a super type
- Support for password authentication was removed on August 13
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |