3장 재사용성
Item 19 knowledge를 반복하여 사용하지 말라
"프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다."
- Don't Repeat Yourself(DRY) = WET 안티패턴
knowledge
프로그래밍에서 knowledge는 넓은 의미로 '의도적인 정보'를 뜻한다.
중요한 2가지 knowledge
- 로직(logic) : 프로그램이 어떠한 식으로 동작하는지와 프로그램이 어떻게 보이는지
- 공통 알고리즘 : 원하는 동작을 하기 위한 알고리즘
모든 것은 변화한다
knowledge가 계속해서 변화하는 이유
- 회사가 사용자의 요구 또는 습관을 더 많이 알게 되었다.
- 디자인 표준이 변화했다.
- 플랫폼, 라이브러리, 도구 등이 변화해서 이에 대응해야 한다.
Knowledge 반복의 단점
- 프로젝트의 확장성을 막고, 쉽게 깨지게 만든다.
=>(대안) 하이버네이트와 같은 ORM 익스포즈드와 같은 DAO
언제 코드를 반복해도 될까?
knowledge 반복을 줄이면 안 되는 상황도 있다.
단일 책임 원칙
코드를 추출해도 되는지를 확인할 수 있는 원칙
(클래스를 변경하는 이유는 단 한가지여야 한다)
단일 책임 원칙은 2가지 사실을 알려준다.
- 서로 다른 곳에서 사용하는 knowledge는 독립적으로 변경할 가능성이 많다.
- 다른 knowledge는 분리해 두는 것이 좋다. 그렇지 않으면, 재사용해서는 안 되는 부분을 재사용하려는 유혹이 발생할 수 있다.
Item 20 일반적인 알고리즘을 반복해서 구현하지 말라
이미 있는 것을 활용하면, 단순하게 코드가 짧아진다는 것 이외에도 다양한 장점이 있다.
- 코드 작성 속도가 빨라진다.
- 구현을 따로 읽지 않아도, 함수의 이름 등만 보고도 무엇을 하는지 확실하게 알 수 있다.
- 직업 구현할 때 발생할 수 있는 실수를 줄일 수 있다.
- 제작자들이 한 번만 최적화하면, 이러한 함수를 활용하는 모든 곳이 최적화의 혜택을 받을 수 있다.
표준 라이브러리 살펴보기
가장 대표적인 라이브러리 : stdlib
나만의 유틸리티 구현하기
Item 21 일반적인 프로퍼티 패턴은 프로퍼티 위임으로 만들어라
코틀린은 코드 재사용과 관련하여 프로퍼티 위임이라는 새로운 기능을 제공한다.
- 지연 프로퍼티 : lazy 프로퍼티는 이후에 처음 사용하는 요청이 들어올 때 초기화되는 프로퍼티를 의미한다.
코틀린에서 프로퍼티 위임을 사용하면 간단하고 type-safe하게 구현할 수 있다.
코틀린 stdlib의 다음과 같은 프로퍼티 델리게이터를 알아 두면 좋다.
- lazy
- Delegates.observable
- Delegates.vetoable
- Delegates.notNull
Item 22 일반적인 알고리즘을 구현할 때 제네릭을 사용하라
- 제네릭 함수 : 타입 아규먼트를 사용하는 함수
제네릭은 List, Set 처럼 구체적인 타입으로 컬렉션을 만들 수 있게 클래스와 인터페이스에 도입된 기능이다.
이러한 타입 정보 덕분에 MutableList 에 안전하게 Int를 추가할 수 있습니다.
제네릭 제한
타입 파라미터의 중요한 기능 중 하나는 구체적인 타입의 서브타입만 사용하게 타입을 제한하는 것이다.
Item 23 타입 파라미터의 섀도잉을 피하라
Item 24 제네릭 타입과 variance 한정자를 활용하라
- variance 한정자의 안전성
Item 25 공통 모듈을 추출해서 여러 플랫폼에서 재사용하라
풀스택 개발
- 코틀린이 자바스크립트로 컴파일 될 수 있다는 점때문에 웹 백엔드와 프런트엔드를 모두 만들 수 있다.
모바일 개발
- 코틀린의 멀티 플랫폼 기능을 활용하면, 로직을 한 번만 구현하고, 두 플랫폼에서 이를 재사용할 수 있다.
라이브러리
- 플랫폼에 크게 의존하지 않는다는 점은 공통 모듈을 JVM, 자바스크립트, 네이티브 환경에서 작동하는 모든 언어에서 활용할 수 있다는 의미이다.
느낀 점
해당 장에서는 재사용성의 중요성에 대해서 강조하고 있다. 하지만 무조건적으로 재사용을 하는게 아니라 하지 말아야할 때를 해야할 때를 단일 책임 원칙을 활용하여 예시를 들어줬던 부분이 인상깊었다. Item 20번의 일반적인 알고리즘을 반복해서 구현하지 말라에서 1. 표준 라이브러리 살펴보기 2. 나만의 유틸리티 구현하기 파트에서 당연하지만 다시 한번 짚어보는 시간이 되었다.
또한, type-safe하게 개발하기 위해서 제네릭을 사용하거나 제네릭을 제한하는 방법을 안내하고 있다.
그 외 마지막 Item에서는 코틀린이 굉장히 범용적인 언어임을 나타내고 있고, 비슷한 느낌(Full-Stack)으로 JavaScript 언어가 떠올랐고, 두 언어의 차이에 대해서는 차차 찾아보고 학습할 예정이다.
주요 아젠다
- Kotlin으로 풀스택 개발하기 vs 백엔드, 프론트 분리하여 개발하기
Kotlin으로 풀스택 개발하기
Olive : 생산성 문제, 이점들을 커버할 만큼의 장점이 있는지를 정확하게 따져봐야할 것 같다.
Kuma : front가 back 보다 빠르게 발전하기 때문에 코틀린이 경쟁력이 있을지에 대한 의문이 있다.
charles : 개발자 풀 문제, 트러블 슈팅할 수 있는 레벨이 되기는 힘들 것 같다. 현실적으로는 힘들 것 같다.
- 재사용성을 저해하는 것들은 무엇이 있을까?
- 재사용성이 필요할까?
olive : 상황에 따라서 다를 것 같다. 재사용성이 떨어진다는 건 중복이 많이 발생할 수 있다는 관점에서 봤을 때, => 복붙
charles : 중복이 발생할 수록 재사용성이 올라간다.
Kuma : 어쩔 수 없이 재사용성을 침해하면서 코드를 작성할 때가 있는 것 같다. ex) 단발성 이벤트 같은 경우 실제 베이스가 된 실제 서비스에서 필요가 없는 경우가 있다. 예를들어 3일만 진행하는 이벤트, 기존에 있는 로직을 가져오다보니 유지보수 측면에서 안좋았다.
charles : 재사용에 대해서 명확하게, 로직이 같다고 같은 건 아니다. A, B가 같은 동작을 한다고 같은 건 아니다. Kuma님의 예제는 2개의 knowledge가 있다. kuma님의 예제 접근 방법이 올바른 방법이다.
kuma : 동작과 기능이 똑같다면 재사용을 할 수 밖에 없지 않나
charles : 20%의 코드가 80%의 성능을 발휘한다. -> 컴퓨터 공학에서는 함수 호출의 비용을 '0'로 가정한다. 재귀도 같은데, 현실에서 재귀를 하고 20%에 해당된다면 성능이 많이 낭비가 된다. 구조적으로는 좋지만, 20%의 코드에 해당되면 루프로 바꿔야한다.
Q. 언제부터 재사용성에 대해서 관심이 갖게 되었을까?
제일 처음의 컴퓨터 -> 애니악
애니악은 미사일 궤도를 계산하기 위한 용도로 나왔음.
각각 컴파일을 한 다음 링크라는 것을 한게 C언어
큰 프로그램을 만들 때 생기는 문제를 해결하기 위해서 재사용성에 대해서 관심을 가지게 되었음
Q. 파일을 왜 나누는것이 왜 중요할까?
컴파일 타임이 굉장히 오래걸린다.
파일이 커지면, 연산을 해야한다. 컴파일 타임에 앞에서부터 실행하는게 아니라 jump 등 에 대한 연산도 필요하기 때문에 현재 위치에서 offset 계산을 하려면 뒤를 읽어야지 어디로 jump할 수 있는지 address를 알 수 있다.
결론적으로 jump 등과 같은 것들에 의해서 컴파일 타임이 결정된다. 이러한 것들을 해결하기 위해서 파일을 나눈다.
프로그램이 커지면 재사용성이 필요하고, 작으면 필요없다.
Re) 재사용성을 저해하는 것들은 무엇이 있을까?
olive : SOLID에서 SRP라는 요소가 있는데, 역할과 책임이 잘분리가 되어 있어야하고 공통적인 요소를 잘뽑아낼 수 있어야하는데 예를들어 하나의 메소드가 너무 많은 책임을 가지고 있을 때, 재사용성을 저해한다고 생각한다.
그렇다면 책임을 분리를 하면, 재사용성이 올라가는가?
kuma : 제대로 된 기획이 이루어지지 않은채 진행이 되거나, 변경이 많이 되는 구조라면 재사용성이 저해된다고 생각한다.
charles : 공학적인 측면) 컴퓨터 사이언스에서 풀고 싶어하는 제1문제는 무엇일까?? -> P-NP 문제, 복잡성을 푸는 것이 공학이 하는 것이다.
복잡성이란 A가 증가할 때, B가 선형이상으로 증가할 때 복잡성이 증가한다고 정의했다.
복잡성이란 왜 나오는 것인가?
=> 의존성. 의존에 의해서 복잡성이 발생한다. 알고리즘이 어디에 의존하냐에 따라서 그래프의 모양이 다르다.
의존성이 재사용성과 어떤 연관이 있는가?
=> A함수가 B를 사용하는 것과, A함수가 C함수를 사용한다고 했을 때, 재사용한다고 정의한다.
=> A는 B와 C에 의존한다.
=> 의존성 다음이 SOLID
=> 결론적으로, 의존성이 올바르지 않으면 재사용성을 저해한다.
코틀린의 또 다른 장점) 유비쿼터스 언어로 쓸만한 언어인 것 같다. 아이디어를 표현해야하는데 예전에는 UML, ER다이어그램으로 표현했지만, java로 하면 굉장히 번거롭고 타이핑이 많아서 머릿속의 속도를 못따라간다. 하지만 코트린으로 표현하면 좋다. 따라서 Front, Back 을 개발할 때에도 아이디어 단계부터 재사용이 가능해서 좋다.
SOLID가 나중에는 필요가 없다. -> 비공학적인 개발자들을 위한 내용
