본문 바로가기
일기/우아한테크코스 3기

[우아한테크코스 3기] 레벨 1 - 2주차 회고

by 검프 2021. 2. 15.

한 주 명언

“You can never plan the future by the past.” —Edmund Burke
- 과거로는 미래를 계획할 수 없습니다. 

이번주는 설날이 겹쳐있어 실제로 공부한 양이 그렇게 많지 않습니다..ㅠㅠ

많이 쉬었으니, 다시 시작하는 마음으로 열심히, 꾸준히 해봐야겠습니다.

 

5Fs란?

1. Facts(한 것)

실제로 했던 일이나 겪었던 일의 사실을 적습니다.

2. Feelings(느낀 것)

일을 하거나 겪으면서 느꼈던 감정이나 느낌을 적습니다.

3. Findings(배운 것)

일을 하거나 겪으면서 새롭게 배운 점이나 알게 된 점을 적습니다.

4. Future Actions(할 것)

배운 점을 토태로 이후엔 어떻게 유지하고 개선할 것인지 적습니다.

5. Feedbacks(시간이 지난후 결과)

적절한 기간 이후 (저는 1달로 정함) 결과가 어떘는지 적습니다.

 

1. Facts(한 것)

데일리 미팅의 마스터가 시작됐다.

팀 프로젝트 (보이는 라디오)가 끝났다.

제이슨의 객체의 책임은 메서드가 정의되는 순간인가, 호출되는 순간인가?'에 대한 답을 했다.

제이슨에게 자동차 경주 게임에 대해 간단한 피드백을 받았다.

자동차 경주 게임 2단계를 완료하고, PR을 보냈다.

  • 리팩토링한 부분을 정리해서 제출했다.

수업이 끝나고 브라운 팀과 함께 수업의 의문점들을 공유했다

  • 의문점을 남기고, 지식을 공유할 슬랙 채널에 초대됐다.

이후 책읽기 스터디를 위한 레포지토리를 만들었다.

 

2. Feelings(느낀 것)

마스터때 진행을 어떻게 해야 크루원들을 더 잘 알 수 있을지 느꼈다.

  • 나를 밝힐 수 있는 질문들을 통해 게임을 진행하면 다른 크루원들을 더 잘 알 수 있을 거 같다!

팀 프로젝트를 진행할 때 어떻게 해야할지에 대해 느꼈다.

  • 많은 크루원들과 같은 목적을 위해 준비하는 것이 좋았다.
  • 계획이 너무 많을 땐 먼저 시작후 준비하자.
  • 이렇게 부담없이 즐기는 것들을 많이 했으면 좋겠다는 생각을 했다.

간단히 생각한 지식들은 실제로 많은 배경지식이 필요하다는 것을 느꼈다.

  • 정리는 힘들지만, 일단 한번 정리를 해야 이후에 다시보기 편한다.

크루원들과 지식을 공유할 수 있다는 것이 좋다.

사람들과 모르는 지식들을 공유할 수 있다는 점이 좋다.

 

3. Findings(배운 것)

변수 이름에 자료형은 사용하지 않는다.

# 나쁜 예
List<String> carNameList = new ArrayList<>();

# 좋은 예
List<String> carNames = new ArrayList<>();

Getter와 Setter를 의식적으로 사용하지 말자

객체에 메세지를 보내면 getter와 setter를 최대한 사용하지 않을 수 있다.

디미터 법칙을 준수하자

협력 경로를 제한하라.

객체의 내부 구조를 묻지 말고, 무언가를 시켜라.

디미터 법칙은 객체의 내부 구조를 묻는 메시지가 아니라 수신자에게 무언가를 시키는 메시지가 더 좋은 메시지라고 속삭인다.

자료구조형에서는 디미터 법칙을 준수하지 않아도 된다.

# 나쁜 예 (기차 충돌 혹인 메세지 체인이라는 말을 한다)
object.getChild().getContent().getItem().getTitle();

# 좋은 예
object.method(parameter);

Collections API를 적극 활용해라.

이부분을 따로 정리를 해야겠다.

원시값을 최대한 객체로 포장하라

원시값을 그대로 저장하는 것이 아닌, 객체로 포장하여 그 의도를 정확하게 들어낼 필요가 있다.

# 나쁜 예
String carName;

# 좋은 예
CarName carName; 

일급 컬렉션은 무조건 불변이 아니어도 된다. ( 개발자 마음 )

Collections.unmodifiableList는 참조 관계를 끊어주는 것이 아니다.

https://user-images.githubusercontent.com/48986787/107944863-22a53600-6fd2-11eb-91b1-3efc349d944a.png

주소는 그대로, add, remove, 만 없애주는 것

https://user-images.githubusercontent.com/48986787/107944911-318be880-6fd2-11eb-9a0f-c041e8c42e07.png

그렇기 때문에 생성자를 통해 객체를 새로 만들어 주는 것이 안전하다

코드 컨벤션은 포메터를 사용해서 맞춘다.

팀바팀 혹은 사바사로 포메터가 다르기 때문

풍부한 도메인(로직이 내부에 있다.) → 빈약한 도메인 (로직이 외부에 있다.)

내가 작성한 도메인이 풍부한지, 빈약한지 살펴볼 필요가 있다.

OCP: 개방 폐쇄 원칙

변경엔 닫혀있고 확장에 열려있다.

요구사항의 추가나 변경이 일어나도 클라이언트 코드에서의 변경은 없어야한다. 다형성의 축복을 여기서 느낄 수 있다...

 

4. Future Actions(할 것)

컬렉션 프레임워크와 java.util.Collections 클래스를 정리하자

Collections 클래스는 Collection 인터페이스를 구현한 클래스에 대한 객체생성, 정렬(sort), 병합(merge), 검색(search) 등의 기능을 안정적으로 수행하도록 도와주는 역할을 하는 유틸리티 클래스이다.

얉은 복사와 깊은 복사를 정리하자

언제, 어떻게 얉고 깊은 복사가 이루어 지는지 알아볼 필요가 있다.

객체의 책임에 대해 한번더 생각해보자

 

5. Feedbacks(시간이 지난후 결과)

댓글