본문 바로가기
회고

[코드숨] 3주차 회고

코동이 2021. 2. 8.

dal-lab.com/2019/09/18/today-i-learned/

 

오늘 나는 무엇을 배웠나?

오늘 나는 무엇을 배웠나? 2019년 9월 18일 - 아샬 초기 스타트업을 위한 컨설팅 업체인 thoughtbot이란 곳이 있습니다. Ruby on Rails가 유행하던 시절에 여러 기술을 공유해서 유명한 곳이죠. Active Storage

dal-lab.com

회고를 쓰기 앞서서, TIL ( Today I Leaned)에 대한 내용, 특히 Three FS를 활용하는 방법을 이해해야 합니다.

위의 달랩 홈페이지 아샬님의 글에서 관련된 내용을 확인할 수 있습니다. 

 

 

* 내맘대로 서론

이번주는 재택이 있었는데, 월요일에는 동기들과 인사 시간도 가졌고, 본가로 가서 그런지 긴장이 풀려 침대와 하나되는 시간들을 많이 가졌습니다.

행복은 멀리 있는 것이 아니다

 

 또한 잘 모르는 분야라서 그런지 선뜻 쉽게 intellij를 열기까지 고민과 시간들이 많았습니다.. ㅋㅋ

이 회고록을 빌어 나의 고통 주도개발을 위해 더불어 고통을 받으셨을 종립님께 인사올립니다.

 

또, 여러가지 테스트에 관한 많은 책들을 읽고 싶고, 더욱 더 고민해야겠다는 다짐을 합니다. 

이런 방식의 회고가 처음에는 어떻게 쓸지 몰랐는데, 점점 익숙해지고 있습니다.

 

진정한 회고의 의미를 담아,

과제 내용을 열지 않고 그동안 내 머리 속에 기억되는 것을 끄집어 내어 작성해보려고 합니다.

 

 1. Facts(사실, 객관)

 

 - Describe - Context - It 으로 이어지는 테스트의 방식은 깔끔한 정리를 돕는다.

 - 전체적인 @DisplayName의 설명은 누가 봐도 쉬우면서도, 구체적으로 이해할 수 있도록 적는다 

 - Context에서 그냥 설명만으로 지나치지 않고, 조건에 대한 준비를 해주어야 한다.

 - 하지만 그렇다고 Context에 모든 테스트 로직을 담는 것은 아니다(?)

 - Assertions에 대한 message 작성은 실패에 대해 올바른 결과를 알려주는 형식으로 작성한다

 - 문법을 사용하기 전에는 주석을 읽고 익히는 습관을 갖는다

 - 내가 설정한 @DisplayName 설명에 부합하는 테스트 증명 과정이 나와야 한다.

 - @DisplayName 설명은 최대한 코드변경에 유동적으로 대응 할 수 있는 느슨한 형태를 고려한다.

 - 상황에 따라서 엄격한 검사와 느슨한 검사에 대한 고민이 필요하다. 

 - 그런데 엄격한 검사와 느슨한 검사에 대한 검사의 차이는... 음..?

 - 단언의 Assertions이 가지고 있는 다양한 문법들을 적절히 이용한다.

(equals, empty, null 등 코드를 작성해보면 흐름대로 해석이 쉽다)

 - Service, Controller, Mv 테스트는 각자 역할을 가지고 있는 부분을 집중적으로 테스트한다.

(Service는 Service를 테스트하고, Controller는 Controllerf를 , Mvc는 Mvc를 테스트하자.. 음 당연하네? )

 - 테스트에 따라 독립적인 조건에 따른 mock의 사용을 고민해본다

 - 많이 작성하고 많이 만들면서 익힌다.

 

