이펙티브 자바 독서, 클린 아키텍처 정리, 프로젝트 템플릿 작성

오늘도 상당히 더운 날이었다. 그래도 오늘은 운동을 쉬는 날이어서, 그렇게까지 땀을 많이 흘리고, 열을 식혀야 하는 시간이 많지 않았다.어제도 잠을 잘 들지 못했는데, 그래도 목표한 시간에 일어나서 활동을 하기 시작했다. 역시나 아침의 시작은 독서로 시작하는것이 좋은 것같다.

 

---

독서: 이펙티브 자바

 

솔직하게 오랜만에 이펙티브 자바 책을 봤다. 어제 잠들기 전, 내일 해야할 일과, 남은 7월달을 계획하면서, 꼭 반드시 읽어야할 책을 정리하면서, 이펙티브 자바를 포함시켰기에.. 다시 눈에 들어와서 읽기 시작했다. 어제 머리 말리면서 읽다보니 한 30분을 본것같은데 진짜 이거 생각하면서 보기에 재밌다. 무튼 오늘도 이어서 책을 읽었다.

 

나는 현재 2장 객체 생성과 파괴 을 먼저 읽고 있으며, 한시간동안 아이템3 부터 아이템 6까지 총 3개를 읽었다.(지금보니 정말 속도가 느린듯하다..) 각 아이템 별로 내가 모르는 내용도 있었지만, 내가 사용하고 있던 부분도 있어 곱씹게 되면서 오래걸린듯하다.

 

 

---

아이템 3: private 생성자나 열거 타입으로 싱글턴임을 보증하라

 

싱글턴은 인스턴스를 오직 하나만 생성할 수 있는 것을 말하며, 나는 디자인 패턴을 공부하면서 처음으로 싱글턴을 공부했다. 뿐만아니라, 싱글턴을 공부하면서, 같이 공부하던 분들과 공부한 디자인 패턴을 설명도 하면서, 싱글턴 패턴이 안티패턴으로 불리기도 한다는 것을 알게되었다. 사실 나는 지금까지 개발을 진행하면서, 싱글턴임을 의도적으로 생성할 기회(필요)가 없었다. 그래서 단지 싱글턴을 어떻게 만들고 까지만 기억하고 있다.

 

책에서는 이런 싱글턴에 대하여 전형적인 예시를 이야기해준다. 싱근턴은 무상태(stateless) 객체나 설계상 유일해야 하는 시스템 컴포넌트를 이야기 할 수 있다고 한다. 그리고 싱글턴의 단점, 클래스를 싱글턴으로 만들면 이를 사용하는 클라이언트를 테스트하기 어려워질 수 있다고 소개한다. 그리고 어떻게 하면 싱글턴을 생성할 수 있는지에 대하여 총3가지의 방법을 소개해주는데, 이것이 왜 이펙티브 자바의 아이템3 으로 소개가 됬는지 나는 의도를 잘 모르겠다.. 분명 나도모르게 싱글턴으로 사용하고 있는 것들이 많거나, 싱글턴으로 개발되고 유용하게 활용되는 경우가 많아서 나온것 같은데... 흠.....

 

 

---

아이템 4: 인스턴스화를 막으려거든 private 생성자를 사용하라

 

나는이 아이템을 읽고서, 지난 Product 개발 간, 개발 했던 SelfValidating 이 생각이 났다.

 

지난 신발 주문 시스템의 Product 개발간 SelfValidating 을 추가했다.

 

이 코드를 보는 호기심이 많은(?) 사람은 궁금할 것이다. 왜 abstract (추상클래스)인거지? 그리고 이 질문은 실제로 PR 코드리뷰간에 질문으로 달리기도 했다.

 

지난 PR의 일부분, 동연님이 감사하게 질문을 남겨주셨다.

 

인스턴스화가 되지 말아야 하는 클래스를 어떻게 인스턴스화를 막을 수 있을까? 에 대한 정답으로 책에서는 private 을 이야기했다. 알고 있던 부분이었지만, 조금 의문이었던 것이, 책에서는 추상클래스로 만드는 것으로는 인스턴스화를 막을 수 없다. 이야기 했다. 하위 클래스를 만들어 인스턴스화 하면 그만이다. 라는 이야기를 남겨놨는데, 아마도 아이템 4 에서는 아예 일절 인스턴스화를 막는 방법을 이야기 하는 듯하다.(private 생성자는 상속까지 막아버리니깐말이다.)

 

