우테코 프리코스 4주차 후기

벌써 마지막이다..

 

내가 우테코 프리코스에 참여하고자하는 이유는 단 하나 

 

"주니어로써 좀 더 온전한 개발자가 되는 것" 을 위함이다

 

---

 

4주동안 메일캡쳐 이미지가 이렇게 늘 다를 수 있다니.

 

 

 

#  공통 피드백

 

저번 주차 주요 목표에 처음으로 제대로 목표가 이해가 안됬다고 적은 만큼 

 

피드백 또한 꽤나 어렵다고 느꼈다. 

 

함수(메서드) 라인에 대한 기준 

발생할 수 있는 예외 상황에 대해 고민한다

비즈니스 로직과 UI 로직을 분리한다(비즈니스 로직과 UI 로직을 한 클래스가 담당하지 않도록 한다. 단일 책임의 원칙에도 위배된다.)

객체의 상태 접근을 제한한다

객체는 객체스럽게 사용한다

필드의 수를 줄이기 위해 노력한다

성공하는 케이스 뿐만 아니라 예외에 대한 케이스도 테스트한다

테스트 코드도 코드다

테스트를 위한 코드는 구현 코드에서 분리되어야 한다

단위 테스트하기 어려운 코드를 단위 테스트하기

 

 

일단 객체는 객체스럽게 사용한다. 라는 말이  이해가 잘 안갔다.

 

# 4주차 주요 목표 

 

미션에 대한 자세한 내용은 링크로 대체합니다! : https://github.com/woowacourse-precourse/javascript-bridge

 

4주차의 주요 목표는 

 

1. 클래스(객체)를 분리하는 연습
2. 리팩터링

 

이 두가지 이다. 

 

 

# 시도한 것 , 우여곡절 

 

일단... 항상 공통 피드백과 다른 사람들의 코드 그리고 내 전 주 코드를 보면 진짜 엉망진창이라는게 곧 이런게 아닐까? 하는 생각이 먼저 들었다.

 

이번주의 경우에는 처음에는 파일이 미리 생성되어있길래 처음엔 슬쩍 보고 와 더 어렵다? 고 만 생각했으나 진행하다보니 오히려 미리 작성되어있는것 파일들을 보면서 굉장히 많은 생각과 공부를 하게 되었다. 

 

 

 

  1. 주요 목표대로 시도

 

일단 공통 피드백 내용이 꽤나 어렵고 생소하게 느껴졌기 때문에 그것들의 적용이 요번 주 의 큰 과제였다.

 

지난 주 까지야 피드백이 없었으니까 될대로 시도한다고 쳐도 이번주차 부터는 피드백대로의 방향대로 적용하려고 최대한 해보려했고 

 

알고있는것을 , 그 간의 주차에서 배우고 활용한것을 여기엔 학습한것 위주로 적어서 다 적진 않았지만  총망라하고자 노력했다.

 

 

   1-1 ) 객체의 분리

 

        1-1-1)  객체와 클래스

 

            만들어진 파일을 쭈욱 보고 있노라니, 어떤 건 객체로 되어있고 어떤건 클래스로 되어있었다.

 

사실 객체를 만드는 방법이 그냥 객체 선언하는거랑 클래스로 있나보다 하고 공통피드백 자료 에서도 보고 대충 읽고 그냥 넘겼었는데

 

이번에 미리 작성 되어 있는 코드가 어떤건 클래스고 어떤건 객체로 되어있는걸 보고 음....? 뭔 차이지 싶어 생각해보게 되었다.

 

나는 클래스가 단순 객체의 상위호환이라고 단순히 생각하고  전부 클래스로 만들어서  static 처리하곤했는데

 

이번에 피드백 자료나 , 작성 되어있는 파일들을 보고 생각하고 있으니 굳이 그렇게 만들거면

 

인스턴스화가 필요없는 객체는 class 로 static 처리할 게 아니라 단순 객체로 선언하는 편이 좀 더 구분되기 쉽지 않을까 하는 생각이 들었고 그렇게 코드도 작성했다.

 

