한 주 명언
"if you want something new you have to stop doing something old - Peter Drucker"
- 새로운 것을 원한다면 오래된 것을 그만둬야합니다. 코니라는 좋은 리뷰어를 만나. 지금까지 가지고 있던 습관들은 전체적으로 바꾸는 연습을 했던 헌 주였습니다.
가지고 있던 오래된 습관들을 버리는 것은 힘이 듭니다. 하지만 낡은 것들을 놓지 않는다면 새로운 것을 얻을 수 없습니다.
5Fs란?
1. Facts(한 것)
실제로 했던 일이나 겪었던 일의 사실을 적습니다.
2. Feelings(느낀 것)
일을 하거나 겪으면서 느꼈던 감정이나 느낌을 적습니다.
3. Findings(배운 것)
일을 하거나 겪으면서 새롭게 배운 점이나 알게 된 점을 적습니다.
4. Future Actions(할 것)
배운 점을 토태로 이후엔 어떻게 유지하고 개선할 것인지 적습니다.
5. Feedbacks(시간이 지난후 결과)
적절한 기간 이후 (저는 1달로 정함) 결과가 어떘는지 적습니다.
1. Facts(한 것)
1단계 피드백을 수정후 코니에게 리뷰 요청을 보냈다.
빠르게 피드백을 받고싶어 피드백에 대한 질문을 DM에 정리해 보냈다.
DM 피드백을 받았다.
근로 장학생을 신청했다.
자바 문법 및 개념의 이해 수업을 들었다.
- Exception 강의를 들었다.
데일리 마스터를 했다.
- 브라운 팀의 갤러리를 진행했다.
랜선 회식을 했다.
2단계 pr을 날렸다.
- 피드백을 받았다.
테코톡을 들었다.
인비의 DTO, VO 테코톡을 들었다.
제리의 MVC테코톡 강의를 들었다.
whiteShip 6주차를 끝냈다.
공변성 불공변성을 알게됐다.
포비에게 번아웃이 오지 않는 법에 대한 수업을 들었다.
- TDD로 만드는 로또게임 수업을 들엇다.
- 내 코드가 수업중에 보여지게 됐다. ( 언제 내 코드가 공개될지 모른다.. )
2단계 피드백을 수정후 코니에게 리뷰 요청을 보냈다.
컬렉션 프레임워크를 정리했다.
로또 게임이 최종 merge됐다.
2. Feelings(느낀 것)
이번주도 무엇을 배웠는지 정리해야할 필요성을 더 알게됐다.( 엄청난 피드백을 받았다..! )
코드작성의 이유를 정확히 하지 않고 있었다는 것을 알게 됐다.
- 그냥 익숙하니까. 좋아보여서 라는 이유로 코드를 작성했었다.
- 그러다 보니 코드 작성의 이유를 정확히 말할 수 없었다.
부끄러웠다. - 또한, 누군가 내 코드를 봤을 때 충분히 납득할 만한 이유도 말할 수 없었다.
- 코드에 나의 생각이 없었기 때문이다.
정답은 없다. 그렇기 때문에 내가 정답을 가지고 있어야하고, 그 정답에 대한 명확한 이유가 있어야 한다.
코드를 보는 시간이 적다는 것을 알게됐다. (사실 아직 잘 모르겠다. 코드 작성이 끝나면 뭔가 더 나은 방향이 없다는 느낌이 든다. )
- 어색한 부분이 있는지, 정말 책임과 협력이 잘 나왔는지 더 자세히 봐야할 거 같다.
공변, 불공변을 처음들었다. 공부해야 할 것이 만하든 것을 느꼈다.
데일리 마스터를 하며 브라운 팀의 크루들에 대해 조금더 알게된거 같아서 좋다.
- 빨리 만나서 더 많은 얘기를 나누고 싶다.
브라운팀에서 랜선 회식을 했는데 2시간동안 정말 많이 웃고 떠들었다.
- 이또한 실제로도 회식을 하고싶다.
테크톡 발표를 어떻게 하면 좋을지에 대해 어렴풋이 알게됐다.
- 청중이 전혀 모른다는 가정하에, 누군가 내 강의를 보고 정리할 수 있을만큼 준비해야겠다.
질문을 할때엔, 나의 정답을 가지고 말하는 것이 좋다는 것을 느꼈다.
- 나는 이렇게 생각했다~~ 혹시 상대의 생각은 어떤가?
무서워하지 말자, 하루하루 차근차근 나의 속도로 걸어나가자.
3. Findings(배운 것)
현재 할수 잇는 일을 고민하라 (먼 미래의 확장성을 고려하지말자)
미래에 사용되겠지~ 하며 확장성을 위해 열어놨던 생성자, 매소드, 객체 등을 잠시 내려놓고. 지금 현재 있는 객체들이 가져도될 책임인지 충분히 고민하자.
코드 작성의 이류를 깊게 고민하라(그냥 쓴다? no!!)
남이 작성한 코드, 좋아보이는 것들을 그냥 쓰면 내것이 되는게 아니다.
한줄 한줄 이유가 있어야한다.
동일성(대칭성)을 생각하자
add가 있으면, remove가 있는게 자연스럽다.
책임을 잘 생각해보자
InputView는 입력을 요구한다. (이때, 입력 요구 앞의 출력문은 같이 있는게 덜 어색하다)
Screen을 무조건 나누는 것은 능사가 아니다.
즉,
input을 위한 메시지는 input에
출력을 위한 메시지는 output에
정적 팩토리 메소드가 꼭 필요한 시점이 언제일까 고민하라
- 이름이 있으므로 생성자에 비해 가독성이 좋다.
- 호출할 때마다 새로운 객체를 생성할 필요가 없다.
- 하위 자료형 객체를 반환할 수 있다.
- 형인자 자료형(parameterized type) 객체를 만들 때 편하다.
위와 같은 장점을 누릴 수 있는 경우에 정적 팩터리 메서드를 사용하는 것은 정말 좋죠. 그런데 of()나 valueOf() 같은 특별히 의미를 더하지 않는 이름에, 메서드 안에서 단순히 생성자를 이용하고 있다면 그냥 생성자를 이용하는 편이 더 명확할 수 있다.
즉, 생성자와 정적 팩토리 메소드가 같은 타입의 인자를 받으면 둘이 그냥 차이가 없는 것 같다고 생각하자.
코니의 말씀처럼 결합도는 낮게 응지도는 높게! , 적절한 책임이 무엇인지 한번더 생각해보자.
자바 Exception
Checked와 Unchecked Exception이 있다.
Checked Exception
Exception을 상속한다.
컴파일 시점에 Exception을 catch하는지 확인한다. 즉, 컴파일 시점에 Exception에 대해 처리를 하지 않을 경우 컴파일 에러가 발생한다.
Unchecked Exception
RuntimeException을 상속한다.
컴파일 시점에서 확인하지 않고 런타임 시 발생한다.
Exception이 발생하는 메소드에 Throws 예약어를 통해 처리할 필요가 없다. (처리해도 무방)
Checked vs Unchecked
checked는 명시적으로 throw해줘야 하지만 Unchecked는 안해줘도 된다.
try안에서 날린 예외는 그다음 catch에서 잡지 않음 (당연하다.. if문과 같다고 보면됨)
우리는 주로 UnchkedExcpetion을 사용한다. (작성 하는 코드의 exception은 대체로 런타임에 일어나기 때문)
하지만 Exception을 통해 뭔가 의미 있는 작업을 한다면 (exception이 명확하다면 ) Checked 를 써도 무방함.
즉, 치명적이면 checked exception (라이브러리나 프레임워크를 사용하는경우엔 사용해아함)
굳이 경고를 안하고 싶고, 서비스 단에서는 Unchecked Excpetion을 사용한다.
가변인자
가변인자는 내부적으로 배열로 변함
Integer 클래스의 캐싱
위에는 통과, 밑에는 실패한다 그 이유는?
@Test
void integer1() {
Integer a = Integer.valueOf(127);
Integer b = Integer.valueOf(127);
Assertions.assertThat(a).isSameAs(b);
}
@Test
void integer2() {
Integer a = Integer.valueOf(128);
Integer b = Integer.valueOf(128);
Assertions.assertThat(a).isSameAs(b);
} → 클래스 내부적으로 -127 ~ 127까지는 캐시가 되어있다.
문서보단 코드와 테스트코드에 예외에 대해 명시적으로 표현하자
문서란 게 낡기 마련이라 계속 업데이트하기가 정말 힘들다 .
웬만하면 코드와 테스트 코드에 항상 명시적으로 표현해 주는 것이 좋다.
Collections.emptyList() 사용하기
빈 컬렉션을 반환할 땐 new ArrayList<>() 말고 Collections.emptyList()를 사용하자.
불변을 보장하고, empty임을 더 잘 드러낸다.
DTO vs VO
이부분은 따로 또 정리해보자.
쉽게 vo는 값 자체를 표현, dto는 레이어간 데이터 전달에 쓰인다.
MVC 패턴
이부분도 따로 정리하자
쉽게 Model은 데이터와 관련된부분, View는 사용자 한테 보여지는 부분, Controller는 Model과 View를 이어주는 부분이다.
개념 관점(Conceptual Perspective), 명세 관점(Specification Perspective), 구현 관점(Implementation Perspective)
순차적인 것이아닌 함께 동작한다.
쉽게, 개념관점은 도메인을 설계하는 시점, 명세 관점은 메세지를 설계하는 시점, 구현 관점은 코드를 작성하는 시점이다.
실제 인스턴스가 어떻게 될진 구현관점에 이루어진다.
아웃사이드 인 방식이 아닌 인사이드 아웃 방식을 사용하라
나만의 속도대로 나만의 지식을 늘려나가라. 외부에서 좋다고 하는거 따라하다 금방 지친다.
즉, 적당히 무시할 수 있는 단단한 멘탈이 있어야한다.
한번에 한 가지에 집중하는 것이 습관(변화)를 만드는 가장 빠른 길이다.
가장 필요한 것은 가보지 않은 길에 꾸준히 도전할 수 있는 용기.
작은 성공을 하나씩 맛보자.
기능목록은 다른사람을 보여주기 위한게 아니다
내가 이해하기 쉬우면 됨
먼저 스태틱을 먼저 주고 나중에 변경해도됨
클래스 메소드를 만들고 나중에 인스턴스 메소드로 수정
메소드에서도 유효성 체크를 하는경우도 많다
생성자가 아닌데서도 유효성 체크를 많이 한다.
작은 테스트도 다 해라
public으로 열러있는 것들은 다 하자. 객체도 마찬가지
부생성자 주 생성자
생성자가 할 수 있는 일이 많아진다. (사용성이 높아진다.)
(포비)생성자가 많으면 많을수록 편해집니다
(제이슨)생성자와 메서드는 다릅니다.
미션에서는 학문을 실제에서는 엔지리어링
너무 스트레스 받지 말자!
유효성 검사 시점은 언제가 좋을까?
유효성 검사 시점을 외부에 둘건지, 해당 도메인 객체 내부에 둘건지 나눌 수 있다. 생성 자체에 대한 유효성 검사라면 정적 팩토리 메서드 패턴, 비즈니스 로직 자체에 유효성 검사라면 도메인 객체 내부
일급컬렉션은 도메인으로 생각하자.
하나의 도메인이다 (값 객체가 아니다. 자료구조라 생각하자. )
동일한 로직에선 동일한 프레임워크를 쓰는게 자연스럽다
당연히 전체적으로 컬렉션 프레임워크를 맞춰야 한다! 그런 건 없죠. 그런데 동일 로직을 굳이 다르게 할 필요는 없지 않나 싶어 드린 코멘트였습니다. 수동 로또든 당첨 로또든 6개의 숫자를 입력받아 LottoBalls 객체가 되고, 이에 관련된 비즈니스 로직(중복 없어야 함, 6개여야 함...)은 동일하니까요.왠만하면 맞춰주자
4. Future Actions(할 것)
DTO vs VO 정리
Checked Exception vs Unchecked Exception 정리
Collectors 클래스의 유틸성 메소드 정리
댓글