그리고 인스턴스화를 막을 때, 좀 더 직관적으로 하기 위해 다음 방법을 추천했다.

 

public class UtilityClass {
	// 기본 생성자가 만들어지는 것을 막는다(인스턴스화 방지용) // 주석을 추가한다.
    private UilityClass() {
    	throw new AssertionError();
    }
    ... // 나머지 코드 생략
}

 

꼭 에러를 던질 필요는 없지만, 에러를 던져 생성이 되는것을 막았다는것을 표현하고, 좀 더 직관적으로 표현하기위해 주석을 사용하라 추천했다.

 

---

아이템 5: 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

 

이부분은 정말 기초적(?) 이면서 상당히 중요한 내용이라는 생각이 들었다. 흔히 말하는 의존성 주입이며, 객체간 느슨한 결합을 위해 반드시 필요한 부분이기 때문이다. 책에서는 느슨한 결합에 대한 이야기가 언급하지 않고, 다른 이야기를 했다. 그래서 조금 오잉?? 했다.

 

내용이 살짝 엉뚱하다는 느낌을 받았다. 클래스 내부가 하나 이상의 자원에 의존하고, 그 자원이 클래스 동작에 영향을 준다면 싱글턴과 정적 유틸리티 클래스는 사용하지 않는 것이 좋다. 이 자원들을 클래스가 직접 만들게 해서도 안된다.(강력한 결합) 대신 필요한 자원을 생성자(혹은 정적 팩터리나 빌더에) 넘겨주자. 의존 객체 주입이라는 거법은 클래스에 유연성, 재사용성, 테스트 용이성을 기가막히게 개선해준다.

 

물론 의미하는 것이 결국 같긴했지만, 보면서 오잉 오잉?? 했었다. 그리고 무엇보다, 새로운 지식을 알게되었다. 자바 8에서 부터 지원하는 Supplier<T> 인터페이스와, 의존성 주입을 정적 팩터리를 통해 사용할 수 있다는 사실말이다.

 

---

아이템 6: 불필요한 객체 생성을 피하라(=기존 객체를 재사용 해야한다면 새로운 객체를 만들지 말자)

 

마지막 아이템 6는 선배가 전해주는 꿀팁(?) 처럼 들렸다. 그리고 지난 개발간, 메서드에서 인스턴스화를 신경을 썼는가? 에 대한 생각과, 내가 공부했던 디자인 패턴(플라이웨이트)에 대한 생각을 다시 하게 되었다.

 

먼저 책의 내용은 이렇다.

 

• 똑같은 기능의 객체를 매번 생성하기보다는 객체 하나를 재사용하자
• 생성자 대신 정적 팩토리 메서드를 사용하자
• 생성 비용이 비썬 객체는 캐싱하여 재사용하자
• 박싱된 기본타입보다는 기본 타입을 사용하고, 의도치 않은 오토박싱을 주의하자.

먼저 1~3은 들어본 내용이고, 마지막 4는 처음 들어보는 것이었다. 그런데 처음들어본것 말고도 들어본내용에서도 오잉? 하는것들이 있었다.

 

요즘의 JVM에서는 별다른 일을 하지 않는 작은 객체를 생성하고 회수하는 일이 크게 부담되지 않는다. 프로그램의 명확성, 간결성, 기능을 위해서 객체를 추가로 생성하는 것이라면 일반적으로 좋은 일이다. 아주 무거운 객체가 아닌 다음에야 단순히 객체 생성을 피하고자 우리만의 객체 풀(Pool)을 만들지 말자.

 

일단 먼저, 값이 비싼 객체의 기준은 무엇이고, 어느 수준까지가 작은객체인거지.. 하는생각과 내가 생각하는 객체풀이 결국엔 재사용을 위한 (플라이 웨이트 패턴) 것인데, 안좋다고하니... 음..... 다시 생각이 많아지게되었다. 하지만 답은 내리지 못했다.

 

그리고 이번 아이템 6에서의 배움은 여기서 멈추지 않았다. 정말 꿀팁처럼 들렸던 것은 바로 마지막 부분이다.

 

기존 객체를 재사용해야한다면, 새로운 객체를 만들지말자.
하지만, 새로운 객체를 만들어야 한다면 기존 객체를 재사용하지 말자.

 

