[우아한테크코스 5기] 1주차 후기

기간: 2023/02/07 (화) ~ 2023/02/12 (일)

 

온보딩 기간으로 크게 수업, 연극 준비, 페어프로그래밍을 하게 된다.

온보딩으로 연극을 하는데 1일차부터 추노하고 싶었다.. ㅋㅋ

 

1. 연극

연극의 경우엔 주제 선정부터 뭘해야할지 고민했는데, 크루들이 다들 좋은 주제를 말해가지고 생각보다 쉽게 선정한 것 같다.

온보딩 크루들이 나 말고는 인싸 같았고, 나 혼자 템포를 못쫓아가서 나와는 완전히 다른 분위기라 우테코를 괜히 했나..?? 라는 생각도 많이 들었다 😭

우리 학교는 엄청 작기 때문에 다들 건너건너 이름을 자주 들었던 사람들이라 이미 다들 누군지 어느정도 알고 있는 상태에서 만나서 크게 부담감이 없었다. 그런데 처음 보는 사람들끼리 만나서 이야기를 나누니까 이거만큼 힘든 일도 없는 것 같다.

연극을 하는데 다행인점은 다른 크루들도 힘들지만 다들 열심히 하니까 다행이라고 말해서 나만 힘든게 아니였구나라고 안도감이 들었다.

다음주 월요일에 연극을 하는데 빨리 월요일이 지나갔으면..

 

 

 

2. 페어 프로그래밍

온보딩 페어 프로그래밍으로 자동차 경주 미션을 진행했다.

페어는 온보딩 조인 로이스와 했는데, 로이스 덕분에 제대로된 온보딩을 해서 다행이라는 점도 있었고, BOJ 티어로 따지면 브론즈가 된 기분이었다. 로이스에게 본받을 점이 엄청 많았다.

• 현란한 인텔리제이 단축키 사용
• 자연스럽게 사용하는 디자인 패턴
• 객체지향으로 설계하는 방법
• 변수명을 더 좋게 짓는 방법
• 조금이라도 더 책임을 분리시켜 덜 의존적인 객체를 만들기

 

처음엔 페어 프로그래밍을 하면 좋은 점이 있을까? 라는 생각을 했지만, 막상 해보니 꽤나 많은 장점을 가지고 있었다. 누군가에게 이야기하며 코드를 작성하니까 내가 생각보다 자바 기초에 대해서 모르고, IDE 자동 완성 기능에 매우 많은 의존을 한다는 점이다. 거기다가 코드를 왜 이렇게 작성해야 하는지 이야기를 꾸준하게 하니까 '내가 이런 코드를 작성하는 이유'를 말해야하는 실력이 확실히 늘어나는 느낌이다.

 

생각보다 코드를 어떻게 작성해야할지 이야기할 내용도 많았다. 검증 기능만 하더라도, 이 기능을 view에 넣을지, domain에 넣을지, validator라는 패키지를 만들어서 관리할지, 아니면 각자 필요한 곳에 나누어서 관리할지 이야기를 해봐야한다. 여기서 끝이 아니다. 어디에서 검증이라는 책임을 담당할지 이야기를 끝냈다면 어떻게 코드를 작성해야할지 이야기를 해봐야 한다. static을 사용하는게 맞을지, 일반 클래스로 사용할지, interface를 만들고 상속을 받을지, 의존성을 객체 외부에서 주입한다면 객체 생성자에 파라미터 하나가 더 추가되는 것인데 이게 더 좋은 코드가 맞을지... 어질어질하다.

 

알고리즘에서 왜?라고 물어보면 그게 정답이기 때문에 자신있게 말할 수 있었는데, 개발은 정답이 없으니 왜?라고 물어보면 내가 맞나?라고 스스로를 의심했었다. 그런데 오늘 돌이켜보니 스스로에게 질문을 던지는 것보다 내가 그렇게 생각한 이유를 말한다음 상대방 의견을 듣고, 상대방 의견이 더 좋은 의견이라면 생각을 고쳐나가는게 정신적으로도 개인 실력 향상에도 좋아보인다.

 

 

 

3. 코드 리뷰

미션을 할 때마다 코드 리뷰를 받는다. 코드 리뷰는 이전에 우테코를 했던 분들이라고 이야기를 들었다.

리뷰어님이 코드 리뷰를 해주시는데, 여기서도 생각해볼 내용이 많았다. 리뷰어님이 규칙도 알려주시고, 여기서도 왜 이런 클래스를 만들었는지, 코드를 작성했는지에 대해 이유도 물어보기 때문에 큰 도움이 되었다. 그리고 리뷰어님이 주말 저녁에 줌을 켜주셔서 많은 내용을 물어봤다. 특히 이 날은 내가 대학교 다니는 동안 너무 쓸모없는 내용만 배웠나 생각하며 멘탈이 나가있어서 아무것도 못하고 있었다가 덕분에 빠르게 정신을 차리고 나머지 기능 목록을 수정했다.