근데 이렇게 하면 어떻게 객체안의 프로퍼티를 접근을  막지? 하는 생각이들었다 근데 머릿속에 답은 금방 나왔다 그냥 freeze 하면 된다고 생각하고 그렇게 처리했다

 

 

 

     

       1-1-2) MVC 패턴  

 

 

              지난 주의 글에도 적었듯이 굳이 mvc 를 목표로 분리하진 않았다. 글에는 안적었지만 class 자체가 값을 지니고 생성하는 시점에서 model 인 동시에 controller 라고 나는 개인적으로 느꼈기 때문에 mvc로 분리하려면 제대로 분리가 안된다고 생각하기도했다. 

 

그래서 이번주 에도 최대한 기능별로 쪼갤려고 했는데  그럼 mvc패턴은 뭐하러 적었냐 하면 나의 경우에는 저번주에는 분리가 안된다고 해서 생각도 안했지만 

 

사람들의 코드를 보니 mvc 패턴을 많이 적용하신듯하여 일단 뭐가 m이고 뭐가 v 이고 뭐가 c 에 해당하는지 정도는 스스로 생각해봐야겠다 싶어 혼자서 분류해봤다. 

 

위에서 말했듯이 클래스를 가지는건 이미 model 이자 controller 라고 느꼈지만 일단은 파일에서 maker에 해당하는것들이 근본의 model 일것이고 클래스는 그것들을 활용하는 controller에 가까운 model 이라고 생각했다.

 

view는 이미 우테코 측에서 생성해놓은 파일에 사실상 다 분리된거나 다름 없다고 생각해서.. 생략했다

 

 

 

     1-1-3) 응집도 와 결합도 

 

        이 역시 기존에 작성되어있는 코드를 보고 접하게 된 키워드이다.  나는 원래 상수 파일을 따로 생성해놓고 그곳에다가 상수파일을 몰아넣고 매번 import 시켜 사용하고있었는데.

 

요번에 미리 작성되어있는 코드를 보니 미리 객체안에 상수가 선언되어있는것을 보고. 

 

"아! 이거다" 하는 생각이들었다.

 

이렇게 각각 객체와 클래스에 필요한 상수는 각각의 객체와 클래스에 들어가있어야.  좀 더 유지보수하고 확인하기도 편하고

 

단순히 상수여서 좀  자신도 없고  맞는 비유인지는 모르겠으나 응집도도 올라가는 동시에 결합도도 낮아지는게 아닐까 ? 하는생각이들었다. 

 

좋은 설계라함은 

 

응집도의 경우에는 관련된 기능끼리 높은 응집률을 가지고있어야되고 

 

결합도의 경우에는 다른 클래스와 결합도가 낮아야 유지보수가 편하고 좋은 설계라고 한다. 라는 점을 이러한 상수 적용을 하면서 찾아보면서 생각해보게 되었다.

 

 

 

 

 

 

 

     1-2) 리팩터링 

 

 

         1-2-1)  테스트코드와 설계 그리고 리팩터링의 상호작용 

              

             네이밍, 함수의 분리, 상수, 컨벤션, 제약사항 같은 부분들을 떠올리면서 최대한 여러번 리팩터링 했다.

 

지난주차들과 같은 실수를 하지않기 위해서 기능 구현 먼저 가능한 빠르게 하고 다음 파일로 넘어가서 App.js 에서 결합하기전에 여러번 리팩토링을 하고 나서 결합하려고했다.

 

왜냐면 다 결합하고 나서 리팩토링하려면 하나고치더라도 전체를 다 고쳐야되서 리팩토링 난이도가 올라간다고 생각했으니까 그렇다.

 

물론 다 결합하고 나서야 리팩토링이 가능한 부분도 많았기에 사실상 별 의미없는 생각이였다. 

 

이런 일련의 과정들을 통해서 계속해서 여러번 느끼고 있다. 

 

테스트코드의 중요성과  설계의 중요성을

 

테스트코드를 , 설계를 잘 해놓았다면 아니 사실 잘 해놓는게 꼭 문제가 아니라 잘 남겨놓기만 이라도 했다면 언제든 참고하고 서로가 서로에게 상호작용하는 항목임을 느꼈다. 

 

설계를 잘해놓았다면 테스트코드를 하기가 쉬워지고 

 

테스트코드를 잘 작성한다면 기능 구현 설계 문서도 좀 더 잘 고쳐졌다. 

 

