우아한 테크 코스 6기 프리코스 1주차 회고

Polla·2023년 10월 28일

우테코

목록 보기
2/7
post-thumbnail

우아한 테크 코스 2023년 6기 프리코스 1주차 회고


정말 바빴던 일주일이 지나갔다.
사실 굉장히 스케줄 관리에 자신이 있었는데, 그럼에도 3일동안 6시간을 잤을 정도로 바빴기에
1주차를 무사히 진행한 2500명의 분들께 수고했다는 말을 하고 싶다...👊👊

돌이켜보니 입학설명회 이후로 거의 하루에 10개 이상의 목표를 잡았더라구요.. 수고했다! 나 자신!
링크는...제 소소한 입학설명회 현장 후기 동기부여를 위해 보는편..

1. 커뮤니티 입성



처음 우아한 테크 코스 디스코드에 들어갔을때,

온라인인데도 열기가 느껴져서 놀랐던 기억이 난다. 특히 많은 분들이 자신의 경험을 공유하고,
또 지식을 공유하면서 많은 팁들을 얻었다.
초반이라서 그런거 아냐?! 하시는 분들을 위해 현재를 보자면

스스로 만드는 커뮤니티가 활성화된 지금, 5시인데도 불구하고
조용조용 모각코 방에서는 다들 화이팅한다는 메시지를 남기고 우테코에 몰입하고 계셨다.

혼자였으면 사실 조금 외로웠을 것 같은데 함께 공부하는 느낌이라 행복했다 ㅋㅋㅋ
(교내 동아리는 일찍 자는 친구들 뿐이라..😂)

심지어 9일이 지난 현재에도 공유하기 방에는 하루에 거의 10개씩 공유하는 글이 올라왔다.
교내 동아리에 공유하면 정말 좋겠다는 생각이 들었는데,
이런 선순환이 우테코 프리코스의 또 하나의 장점이라는 생각이 들었다.



하루가 지난 후, 포비가(정말 님 안 붙이기 어렵네요..) 이러한 글을 토론하기에 써주셨다.

사실 살면서 머릿속에 전혀 들리지 않았던 속삭임은 아니었다.
특히 올해 4월 외부 동아리원에 속하며 과제를 제출할때 다른 수많은 멋진 동아리원들을 보며 자주 떠올렸던 생각이었다.

당시엔 자바가 처음이었기에 intellij 키는 것부터 도움을 받았고 코드에 손을 대는 것 조차 힘들었다.

리뷰를 해주더라도 리뷰를 이해하지 못하고 코드를 읽지 못하는 것이 정말 서러워 눈물도 조금 흘렸던 것 같다.🥹🥹

심지어

어쩌면 나 잘못 뽑힌게 아닐까? 이 동아리에 어울리지 않는 사람이 아닐까?

라고 장난스레 얘기하기도 했었다. 사실 당시엔 진심이었다..ㅋㅋㅋ
그래서 당시의 감정들과 어려움을 극복한 경험을 토대로

이와 같이 작성했다.
다른 분들도 각자의 경험을 공유해주셨고 가끔 동기부여가 필요할때 많이 엿보기도 했다.


+) 이후 확인해보니 포비가 많은 분들의 댓글을 보여주지 못해 정리하여 글을 올려주셨다.
비슷한 어려움을 겪는 분들도 해당 글을 보면 좋을 것 같다는 생각이 들었다.
가장 못하는 사람이 되라


2. 1주차 과제 전 고민을 해보자!


2주차의 미션은 숫자 야구 게임 이었다.

대략 이러한 게임으로, 첫 날은 고민을 시작했다.


2-1. md 파일의 존재 이유는 무엇일까?



우선 나는 해당 고민을 가장 먼저 했던 것 같다.

왜 우테코에선 기능명세를 작성하라고 했을까?

구글에 md 파일의 존재 이유에 대해 구글링을 해봐도 작성하는 방법만 나올 뿐 어떠한 답은 나오지 않았다.
그래서 스스로 정의를 내려보기로 했다.
목적을 생각했을때 "우테코에서는 왜 기능 명세를 작성하라고 했을까?"

