가장 큰 장점은 TAG를 안넣어도 된다는 것
그래서 생산성이 좋다.
Log.d(TAG, message)
Timber.d(message)
TAG를 쓰기 위해서는 중복됨을 방지하기 위해 TAG라는 변수를 만들어서 쓴다. 나는 보통 TAG로 클래스명이나 메소드명을 쓰는데, companion object 안에 만들어두고 썼다.
라이브러리의 선택 기준은 생산성과 가독성, 그리고 성능, 러닝커브라고 생각하는데, 라이브러리를 쓰는 입장 말고 만드는 개발자 입장에서 생각해보면 러닝커브는 그렇다 쳐도, 나머지는 꽤나 중요하다. 아래의 것 중에 아무것도 해당되지 않는다면 그 라이브러리를 만드는 이유가 없지 않을까?
생산성
해당 라이브러리를 도입함으로써 짧은 시간에 코드를 많이 짤 수 있는가?
가독성
기존의 가독성을 개선할 수 있는가?
성능
기존 보다 속도, 안정성, 사이드이팩트 등의 성능을 향상시킬 수 있는가?
러닝커브
러닝커브가 너무 높지는 않은가?
다시, 라이브러리를 쓰는 소비자 개발자로 돌아와보면!
이러한 기준들을 생각해서 마이그레이션을 할지 말지 결정하면 된다.
물론 저기에 해당하지 않는다면 마이그레이션 할 이유가 없다.
그렇다면 Timber의 경우 리소스를 들여서 마이그레이션을 하냐?
아니다. 새로 짜는 코드나 수정할 파일이 있다면 겸사겸사 고치는데, 굳이 리소스를 들여서 한번에 다 고칠 생각은 없다.