2. Feelings(느낌, 주관)

 

 종립님께서 Describe-Context-It 형식의 작성 가이드를 열심히 피드백 해주셨습니다. 마음 한켠에는 그냥 대충 내가 원하는거 메서드 실행하고 검증해서 맞춰보면 되는거 아니야?라는 생각을 했는데 코딩에 감히 대충이라는 쉬운 것은 없습니다.ㅋㅋㅋㅋㅋㅋ 전반적인 코딩 자세를 잡는 데도 도움이 됐습니다.

 

 피드백을 받으면서 느낀 것은 'A에서는 B이다. C에서는 D이다.' 식의100% 정답은 없다는 것입니다. 단지 매 상황에 직면했을 때, 최선의 선택을 하기 위해 고민이 필요합니다. 완성도 있는 결과를 위해서는 필살기 공식이 아니라 주변 사람들의 점검 및 피드백, 스스로의 많은 경험을 통해서 더더욱 견고하게 쌓아간다는 표현이 어울립니다. 

 

 @DisplayName의 설명과 실제 코드가 부합하지 않을 때, 불필요한 변수와 메서드를 사용함으로써 코드의 결합도가 망가질 때, 코드가 중복되어 가독성이 저하되는 것 등은 기본적으로 확인 할 사항이라고 볼 수 있습니다. 하지만 직접 작성하면서 그것들을 지키는 것은 쉬운 것은 아니고 계속 내 코드를 다시 확인하고 고민해야 함을 느꼈습니다. '어 이게 되네? 오케이 그럼 끝!` 이런 성향이 있는데 꺼진 불도 다시보자처럼 작성한 코드도 다시봐야합니다. 왜냐하면 내가 본 코드들이 다음 날 보면 또 새롭게 보이고, 아이디어가 떠오릅니다. 

 

3. Findings (배운 점)

 

 확실히 내가 만든 코드들을 견고하게 지탱해주는 안정감이 생겼습니다. 단순한 CRUD이기 때문에 각 class들이 굉장히 비슷한 형태로 작성되었지만 앞으로 각 class에서 무엇을 테스트 해야 하는지 컨셉을 확실히 알고 구분해야 겠다는 생각이 들었습니다. mvc에서는 주로 응답에 관련한 테스트에 집중했던 것처럼

 

 비슷한 맥락으로, 어설픈 설명과 검증은 철저히 보완하도록 합니다. 정말 내가 제대로 해당 메서드를 테스트 하는지 확실하게 봐야됩니다. 설명문과 검증이 따로 놀지 않도록, 정말 중요한 부분을 제대로 검증하고 있는지, 독립적으로 잘 만들어졌는지 확인합니다. 문자열 내용에 관한 설명을 하고 사이즈만 검증하면 혼란만 생길 것입니다.

 

 중복된 코드를 줄이고, 테스트의 각 단계를 효과적으로 드러낼 수 있도록 합니다. Context는 장식용으로 존재하는 단계가 아닙니다. 해당 조건에 맞게 테스트를 보여줄 수 있도록 최대한 노력합니다. 그리고 이렇게 깔끔히 정리되면 훨씬 코드가 한눈에 쉽게 들어오고 이해하기 쉽습니다. 

 

 마지막으로, 이번 테스트에는 DB가 들어가 있지 않았으므로 다음 훈련을 통해서 확인하고 싶습니다.

또, 이번 과제에서는 모든 코드를 다 작성한 상황에서 테스트를 만들었습니다. 실제에서는 테스트부터 작성할텐대 어느정도 단위로, 어떤 순서와 방식으로 테스트코드를 활용할 수 있을까? 문득 생각해봅니다.

 

4. 자기 선언(Affirmation)

 앞으로 주어진 1주간의 휴식기간 동안 테스트에 관련된 책을 봐야겠다는 생각을 합니다! 개발자가 항상 코드만 볼 것이 아니라 좋은 책을 읽는 것이 얼마나 중요한지 점차 더욱 느끼고 있습니다.

 같이 배우는 동기분들의 코딩 과정을 확인하는 것도 좋은 공부가 될 것 같습니다. 다른 분들의 코드를 참고하면서 내가 생각하지 못한 부분은 내것으로 확인하는 시간을 가지겠습니다.

 

5. 마무리... 회사생활과의 병행

 이제, 신입의 황금 휴식기간이 얼마 남지 않았습니다... 원래 빡세게 굴리는 곳은 아닙니다만, 자유를 만끽 할 시간이 얼마 남지 않았네요... 희망은 좀 더 균형잡힌 생활패턴과 시간활용에 대한 스킬들이 생기고 있습니다. 근데 어떻게든 운동을 좀 시작해야지... 이러다 바지 다 터지겠다

반응형

'회고' 카테고리의 다른 글

210301_TIL  (0) 2021.03.02
[ 코드숨 ] 5주차 회고록  (0) 2021.03.01
[코드숨] 4주차 회고록  (0) 2021.02.22
[코드숨] 2주차 회고  (0) 2021.01.31
[코드숨] 1주차 회고  (0) 2021.01.24