그리고 마찬가지로 리팩토링을 해도 세가지가 다 서로 순환되며 한 싸이클을 이룬다는 것을 느꼈다. 

 

       1-2-2)  객체를 객체 답게 쓴다

         

         리팩 토링을 하면서 고민했던 부분이다. 객체를 객체 답게 쓴다는것이 무슨 말일까?  discussion 에도 나같은 사람이 있지않을까 해서 가봤더니 아니나 다를까 있었다.

 

https://github.com/orgs/woowacourse-precourse/discussions/1177

 

나랑 비슷한 생각으로 구현하신듯 했다.

 

피드백의 요지는 값을 그대로 뱉게 하지말고 가능한 계산한 메세지를 던지게 하라. 라는 이야기로 getter 와 setter를 쓰지말라는 일맥의 연장선상의 이야기가 아닐까 하고 이해 했는데. 

 

아예 안쓰는건 내 실력에는 일단 여러번 봤지만 ... 답이 잘 생각나지 않았고 

 

로또 미션때와 달리 전부 static으로 선언한 것도 아니였고,  클래스는 클래스대로 객체는 객체대로 용도에 맞게 분리해서 쓰고있었음으로

 

객체를 좀 더 객체답게 쓰고있다는 생각이들었다. 적어도 이전주차의 나보다는. 

 

 

             

2. Git 

  음 뜬금없지만 이번 4주차에 git을 굉장히 많이 활용했다. 

 

당연히 이전 주차들에서도 사용했지만 

 

이번주차에 가장 많이 활용하기도했고 그동안 사용한것들 , 시도한것에 대해서 간략하게나마 적으려고한다.

 

 

    2-1) 커밋 지우기 , 수정 

 

       git rebase -i 를 사용하여  지우고자하는 커밋의 직전 커밋을 가져와 drop 하고 -force로 강제 전송했다.

 

사실 커밋을 미리 안날렸으면 force로 할 필요도없는것인데 미리 커밋을 계속 업데이트 되는게 보기 좋아서 push 했다가 force로 고치는 참사가 많이 일어났다.

 

하지만 덕분에 이제는 커밋 내역의 목록을 어느정도 내가 원하는대로 수정할 수 있게되었다.

 

그밖에 git commit --amend  를 사용하여 직전 커밋을 수정하는 방법이나 

 

git stash 를 통해 임시 스테이징 하는 방법도 알수있었다. 

 

 

   2-2) upstream / git fork 최신화 

 

     사실 우테코 공통 피드백에서 준 자료에서  이전에 upstream 에 관한 이야기가 강의자료에 있었어서 

 

아~ 뭔진 알겠는데 어따 쓰지 하고있었는데 요번에 써먹을 일이 생겼다.

 

다름아니라 중간에 원본 레파지토리에 변경사항이 생겨 fork 한 레파지토리를 최신화 할 필요가있었는데

 

이때 upstream 으로 원본 레파지토리를 remote add 로 추가하여  fetch -> merge 하여 최신화를 하면서 활용했다.

 

 

   2-3) branch

 

    사실 브랜치를 적극적으로 사용한적이 별로 없다. 

 

요번 과제에서 bridgeMap 과 관련된 객체를 생성하다가.

 

어딘가 답답하다는 생각과 내마음대로 시도해보고싶다는 생각에 

 

BRIDGE 브랜치를 파서 혼자 분기를 만들어 안에서 마음대로 작업했다.

 

단지  그렇게 작업하고 딱히 merge를 한건 아니고 그걸 참고로해서 새로 다시 작성하는 식으로 활용한거라 git 플로우 대로 활용해볼 수 있는 시간을 가지진 않았는데 끝나고 한번 나중에 시도해보려고한다. 

 

 

 

 

 

 

 

 

 

 

 

 

# 느낀 점 

코드를 치는데 망설임이 줄이 줄고 코드에 대해서 고민하게 되었다.

 

코드를 치는데 망설임이 줄었다.

 

원래 나의 개발 프로세스는 개발이라는 것을 한 구력이 절대적으로 얼마 안되기 때문에

 

다 기억이나서 기록해보자면  극 초기에는 이러했다. 

 

뭔가요구 를 받는다 = > "  안해본거잖아? "  =>

 

1. 멘붕 몇시간 반복 하고 손도 안대보고 포기 

2. 그래도 해 보고 스트레스 받으며 어거지로 개노가다 진행

3. (운이 좋았다면) 몇개 해보고 잘되서 쭉쭉 진행

 

이렇게 3가지 정도로 나눌 수 있었다면 

 