나는 이것이 현업에서는 문제가 발생하지 않도록 예외나 기능들을 잘 정리해야 하기 때문에 프로젝트를 하기 전 만드는 프로젝트에 대해 스스로 다시 생각해보고 정리하는 습관을 들이는 것이라고 생각했다.

이후 생각을 마무리하려던 찰나, 한 개발자 분께서
"코드리뷰 낯설다면 이번 기회에 함께 시작해봐요!" 라는 제목의 작성하신 글을 공유해주셨고

받는 사람, 하는 사람 모두 노력이 필요하다

라는 문구에 코드 리뷰를 하는 사람의 입장도 고려하는 것이 좋다는 생각이 들었다.

그렇다면 그 말은 반대로 생각했을때,

나는 어떤 md파일을 봤을때 가장 좋다고 느꼈는가?

에 대해 스스로 생각해봤다.

  • 가독성이 좋고 깔끔하게 나뉘어져 있는 파일
  • 한 눈에 프로젝트의 모습을 알 수 있었을 때
  • 내가 확인하지 않아도 제대로 작동됨을 알 수 있었을 때
    • 어떤 기능들이 있는지 정리가 되어있을 때

라고 생각했다.

그렇게


나는 스스로 마지막에 체크 표시를 하며 확인할 수 있도록
체크 리스트 형식으로 도메인을 기준으로 나누고 행위에 따른 에러와 기능을 나눠 정리했다.
그리고 마지막에 그 결과를 밑과 같이 gif 형식으로 만들어 작성했다.



2-2. 일단 구현의 기준이 무엇일까?



많은 분들이

~패턴을 써야할까요? 잘 모르는 데 어떡하죠? 리팩토링을 고려하면서 작성해야 하나요? 시간이 부족하면 어쩌죠?

등의 말씀을 많이 하실 때 자주 나오는 답변이 있다.

일단 구현부터 해보세요!

사실 나는 이부분이 정말 어려웠다.

그렇다면 구현을 하면서 고칠 수 있는 부분을 보더라도 넘기고 코드를 작성해야하는가?
아니면 당장 해결할 수 있는 부분은 해결하며 작성해야하는가?

1주차 동안 모든 기능 완료까지 전체 코드를 정말 5번도 더 엎은 것 같다.

그러던 도중 토론하기에 이런 글이 올라왔다.

해당 질문을 통해 답변을 적으면서 생각을 정리해보고 나만의 기준을 삼았다.

갈아 엎은 코드가 그리워지는 것은... 실제 경험이었다.

현재 내 코드가 마음에 들지 않는 것이 단순히 다른 코드들과의 비교때문 인지,
분석 가능한 문제인지를 파악하는 것이 중요하다

고 생각했다.

그래서 해당 답글을 적은 이후로는 시간 제한을 두어 구현했다.
즉 파악도 좋지만 우선 스스로에게 비교할 시간조차 주지 말자가 계획이었다 ㅋㅋㅋㅋ

이후에는 시간을 갈아넣으며 최대한 현재의 내가 만들 수 있는 최선의 코드를 만든 것 같다.


3. 제 코드를 소개합니다.


우선 나는 1주차를 마무리하며 한가지 목표가 있었다.

이번 프리코스를 통해서 많이 성장하기 위해 많이 리뷰 받자!

그러나 한 단톡방에서 리뷰에 대해 언급하며 누군가 말했다.

" 리뷰를 원하더라도 받고 싶은 사람이 더 많아 어려울 수 있어요 "

뭔가 아차 싶었던 것 같다. 그래 내가 리뷰를 받고 싶다면 똑같이 누군가도 리뷰를 받고 싶겠구나

그렇다면 내가 먼저 그런 사람이 되어야겠다!
그렇게 12시가 지나자마자 글을 올리고 약 6시간 동안 다른 분들의 코드에 리뷰를 달았다.

이후 나의 PR을 확인했을때 정말 많이 놀랐다.
정말로 정성스럽게 다들 하나하나 리뷰를 달아주셔서 놀랐고,

