8/17 TIL | 구체적인 액션 플랜 필요! 근데 이제 집중력을 곁들인

 

📝 TIL 작성 가이드
1) 오늘 한 일, 느낀 점, 배운 점을 작성한다. (3Fs, 1~3번에 해당)
2) 앞으로 개선할 점 등 어떻게 하겠다는 실천계획을 구체적으로 작성한다. (Future Action Plan, 4번에 해당)
3) 다음 TIL을 작성할 때 FAP가 제대로 지켜졌는지 피드백을 작성한다. (5번에 해당)

- 참고: 5Fs, 뒤돌아보다

---

1. Facts (사실, 객관)

- 아침에 코딩 테스트 문제를 풀었다.
- 목표했던 퀘스트 과제 다 했다. (삼천 줄 코드 미포함)
- 리뷰 받은 코드 리팩토링을 시작했다.

2. Feelings (느낌, 주관)

1) 슬슬 루틴에는 익숙해지고 있음.
오늘은 벌써 주중 학습 3일차.. 어리버리했던 첫날 이튿날과는 달리 이제야 좀 익숙해지는 느낌이다. 물론 아직까지도 시간 활용을 제대로 하는 거 같지는 않지만, 이 부분은 어떤 부분에서 시간이 새고 있는지 하루 일과를 적어보고 분석해야겠다.

2) PR 작성을 칭찬받아서 보람찼음.
과제 별로 PR을 올릴 때마다 결과화면 뿐만 아니라 배운 것과 고민한 부분들을 같이 적어서 올렸다. 실무에서는 PR을 이렇게 활용하지 않지만 뭔가 커밋한 코드들을 한눈에 볼 수 있는 PR에 작업 일지를 같이 적으면 좋을 거 같다 싶기도 했고, 어차피 공부용 레포지토리이니까 이것저것 작성을 했는데, 노아 트레이너님이 남겨주신 리뷰를 보고 더 열심히 작성해봐야겠다는 동기부여가 뿜뿜! 그리고 이 PR로 흘려보내지 않고, 주말 학습 시간에 PR에 작성한 작업 일지를 노션에 따로 정리 + 코드 리뷰 내용 정리를 해야겠다.

3) 내 머리로 생각해서 코드를 작성해내는 것이 좀 신기하고 대견함.
사실 이건 개발자면 당연한 거 아냐? 생각할 수 있는데 그래도 무슨 문제를 봐도 어떻게 푸는 거지..?라는 생각이 앞섰던 예전과는 확연히 다르다. 문제를 보고 강의 내용을 토대로 이건 어떤 식으로 풀어내야 하는 건지 먼저 의사 코드를 작성하고, 바로 그것을 구현하기 위해서는 어떤 메서드를 사용하고 어떻게 해야겠다. 하는 생각들이 바로 바로 떠오르는 게 좀 대견했다..ㅋㅋㅋ 그동안 했던 공부들은 뭐지 싶을 정도로 아직 1주일도 되지 않은 시간 동안 엄청 많은 걸 배워가는 중이다!👍🏻

3. Findings (배운 점)

1) 구체적인 액션 플랜을 세우자
오늘 홀맨님이 구체적이고 유의미한 액션 플랜을 도출해내라는 피드백을 주셨다. TIL의 4번에 항상 FAP를 적고 있는 사람으로서 과연 내가 구체적이게 액션 플랜을 작성하고 있는지 되돌아보는 시간을 가졌고, 이거로는 부족하다는 판단이 들었다. 그래서 그럼 어떻게 작성하나요.. 하는 질문을 다시 드렸고, "실질적으로 실천 여부를 정확히 체크하고 피드백 할 수 있는지가 중요하죠. 수치화될수록 좋습니다. 막연히 '일찍 일어나겠다~' 이런 건 아무 의미 없죠." 라는 피드백을 받았다. 그렇기에 앞으로의 FAP는 정성적인 내용은 지양하고, 정량적으로 적어보자!

2) ==과 equals()의 차이
지난번 문제를 풀면서 String을 비교하고자 할 때는 equals() 메서드를 쓴다고 이해했었는데, 막상 아래와 같이 ==으로 작성해도 비교가 되는 것이다.

String paper = "보";
String computerPick = "보";

System.out.println(paper == computerPick); // true 반환

아니.. 문자열은 ==으로 비교할 수 없는 거 아니었어..? 하고 찾아봤더니 == 연산자는 주소값을 비교한다고 한다. 리터럴을 사용하게 되면 string constant pool이라는 영역에 존재하게 되는데, 리터럴로 선언한 경우 내부적으로 String의 intern() 메서드가 호출되게 되고 intern() 메서드는 주어진 문자열이 string constant pool에 존재하는지 검색하고 있다면 그 주소 값을 반환하고 없다면 string constant pool에 넣고 새로운 주소 값을 반환하는 원리!

이런 특성 때문에 String을 비교하고자 할 때는 equals()를 쓰는 것이다. equals()는 주소값이 아닌 값을 비교하는 것이기 때문에 원하는 결과를 얻을 수 있다.

- 참고 블로그

3) git pull 사용을 지양하자.
나는 그동안 항상 pull 받을 때 git pull 명령어로 받아왔는데, 동기분 중에 한 분이 웬만해서 사용하지 않는 게 좋다는 피드백을 주셨다.

- git pull 사용을 지양해야 하는 이유: 터미널 명령어를 입력한다는 건 기본적으로 내가 어떤 실행을 명령하는 건지 구체화되어야 한다. 그래서 git fetch 보다는 git fetch upstream main을, git rebase 보다는 git rebase upstream/main을 해주는 것이 좋다. 모든 명령어는 내가 정확히 원하는 결과로 만들어 낼 수 있게 하기 위함이고, 정확하지 않으면 언제고 내가 원하지 않는 어떤 미지의 변화가 생길 수밖에 없는 것! 그렇게 되면 통제하기가 매우 어려워진다. 더군다나 git pull은 기본적으로 fetch와 merge이기 때문에 내가 하려 했던 fetch와 rebase와는 동작 구조가 다르다. 물론 git pull에도 rebase 옵션이 있지만 굳이 옵션을 쓰기보다 더 명확하게 명령어를 입력하는 게 좋다.

- 추가적으로 그동안 나는 브랜치를 전환할 때 git checkout {브랜치명}으로 했었는데, checkout 또한 기능이 너무 많기 때문에 git switch와 git restore를 사용하라는 사실도 알 수 있었다. (참고 블로그)

4. Future Action Plan (미래의 행동 계획)

- 주말 학습 시간에 주중에 올린 모든 PR의 작업 일지를 노션에 문서화하면서, 동시에 리뷰 주신 내용도 함께 정리하자.

- 항상 오후 4시부터는 집중력이 떨어지기 때문에 이때 진행하는 뽀모도로에는 철저하게 50분 작업, 10분 휴식을 지켜보자. 50분 작업 때에는 화장실도, 집중력이 깨지는 행동을 절대 하지 말 것! + 요가를 주 3회는 꼭 가자!

5. Feedback (피드백)

(내일 채워질 예정 💬)

---

무튼 오늘은 여러모로 집중력이 필요하다고 절실히 느꼈다. 순간적으로 몰입하는 능력, 그리고 그걸 지속하는 지구력이 필요하다! 그러니 열심히 요가를 하자~(갑분 요가 마무리)