이젠 그냥 일단 기능 구현 목록 부터 클래스별로 작성하려고 노력해보고. 

 

그대로 기능 부터 만들고 기능이 일단 의도한대로 만 잘돌아간다면 (예외 사항은 나중에)

 

그대로 구현한다음에 이어붙여서 잘 되는지 확인해보면 

 

어느새 인가  시간이 엄청나게 많이 흘러가있었다. 

 

이제는 맨 땅에 해딩을 하더라도 나의 설계 문서와 함께 했다.

 

나는 적어도 우테코 프리코스의 경험에 대해 대만족이라고 말할 수 있을 것 같다.

 

설계 습관과 테스트 코드, 사람들과의 소통 정말 내가 가져가고 싶은것들의 효용성이나 중요성을 다시한번 스스로 느끼고 경험하고 재정리할 수 있었을뿐만 아니라 

 

무엇보다도 여러번 다른글에서도 말했지만 이 익히는 훈련을 제공해준것에 굉장히 감사하게 생각하기 때문에 

 

아마 끝나고 나서도 전체적인 프리코스의 학습 프로세스를 참고해서 앞으로 코딩 공부나 다른 공부에도 참고해서 적용해볼 생각이다. 

 

또한 개인적으로 느끼기에  많은 자원들도 제공되었다. 

 

내가 지금 스스로 자정작용하면서 잘 피드백하고 나아가는것인가? 하는 생각이 들때마다 

 

커뮤니티 라는 자원이 있는덕분에 용기만 내면 피어리뷰를 요청할 수 있었고 

 

아고라의 글을 보면서 학습자료를 얻고 회고를 보면서 위로 받기도 했다.

 

아 그리고 문제 설계 하신 분들에게 정말 감탄한것은

 

예전 우테코 말고 취준 하면서 적은 회고에도 적혀있지만 

 

알고리즘 문제를 처음 풀때는 자신의 무력함을 느끼며 짧지만 강렬했던 번아웃을 경험하기도 했다.

 

근데 우테코 프리코스 내내 주어지는 문제들은 조금 생각해보고 배열이나 객체를 어떻게 활용할것인지 만 생각해보면 다 풀 수 있었는데

 

스스로 설계하게 하고 익힐 수 있게 하는 문제를 만들었다는게 참 대단하게 생각한다.(설계를 설계했다니!  )

 

그래서 더 재미있었다 (물론 어려운 부분도 많이 있었고 대부분 안하던것들이였다)

 

 

 

코드에 대한 고민이 늘었다.

 

이전의 나는

 

기능만 돌아간다면 리팩토링 같은건 하지않았다.

 

마찬가지로 기능만 돌아간다면 변수명이나 함수명 분리 같은건 크게 신경쓰지도 않았다.

 

객체의 특성에 대해서도 생각해보지 않았고 

 

테스트 코드는 쳐본적도 없다

 

이제는 

 

테스트 코드를 하면서 확장성있는 코드  , 그 자체만으로도 온전한 함수 , 기능 같은것들을 더욱 고민하고 생각할 수 있게 되었고 

 

함수명을 고민하고 특성을 고민하고 설계를 하고 리팩토링을 한다.

 

정말 좋았다.

 

짧게 말했지만 그 동안 정말 날림으로 만들고 날림으로 공부했구나... 하는 생각이들었다 이렇게 배우고 익히고 만들면서 현업에 나가서도 이런식으로 일하는 문화를 가진 기업에 가고 싶다는 생각을했다.

 

물론 당장에는 바램일 뿐. 

 

이제 한 동안 다시 나는 우테코에서 얻은것들을 토대로 내 공부 루틴에 승화 시키고 못다한 공부도 더 하고 적용하는 시간을 가지려고 한다. 

 

다시한번 프리코스 확대를 통한 이런 경험을 하게 해주심에 감사하면서 회고 마친다. 

 

 

 

 

 

 

 

 

 

 

 

---

 

이전글 목록 

 

 

3주차 후기 : https://hello-coding-world.tistory.com/49

우테코 프리코스 3 주차 후기 (+ 코드 리뷰 받은 느낀 점)

 

 

2주차 후기 : https://hello-coding-world.tistory.com/48

우테코 프리 코스 2주차 후기

 

1주차 후기 : https://hello-coding-world.tistory.com/45

우테코 프리 코스 1주차 후기