그렇기에 나도 지식이 많았다면.. 하는 아쉬움이 많이 남아 최대한 칭찬도 좋지만
~는 왜 이런 방식으로 작성하셨는지 궁금해요! 와 같은 질문 형식으로라도 하려고 노력했던 것 같다.

그렇게 현재는

150개의 리뷰를 달성하게 되었다.
다만 이후 PR을 들어갈때마다 렉이 걸리는 바람에😂
리뷰 부탁은 중지하고,

이후 나와 비슷한 형식의
코드를 발견할때마다 내 PR 리뷰들을 공유하고 보시는 것을 추천 드리곤 했다.

그리고 이번 회고에서도 내 PR을 공유하려고 한다.
개인적으로 정말 좋은 질문들, 말씀을 많이 해주셔서 많더라도 읽는다면 좋은 경험이 될 것 같다.
실제로 동아리 후배들한테도 공유했다 ㅋㅋㅋ

[숫자 야구 게임] 장유진 미션 제출합니다.

특히 이자리를 빌어,
소중한 시간을 내어 코드까지 작성하며 리뷰해주셨던 23분의 리뷰어께 정말 감사를 표합니다.



++) 현재도 리뷰를 달고, 달리고 있는데 정말 배움에는 끝이 없더라...
	어쩜 이렇게 새로운 지식들이 계속 나오는지 빨리 능숙하게 
  	내 의견을 가지고 적용할 수 있도록 성장해야겠다..!!!

4. 리뷰 다 했니? 이제 목표를 정하자.


그래서 약 2주차가 시작한 이틀 동안 리뷰와 답글을 작성하고 회고를 정리했다.
머릿속으로는 구현이 너무 늦어지지 않을까 하는 걱정이 들었지만,
나는 일단 구현 과 피드백 정리 후 구현 중 후자를 선택했다.

이후엔 후회할지 모르겠지만
리뷰를 끝까지 마무리하고 싶었고,
입학 설명회때 제임스 코치님께서 해주신 말씀이 떠올라서 우선 시도를 해보기로 했다.
만약 아쉬운 결과가 남는다면
3주차때는 구현을 먼저 하면 그만이니까~ 라고 생각하기로 했다. to be continue..


4-1. 스스로 피드백 총 정리


그래서 많은 피드백들 중 수용이 필요한 것들을 추려 작성해 보았다.

  • 접근 제어자를 습관처럼 정해서 작성하지 말자.
  • 직접 구현하기 보다는 자료구조를 이용할 수는 없을지 고민해보자
  • 네이밍을 좀 더 명확하게 하자. 어렵다면 어울리는 네이밍을 찾아보자!
  • 예외 테스트를 많이 작성해보는 버릇을 들여보자! 어렵더라도 많은 시도를 해보기
  • 내부에서 관리, 외부에서 관리에 대한 생각을 조금 더 해보고 작성하자!
  • 생성자는 상단에 작성하자!
  • 테스트를 하기 간편한 방식으로 코드를 짜려고 노력해보자
  • 사용하는 함수는 최대한 알아보고 사용할 것! (성능도 고려하기)
  • 공통으로 사용하는 부분을 조금 더 넓게 생각해보기 (Strike 개수 3처럼!)
  • 습관적으로 Wrapping 하지 말자 이유 있게 사용하자!
  • for문에 사용되는 변수도 i보다는 이유 있게 네이밍 하자!
  • 공통되는 부분이 있다면 Interface, Abstract도 고려해보자

++) 10월 30일, 추가 피드백

  • IllegalException을 커스텀 Exception으로 만들때도 IllegalException이 라는 걸 알 수 있도록 네이밍을 생각하자!



물론 처음부터 모든 것들을 하기는 힘들 것 이라는 생각이 든다.
그렇지만 최대한 할 수 있는 만큼 힘을 써서 후회없이 프리코스를 마무리 하고
2주차 회고의 피드백이, 새로운 피드백으로 가득 차길... 기대해본다!

profile
트러블 슈팅 Blog => https://polla.palms.blog/home

0개의 댓글