비슷한듯 다른 이 말이 오랜 생각을 하게하는 것은 덤이고, 지난 내 모습들이 싸악 ~ 지나가게 하는 말이었다. 얕은 복사, 깊은 복사 부터 시작하여, 개발 간, 비슷한 객체를 복사해서 사용했던 순간들, 또 객체를 만든 순간들.. 다양하게 생각이 많이 났다.

 

이펙티브 자바는 정말 재밌는 책인 것 같다. 어렵고 모르는 내용도 많지만, 다양한 주제로 또 해당주제로 많은 꿀팁들이 많은 것 같다. 이와 관련하여 다른 개발자들과 함께 공부하거나 이야기도 하면 좋을텐데.. 이 부분은 조금 아쉽다.

 

---

git Issue Template 추가

 

git issue 등록을 위한 템플릿을 만들었다.

 

나는 어제, Product Wiki 수정을 확인하고(다시 보니, main에만 반영이 안된 것이고, Wiki 에는 정상 반영이 되어 있었다.) 이슈를 등록하려는 찰나, 지금 이 첫 이슈가 중요할 것 같다는 생각이 들었다.

 

나는 기존 STUDY 레포와 지금 신발주문시스템 의 PR 작성에 템플릿을 사용하고 있다. 기존의 STUDY 레포에서는 이슈를 사용해보려다가 내가 잘 활용하지 못하여(필요성을 못느꼈다.), PR로만 내용을 정리하였다. 그런데 이번 신발 주문 시스템의 경우에는 Issue 로 관리가 되는 것이 좀 더 체계적이고, 나중에 실무에서의 도움이 될 듯하여, 템플릿을 작성하였다.

 

 

이슈템플릿 중 feat 템플릿의 모습

먼저 나는 이슈로 작성될 수 있는 경우를 고민해보았다. 기본적으로 깃허브에서 제공하는 템플릿을 참고하였는데, bug, feature 가있었고, 나는 리팩토링을 진행할 것이기에, 또 리팩토링을 feature 혹은 bug에 분류하기에는 다소 난감하여 refactor 템플릿을 생성했다.

 

템플릿을 생성하는데 시간이 꽤 오래걸렸다.(약 3시간..) 이렇게 까지 고민이 될 내용이가 싶지만.. 과거 Issue 사용했던 경험에서 왜 내가 실패(필요성을 못느낌)했을까?, PR 템플릿 사용간 불편한 점은 무엇이있었지? 하는 고민 때문에 오래걸렸던 것 같다.

 

나는 처음에는 분류가 많았다. 설명, 허용기준, 관련문제, 작업량, 마감일 등등.. 모든것을 제목으로 분류했었다. 그런데 이렇게 하면 내 스스로가 하기 힘들어할 것같아, 꼭 필요한 부분이자 내가 상황에 맞게 조절할 수 있는 그런 항목만 남겨두었다. 그리고 해당 부분을 작성하는 데있어 도움이 되도록 가이드 주석을 추가했다. 아직 부족하겠지만, 지금은 이렇게 만들어서 한번 프로젝트를 개발 및 유지보수 해보려고한다.

 

그리고 작업을 하다보니, 제목만으로도 구분이 가능하지만, 많아졌을 때, 해당 작업을 간편하게 모아 확인하는 것이 필요할 것으로 판단, 이를 해결해 줄 수있는 좋은 도구인 라벨을 처음 사용해보기로 결정하였다.

 

알록달록 이쁜 7 공주 라벨들

 

해당 라벨은 검색 간 참고하기 좋은 블로그의 글을 보고 참고했다.

 

좋은 개발 환경만들기 Label, PR, ISSUE 템플릿

 

---

벌써 내일이면 금요일이다. 그리고 내일은 아버지 생신으로 오후에는 잠시 공부를 뒤로하고 행복한 시간을 보내려고한다. 그래서 내일은 아침부터 정말 바쁠 예정이다. 운동도 다녀오고, 오후 가족들이 모이기 전까지 목표량을 해결해야한다..!  할 수 있다!! 아마도 !!!

 

근데 나 생각해보니깐 오늘 웹 어댑터 개발해야하는데 안했네.. 하고 자야겠다..

 

이슈도 등록깜빡했네..... 이런...