Recommended
More Related Content
Similar to 20년된 Naver Cafe 서비스가 Modularization으로 진화 하기_정동진.pdf
Similar to 20년된 Naver Cafe 서비스가 Modularization으로 진화 하기_정동진.pdf (20)
20년된 Naver Cafe 서비스가 Modularization으로 진화 하기_정동진.pdf
- 1. 20년된 Naver Cafe 서비스가 Modularization으로 진화 하기 정동진 / NAVER Community CIC
- 2. 소개 ❑ 운이 좋게 국내 안드로이드가 들어올 때 부터 했음 ❑ 안드로이드 이전에 경력도 8년정도 있음 ❑ 신기한거 좋아함.. ❑ 신기술 좋아함.. ❑ 첨보는 물건 좋아함 ❑ 귀찮은 것.. 아주 많이 싫어함 ❑ Tool 잘 사용함 ❑ Naver Community CIC / Android 팀
- 3. Naver Cafe 서비스 변천사 ❑ 서비스 시작일 ❑ 서비스일 : 2003년 12월 ❑ 올해가 20주년 ❑ 첫번째 앱 배포 2011. 06. 02 ❑ 출처 : 네이버 다이어리 ❑ 주요 SNS 앱 이용자 수 ❑ 출처 : 앱마인더 https://www.appminder.co.kr/report.html?idx=40
- 4. 우리 대표님이 내가 자랑 한거 꼭~ 봐야 하는데
- 5. 배경 ❑ Modularization ❑ 20년된 서비스
- 7. History of Naver Cafe architecture ❑ hum... ❑ mvp ❑ mvvm ❑ clean architecture(현재)
- 8. 모듈 ❑ Module ❑ :app - other... ❑ :shared - repository,domain,util ❑ :model - entity, apiModel ❑ java ❑ :cafe-lib-annotations ❑ :cafe-lib-annotations-processors
- 9. 기술 ❑ language : ❑ java ❑ kotlin(5%) ❑ api : ❑ xml ❑ json ❑ find view id : ❑ butterknife ❑ image loader : ❑ AUIL
- 10. 기술 ❑ 비동기 : ❑ rxjava ❑ 통신 : ❑ spring-android-rest-template ❑ apache HttpClient ❑ volley ❑ retrofit ❑ 기타 : ❑ nine old androids ❑ commons-lang
- 11. 왜?🤨 멀쩡한 앱을...
- 12. Cafe App architecture 목표 ❑ 오래된 기술 스택 버리기 ❑ EventBus, RxJava2, ButterKnife, Apache HttpClient ❑ 유지보수를 어렵게 합니다. ❑ Android SDK 변경에 따라 못 사용 할 수도 있음 ❑ ViewModel ❑ data에 흐름이 보이지 않음 ❑ 복잡하고 비대한 ❑ Best Practice 만들기 ❑ 반응형, compose, UDF, testable ❑ 일관성 코드를 작성해서 작성한 코드가 안더라고 쉽게 이해
- 14. Modularization ❑Guide to Android app modularization ❏ 모듈화의 장점 ❏ 코드의 재 사용성 증가 ❏ 기능별 코드 분리로 관리 용이성 향상 ❏ 독립적인 테스트 환경 제공 ❏ 모듈화 전략 ❏ UI 계층: UI 및 OS 상호 작용 로직 포함 ❏ 도메인 계층: 비즈니스 로직 포함 ❏ 데이터 계층: 데이터 저장 및 액세스 로직 포함 ❏ 학습코스 ❏ https://developer.android.com/courses/pathways/android-architecture
- 15. Modern Android App Architecture https://developer.android.com/courses/pathways/android-architecture
- 16. Build Time...
- 17. 우리는 빌드를 언제 하는가? ❑ 빌드는 언제 했지? ❑ 배포할때 🤔 ❑ TDD - UnitTest ❑ 개발할때 Best Practices for Response Times and Latency https://oreil.ly/YYH0b 출처 : 구글 엔지니어는 이렇게 일한다
- 18. 200ms 빠르다 1초가 넘어가면 주의가 분산 10초 보다 크면 전혀 다른 일을 하기 시작, 생산성을 급격히...
- 19. 왜 모듈화를 생각했을까?
- 20. 개발 속도 Presentation Domain Data Compose App Presentation Domain Data Ui Demo Feature Demo Presentation Domain Data Presentation Domain Data
- 21. Compose만 분리 UI 빌드 Presentation Domain Data App Presentation Domain Data Ui Demo Feature Demo Presentation Domain Data Presentation Domain Data Compose
- 22. Feature만 분리 빌드 Presentation Domain Data Compose Ui Demo Feature Demo App Presentation Domain Data Presentation Domain Data Presentation Domain Data
- 23. 유지 가능한 작은 코드 만들기 ❑ domain - data - presentation을 모듈분리로 간섭할수 없게 됨 ❑ 독립적인 코드 ❑ 작은코드 ❑ 규격화 하기 ❑ Bus factor 높이기 출처:https://www.lesstif.com/software-engineering
- 24. Legacy 던전 공략집
- 25. 목차 ❑ 문서화는 기본이다. ❑ 어려운 코드 쉽게 바꾸기 혹은 지우기 ❑ refactoring과 feature(과제)는 분리해서… ❑ 대규모 변화 vs. 점진적 변화
- 26. 문서화는 기본이다. ❑ 문서가 있을경우 ❑ 최신화되어 있는지 확인 ❑ 문서가 없을경우 ❑ 모든 코드를 찾아서 확인 ❑ 작업한 내용도 나중을 위해 필요함 ❑ 문서화가 필요 없을경우 ❑ 자주 해봐서 머리속에 들어가 있는경우 ❑ 팀원 모두가 익숙하거나 익숙한 팀원과 긴밀히 소통이 가능한경우 ❑ 타이핑에 의한 코딩 수정이 아닌 IDE에 의한 파일이동 모듈이동 ❑ Hotfix 하면 되지~(팀 특성)
- 27. 문서화 최소요건 ❑ 상세한 문서는 없어도... ❑ 화면에 기능에 대한 정의 ❑ 예외사항 기술 ❑ 꼭 규격화된 문서가 아니어도 됨
- 28. ❏ 예전에 없었던 / 몰랐던 기술에 한계로 어렵게 쓰여진 코드들. ❏ 비동기처리 ❏ Kotlin 변환으로 없어질 코드들 ❏ apache common util : kotlin 전환 시 필요 없어짐 ❏ for + if : map, filter ❏ View.postDelayed ❏ coroutines 어려운 코드 쉽게 바꾸기 혹은 지우기
- 29. 핑계 없는 무덤은 있어도, 핑계 없는 code는 없다.
- 30. 하이럼 법칙 With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. API 사용자가 충분히 많다면 API 명세에 적힌 내용은 중요하지 않습니다. 시스템 에서 눈에 보이는 모든 행위(동작)를 누군 가는 이용하게 될 것이기 때문입니다. 출처 : 구 글 엔 지 니 어 는 이 렇 게 일 한 다
- 31. refactoring과 과제는 분리해서… ❑ refactoring과 업무를 동시에... ❑ 이 문제는 refactoring 버그? or 과제 버그? ❑ PR 내용이 복잡해 짐 ❑ 어쩔 수 없다면… ❑ 한 번에 하나에 모자만 써라 ❑ feature 모자를 쓸 것인가? ❑ refactoring 모자를 쓸 것인가? ❑ refactoring PR 후에 과제 PR하는것이 더 좋았습니다.
- 33. 점진적 변화 vs. 대규모 변화
- 34. 대규모 변화 ❑ 불안하면 새로 만들어라? ❑ 조금만 고쳐도 오류가 발생한다. ❑ 배포 후에 hotfix로 고생한다. ❑ Legacy refactoring이 의문스럽다?🤔 ❑ xml -> compose 전환 ❑ ViewModel + MVI를 적용 ❑ 고려사항 ❑ rollback을 염두해두고 작업하라 ❑ 몇줄 안되는 코드로 새로운 버전과 기존버전을 오갈수 있도록 작업
- 35. 대규모 변화 1. activity-alias를 사용 2. activity 단위의 분리 시에 효과 적이다. 3. https://developer.android.com/guide/topics/manifest/activity-alias-element
- 36. 기존모듈 <manifest xmlns:android="http://schemas.android.com/apk/res/android"> <application> <activity android:name="com.naver.cafe.feature.LegacyActivity" /> 신규모듈 <manifest xmlns:android="http://schemas.android.com/apk/res/android"> <application> <activity android:name="com.naver.cafe.NewActivity" /> <activity-alias android:name="com.naver.cafe.feature.LegacyActivity" android:targetActivity="com.naver.cafe.NewActivity" />
- 37. 어떻게 Module을 나눌까? ❑ Modularization Step ❑ My First Module ❑ Feature Module
- 39. Modularization 1 ❏ package에 의한 분리 ❏ 내부에서 layer가 분리 ❏ 작은 앱에서 유리함
- 40. Modularization 2 ❑ 기능별 분리
- 41. Modularization 3 ❑ feature 별 분리
- 42. Modularization 3 ❑ feature 별 분리
- 43. Modularization 4 ❑ 기능별 피처별 분리
- 44. Modularization 4 ❑ 기능별 피처별 분리
- 45. Modularization 5 ❑ 기능별 피처별 분리 후 유기적 통합 Presentation Domain Data App Presentation Domain Data Presentation Domain Data Presentation Domain Data
- 46. My First Module ❏ 공통 모듈 ❏ common(Android 공통) ❏ base(App 공통) ❏ Domain 공통 ❏ authentication ❏ network App Legacy 공통 common base network authentication
- 47. Feature 분리하기 1 ❏ 계층화 되어 있음 App Presentation Domain Data 공통 common base network authentication Legacy
- 48. ❏ 계층화 되어 있지 않음 ❏ Data Layer의 Model이 Presentation Layer의 Model 같은 모델로 사용되고 있음 App Presentation Domain Data Domain Data 공통 common base network authentication Legacy Feature 분리하기 2
- 49. Know How & Tip
- 51. Review 없이 머지하는 경우는? 1. 코드 위치 이동 2. IDE에 의한 변화 3. kotlin Convert
- 52. Branch 관리 Tag-1 Main Develop Develop-1 Feature-1.1 Feature-1.2 Main Release-1 Develop-1 Develop-1 Develop Bug fi x-1 Develop Release-1 Tag-1 Develop-2 Refactoring-1 Refactoring-2 Release-2 Develop-2 Develop-2 Bug fi x-2 Release-2
- 53. Branch 관리 Tag-1 Main Develop Feature-1.1 Feature-1.2 Main Release-1 Develop Develop Bug fi x-1 Develop Release-1
- 54. Review 끝날 때 까지 기다리는 건? 1. Review 순서 a. develop ← feature/A b. feature/A ← feature/B c. feature/B ← feature/C 2. Merge 순서 a. develop ← feature/A b. develop ← feature/B c. develop ← feature/C
- 55. Review 끝날 때 까지 기다리는 건?
- 56. Review 끝날 때 까지 기다리는 건?
- 57. Review 끝날 때 까지 기다리는 건?
- 58. Review 끝날 때 까지 기다리는 건?
- 59. Toggle Bookmark(^+⇧+0~9 / ^+0~9)
- 60. Tab 설정 : pinned tabs + Multiple rows
- 61. Tab 설정 : pinned tabs + Multiple rows
- 62. 파일 이동 전략
- 63. import 에서 주석처리 하면 수정할 파일이 보인다. //import org.apache.commons.lang3.StringUtils //import org.springframework.util.CollectionUtils
- 64. 파일 이동 후 오류 확인 1. 이동후에는 파일이 오류가 없는것 처럼보임 2. 파일을 하나씩 열어서 잠시 기다려야 오류가 발생함 3. 설정에서 Open Filse with Single Click 사용
- 66. 다른 Module에 동일 Package로 이동 ❏ 처음 이동은 다른 Module에 동일 Package로 ❏ source ❏ app/source/main/java/com/naver/cafe/package/Foo.kt ❏ target ❏ base/source/main/java/com/naver/cafe/package/Foo.kt ❏ package 정리는 빌드가 완료된 후에 진행 ❏ 권장 다음번 배포해 해도 늦지 않음 ❏ ugly 한 상태도 괜찮음 ❏ IDE에서 move보다 Finder(탐색기) 권장
- 67. 다른 Module에 동일 Package로 이동
- 68. Finder(탐색기) 권장 ❏ IDE에서 move 이동시 Refactor 과정이 있음
- 69. Shells...
- 70. Create module shell ❑create module ❑https://gist.github.com/eastar-dev/0682a69c16f712f562d503beae037b5d
- 71. 모듈 탬플릿 파일 ❑https://github.com/eastar-dev/Droid-Knights-2023/files/12527644/ module_template.zip ❑모듈 탬플릿 파일
- 72. ModuleMover 1. basefunc a. https://gist.github.com/eastar-dev/e9eb7f4da9a6cd28d229ae086dcdfdc6 2. ModuleMover a. https://gist.github.com/eastar-dev/b8b24445d390b33d0b952339ef332fd9 3. Module Mover Last a. https://gist.github.com/eastar-dev/c1e8584e49b78483f74c7f42a7cdcbbe
- 75. ModuleMover 후처리 ❑ search : 정규식 옵션 켜기 ❑ import com.naver.old.package.name.(BuildConfig|R|BR|databinding) ❑ replace ❑ import com.naver.new.package.name.$1 ❑ https://gist.github.com/eastar-dev/3d48869fa3385da6a25c261cfd65f6ba
- 76. ModuleMover 후처리 ❑ search : 정규식 옵션 켜기 ❑ import com.naver.old.package.name.(BuildConfig|R|BR|databinding) ❑ replace ❑ import com.naver.new.package.name.$1 ❑ https://gist.github.com/eastar-dev/3d48869fa3385da6a25c261cfd65f6ba
- 77. 모듈화 진행중에 막힐때… 1. file_a 이동 2. file_b 이동 3. file_c 이동 4. file_d 이동 -> 막힘 5. issus 생성 file_d 모듈화 진행 6. issus 생성 file_d 이동 후 file_c 모듈화 진행
- 78. refactoring 위해 refactoring 하지말라 ❑ 새로운 기술을 위한 적용을 위한 refactoring인가? ❑ refactoring은 성과 인가?
- 79. Legacy 고립 전략 ❑ 지우지 못할 경우 고립시키는 것이 하나의 방법 ❑ Wrapper , Helper 를 통해 Legacy코드를 고립 ❑ implementation의 경우 고립된 곳에서만 사용하도록 변경
- 80. 현재 / 미래
- 81. 공통 common resource base network authentication web Presentation Domain Data Compose App Presentation Domain Data Ui Demo Feature Demo Presentation Domain Data Presentation Domain Data
- 82. Legacy 공통 common resource base network authentication web Presentation Domain Data Compose App Presentation Domain Data Ui Demo Feature Demo
- 83. Legacy 공통 common resource base network authentication web Presentation Domain Data Compose App Presentation Domain Data Ui Demo Feature Demo Domain Data Legacy
- 84. Legacy 공통 common resource base network authentication web Presentation Domain Data Compose App Presentation Domain Data Ui Demo Feature Demo Domain Data Domain Data
- 85. Legacy 공통 common resource base network authentication web Presentation Domain Data Compose App Presentation Domain Data Ui Demo Feature Demo Presentation Domain Data
- 89. 이 글을 Legacy에 고통받는 당신에게 바칩니다.
- 90. Q/A