[CHORE/#310] 빌드로직 구현 수정

[leeeyubin]

• closed [CHORE] 빌드로직 구현 수정 #310

⛳️ Work Description

• 모듈 이름 type safety하게 바꾸기
• 서버통신 관련 string 추출 core에서 하기
• 네트워크 라이브러리 수정
• Sdk 업그레이드 (34 -> 35)
• 버전 업그레이드 (1.1.8 -> 1.2.0)
• Compose Compiler Metrics 확장함수 추가

📢 To Reviewers

(1) 서버통신 string 추출

• R.string.server_failure까지 임포트한 이유는 단순히 com.terning.core.designsystem.R로 임포트를 하면 기존의 R 클래스와 충돌이 생기더라구요.
• 그래서 서버통신 문자의 경우만 server_failure로만 넣을 수 있게 해두었어요!

=> as 사용하는 방식으로 수정 완료

(2) Compose Compiler Metrics Report

• 컴포즈의 성능을 확인할 수 있는 방법을 적용했어요!
• 만약에 본인의 모듈 성능을 확인해보고 싶다면 Gradle 명령어를 아래와 같이 입력해주세요.

 ./gradlew :{원하는 모듈}:assembleDebug

• 보고서 관련 자세한 사항들은 제가 쓴 블로그 참고해주세요!
• 고민인 부분은 보고서 파일들이 생기는 위치인데 아래 3가지 정도 생각해봤어요. 현재 방법대로 갈까요??

1. 프로젝트 가장 최상위에 두기
2. 각 모듈 하위에 바로 두기
3. 각 모듈 build 파일 안에 두기 (현재 방법!! 이러면 깃허브에 올라가진 않음)

[boiledEgg-s]

Compiler Metrics Report 신기하네요,, 잘 써먹을 수 있도록 공부해야겠네요ㅎㅎ
저는 개인적으로 현재 방법이 좋다고 봅니다! 프로젝트 안에 Metrics를 계속 갱신하면 불필요한 커밋이랑 pr이 계속 발생할거 같아요,,

R 클래스 관련해선 댓글을 남겼는데 참고"만" 해주세요~

[boiledEgg-s]

as라는 예약어를 사용하여 라이브러리의 이름을 지정하고 사용할 수 있어요!

Suggested change

	import com.terning.core.designsystem.R.string.server_failure
	import com.terning.core.designsystem.R as DesignSystemR

위와 같이 라이브러리에 이름을 부여하면 코드에선 DesignSystemR.string.server_failure로 사용이 가능합니다!

[leeeyubin]

오호 이에 대해선 몰랐네요!! 이 방법이 헷갈리지 않고 쓸 수 있는 것 같아요! 적용해보겠습니당

[boiledEgg-s]

이 문서들이 Compiler Metrics Report가 동작하여 생기는 것들이죠?
이 파일들이 깃허브에 올라오는건 불필요해보이네요..
각자 분석하는 용도로 사용하면 매우 좋을 것 같습니다!

[leeeyubin]

네! 이 파일들입니당
저도 깃허브에 올라오는 게 불필요하다고 생각해서 이대로 가도 될 것 같아요! 의견 감사합니당

[Hyobeen-Park]

우와!! 수고하셨습니다!! 확실히 코드가 더 깔끔해진 것 같아요!!!

그리고 보고서 파일 위치는 현재처럼 가는게 좋다고 생각해요!!! 보고서는 깃허브에 올라가면 안될 것 같은 느낌이랄까요..?? 그리고 보고서가 추가되거나 변경될 때마다 불필요한 커밋이 생기는 것도 안좋아보여서요!!

[leeeyubin]

feature 그래들마다 configureComposeMetrics() 함수를 추가하는 게 불필요하다고 생각해서 아예 feature 빌드로직 안에 넣어두었어요!
그래서 별도의 함수 추가 없이 바로 Gradle 명령어 이용해서 사용해주시면 됩니다!

만약에 처음 명령어 실행 후, 코드가 수정되면 rebuild를 해주는 것만으로도 보고서 파일에 반영되는 것 같아요:)

확인 부탁드려요🙏 @Hyobeen-Park @boiledEgg-s @arinming

[boiledEgg-s]

확인했습니닷