-
반응형
API 안정성을 확인하라
- API가 변경되고, 개발자가 이를 업데이트 했다면 여러 코드를 수동으로 업데이트 해야한다. 많은 요소가 이 API에 의존하고 있다면 이는 큰 문제가 된다.
- 라이브러리의 작은 변경은 이를 활용하는 다른 코드들의 많은 부분을 변경하게 할 수 있다. 그래서 이전 라이브러리를 유지하는 경우가 있다.
- 오래된 라이브러리는 버그와 취약성이 발생할 수 있기 때문에 안정적인 라이브러리로 업데이트 하는 것을 두려워하면 안된다.
- 처음부터 안정적이지 않은 모듈을 많이 공부하는 것보다 안정적인 모듈부터 공부해보는게 좋다.
- API의 일부가 불안정하면 이를 개발자에게 명확히 알려줘야한다.
외부 API를 wrap 해서 사용하라
- API 설계자가 안전하지 않다고 하거나 우리가 그것을 제대로 신뢰할 수 없다면, 해당 API는 불안정한 것이다. 이러한 불안정한 API를 과도하게 사용하는 것은 굉장히 위험하다.
- 어쩔 수 없이 사용해야 한다면 로직과 직접 결합시키지 않는 것이 좋다.
- 그래서 불안정하다고 판단되는 외부 라이브러리를 wrap해서 사용한다.
- 문제가 있다면 warpper만 변경하면 되므로 API 변경에 쉽게 대응할 수 있다.
- 프로젝트의 스타일에 맞춰서 API의 형태를 조정할 수 있다.
- 필요한 경우 쉽게 동작을 추가하거나 수정할 수 있다.
- 하지만 단점으로 래퍼를 따로 정의해야하고, 다른 개발자들이 어떤 래퍼들이 있는지 따로 확인해야한다.
요소의 가시성을 최소화 하라.
- 작은 인터페이스는 배우기 쉽고 유지하기 쉽다.
- 일반적으로 어떤 수정을 할 때는 클래스 전체를 이해하고 있어야 하는데 보이는 요소 자체가 적다면 유지보수하고 테스트 할 것이 적다.
- 변경을 가할 때는 기존의 것을 숨기는 것보다 새로운 것을 노출하는 것이 쉽다.
- 가시성이 제할될수록 클래스의 변경을 쉽게 추적할 수 있으며, 프로퍼티의 상태를 더 쉽게 이해할 수 있다.
- 내부적인 변경 없이 작은 인터페이스를 유지하고 싶다면 가시성을 제한하면 된다.
반응형'개발 > Android' 카테고리의 다른 글
[이펙티브 코틀린] hashCode의 규약을 지켜라 (0) 2023.04.28 [이펙티브 코틀린] 상속보다는 컴포지션을 사용하라 (0) 2023.04.27 [이펙티브 코틀린] 추상화 설계 (0) 2023.04.11 [이펙티브 코틀린] 일반적인 프로퍼티 패턴은 프로퍼티 위임으로 만들어라 (0) 2023.04.10 [Kotlin] 안드로이드스튜디오 다양한 형식의 자료형 Intent 활용 방법 (0) 2023.04.06 댓글