주말에 줌을 키고 알려주실 줄은 꿈에도 몰랐는데, 확실히 코멘트를 읽고 스스로 생각해보는 것보다 줌을 통해 질문에 대한 답변을 얻으니까 더 많은 내용을 알 수 있었다. 특히 줌이 아니었으면 주말 내내 멘탈이 나가있었을지도 모르겠다 ㅋㅋㅋ

 

 

 

4. 새롭게 알게된 점

- IntelliJ Mac 단축키 사용법

 

- 객체지향 생활체조에서 getter를 만들지 말라는 이유는 getter가 캡슐화를 위반하기 때문이다. 그렇다고 getter를 아예 사용하지 않는 것보다 적당한 타협이 필요하다.

 

- 생성자 대신 정적 팩토리 메소드를 사용하면 객체지향 설계를 지킬 수 있다. (of는 파라미터가 1개일 때, from은 파라미터가 2개 이상일 떄 사용한다.)

 

- toString, equals, hashCode의 오버라이딩하여 작성하는 기준이 존재한다. 그래서 이것과 비슷한 기능을 만들어야 한다면 다른 이름을 사용하는게 좋다.

 

---

 

자신감이 확 떨어졌는데, 바닥부터 시작해서 올라온 일은 많으니 이것도 처음에만 힘들지 버티다보면 언젠가는 많이 성장할 것이라고 생각한다. 그리고 정말 다행인 점은 우테코를 시작하기 전에 객체지향 서적을 읽었다는 점이다. 특히 객체지향의 사실과 오해 책을 읽은게 매우 큰 도움이 되고 있다.

 

이번에 일주일동안 느낀점은 개발에 정답은 없다는 것이다. 알고리즘을 너무 많이 해서 그런지 자꾸 개발에서 정답을 찾게 되는데, 자동차 경주 미션을 하면서도 느꼈고, 현업에서도 자기주장이 강한 사람이 말하는 방법을 사용한다는 이야기를 들으니까 '개발 = 주장이 논리적이면 모두 정답'이라는 생각을 주기적으로 상기시켜야 할 것 같다.

 

---

우테코와 관련되지 않은 내용이지만 우연하게 오픈소스 활동을 같이 활동했던 분의 이력서가 자주보는 유튜브 채널에 나와서 신기했다. 이력서 피드백을 받는 영상인데, 토크쇼라 여러가지 팁도 나와있고, 피드백에 대한 내용도 나와있어서 나도 도움이 많이 되었다.

• 백엔드 메인 기술 스택에 집중하기, 다른 분야의 우선 순위를 더 높게 두지 않기 (ex. AWS, CI/CD, k8s, ...) 하지만 사용 방법은 알아야 한다.
• 무슨 무슨 기능 구현은 누구나 다 시간만 주어지면 할 수 있으므로 이력서에 언급하기엔 제일 안좋은 내용이다.
  위 내용보다는 최적화 경험, 복잡한 문제 상황을 해결하는 것에 대해 이야기해보기
  ex) 예약 기능을 만드는 프로젝트를 진행할 때, 동시에 여러 사람들이 같은 시간대를 예약할 경우 어떻게 처리를 할지에 대한 내용. 프로젝트에서 복잡한 상황에 대한 문제 해결 방법을 언급하는게 좋다.
• 자신의 프로젝트에 대한 내용 정리를 잘 해두기
• 내가 앞으로 성장 가능성이 높은 개발자라는 것을 보여주기

 

오픈소스 활동에 있었던 분을 보니까 갑자기 오픈소스 기여에 대한 내 경험이 과연 취준에서 좋은 경험일까?라는 고민도 들게 되었다. 그런데 생각보다 '오픈소스 기여 경험은 좋은 스펙이다'라고 말하는 사람들은 많은데, 왜 좋은지 이유에 대해 말하는 사람들은 없어서 계속 찾게 되었다.

 

https://www.youtube.com/live/2KmZjMVqdoY?feature=share 

 

위 영상이 큰 도움을 받았는데, 협업 경험이나 대규모 프로젝트에 참여한다는 경험이 제일 크게 느껴졌다. 그런데 영상 설명하시는 분을 보니 이 분은 오픈소스 활동 시작으로 git 강의를 해주신 분이였다 ㅋㅋㅋ 다른 유튜브에 대한 답변도 찾아봤는데 그 분 역시 오픈소스 활동을 통해 깃허브에서 봤던 분이라 나도 이런 사람이 되고 싶다는 마음가짐을 다시 가지게 되었다. 열심히 갓생 살아야지

 

 

 

끝