Search
Duplicate
🔁

2021년 9월 4주차 회고록 - 반복의 미학

Facts

코드숨 미션 2주차 - 6주차 복습 진행
이펙티브자바 아이템 46 포스팅

Feelings

코드숨 미션 2주차부터 6주차까지 복습

명절로 인해 버퍼기간이였던 한 주동안 고민을 했다. 미리 스프링 시큐리티를 다시 한 번 훑어볼까..
영한님의 MVC2편 강의 밀린걸 좀 보고 포스팅을 할까.. 아니면 밀린 책들을 읽을까..
그러다가 슬랙에서 리뷰어님들이 하셨던 말이 떠올라 지금까지 했던 미션들을 다시 한 번 진행하면서
테스트 케이스 작성 및 주석 작성을 숙달하는 시간을 가지기로 했다.
처음엔 사실 12시간 언저리에 금방금방 끝내지 않을까 생각했는데, 어림없는 소리!
화요일인가 수요일에 시작한 복습은 아직도 진행중이다...
merge까지 되면서 충분히 했다고 생각했는데 다시 하다보니 새롭게 고려사항이 생기고 새로운 테스트케이스가 생기고 고민할 점들이 생긴다. 사실 질문리스트도 많은데 귀찮을까봐 슬랙에는 남기지 못하고 다른 톡방이나 구글링을 통해 해결하고 있다. 다음주에 7주차 과정을 시작하면 다시 몰아서 다시 여쭤봐야 할 것 같다

이펙티브 자바 아이템 46 포스팅

오랜만에 이펙티브 자바 포스팅을 했다.
사실 집에서 공부가 잘 안되 오전에 집근처 카페에 와서 공부를 하려는데 실수로 집에서 작업내용을 푸시하지 않았고, 굳이 여기서 다른 API 개발을 해도 되지만, 머지하면서 conflict resolve를 하는것도 귀찮고, 그냥 새로운 마음으로 다른 공부를 해볼까 해서 이펙티브 자바를 포스팅 하게 되었다.
아직 챕터 6 람다와 스트림을 진행중인데, 상당히 한정적으로 사용하고 있고, 실무에서는 가장 '덜' 스트림스러운 forEach도 많이 쓰면서 그와중에 외부 가변상태에도 영향을 주도록 작성을 하고 있었는데, 책을 읽으면서 많이 반성하는 시간을 가진 것 같다.
당장은 힘들더라도 점진적으로 올바른 스트림 패러다임을 적용할 수 있도록 해야 할 것 같다.

반복의 미학

코드숨 과정 복습을 통해 다시 한 번 느꼈다. 잘 아는 것 같아도 설명할 수 없으면 모르는 것과 같다.
즉, 나는 블로그에는 수백개의 글이 있고 돈은 돈대로 시간은 시간대로 공부에 많은 시간을 썼지만,
사실은 몇 달 공부 안했지만 제대로 공부한 학생보다도 못하다는 것.
많은 키워드에 대해서 알고 구글링 혹은 블로그에서 빠르게 검색을 통해 대답을 할 수 있다.
즉 많이 알고 있다. 하지만, 구글링 없이 블로그 없이 그냥 말로 설명하려면 제대로 설명하지 못한다. 이는 많이 알고 있지만, '잘' 알고 있지는 않기 때문이다. 그럼 왜 그럴까?
이는 뭔가 엄청난 이유가 있는게 아니다. 그냥 반복이 부족하고, 복습이 부족하기 때문이다.
보통 포스팅을 할 때는 요약까지 하면서 정리도 하고 예제 코드도 작성해야 하기에 나름 열심히 한다. 대충 훑으면서 공부하는건 아니다. 하지만, 그래봐야 1회독이다. 그 뒤로 보지 않으면 결국 잊게 되고 모르는 것 만 못한 상태가 된다.
코드숨에서 아샬님이 슬랙에 올린 말이 있다.
그럼, 이렇게 뻔히 아는 내용을 나는 왜 못지킬까? 이 또한 잘 생각해보면 다음과 같은 결론을 도출하게 된다.
1.
반복은 지루하다.
2.
내용을 눈으로 보면 아는 것 같다.
3.
계속 나오는 새로운(내가 모르는) 키워드가 나를 조급하게 해 새로운 지식을 공부하는데 시간을 쓰도록 한다.
이를 정리하면 반복하는건 지겹고 내가 발전하는건지 알기 쉽지 않지만, 내가 모르는 새로운 기술용어나 지식들이 나오면 나올수록 조급해지게 되고, 그런 새로운 지식들에 대해 떠들정도로 얕게 공부하다보니 얕은 지식만 가득해지는 일명 얕고 방대한 지식 저장소가 되는 것이다.
이러면 비 전문가와 대화할 때는 아는 것 많아보이고 똑똑해 보일 수 있지만, 전문가를 만나게 되면 금새 들통나 속 빈 강정임을 알리게 된다.
하지만, 그렇다고 단순히 반복하며 암기하는 것은 효율도 떨어지고, 파편화된 지식들은 하나하나의 파편들은 잊기도 쉽다.
그러니 이런 파편들을 연관짓고 이를 통해 이해하기 위해서는 다음과 같은 과정을 수행하도록 하자.
1.
지식 습득(ex: Stream API, 주석을 작성할때 중요한 점, 각종 테스트 애노테이션)
2.
지식 사용(ex: 실제로 프로젝트를 생성하여 API를 만들고 주석을 작성하고 테스트 애노테이션을 활용해 테스트를 만들고 스트림 API를 이용해 로직을 짜 본다. )
3.
반복

Finding

코드숨 미션 2주차부터 6주차까지 복습

목요일 - 일요일까지 4일간 진행을 했는데, 6주차까지 모두 완성하진 못하고 5주차 80%정도까지 구현을 했다. 피드백 받았던 내용들 리마인드 + 새로운 고민점과 학습내용들을 숙달하는 과정이였다. 하나하나 테스트케이스도 다시 다 구현하다보니 일요일 새벽 1시경에는 4일간 작성한 테스트케이스만 repeatableTest 애노테이션을 제외해도 300개에 가까워졌다. 그렇게 복습을 진행하며 다시 새롭게 고민하게된 이슈들은 다음과 같다.
화면단에 노출 될 View 객체를 변환하는 책임은 ViewSupplier라는 인터페이스를 정의해서 View객체 혹은 View를 가지는 일급 컬렉션에서 가지는게 맞지 않을까?
검증기(Validator)는 MockMvc, RestAssured등을 이용한 Rest API 테스트를 진행할 때는 제대로 작동하지만, 서비스나 도메인 테스트를 할 때는 해당 검증기가 동작을 하지 않기 때문에, 어떻게 해야 하나 고민을 했다. 그리고 구글링을 해 본 결과, 그냥 필요한 레이어에서 직접 검증기의 validate 메서드를 실행해서 검증과정을 수행했다.
일급 컬렉션을 사용하라. 라는 예전 조언이 생각나서 List<Product> 와 List<Account>등의 목록들을 AccountList, ProductList라는 일급 컬렉션을 만들어 관리해도록 구현해줬다. 그런데 이건 정말 오버엔지니어링이 맞을까 아닐까 고민하게 된다.

이펙티브 자바 아이템 46 포스팅

아이템 46에서는 스트림 API를 사용하면서 내부 함수에 부작용(side effect)가 없는 순수함수를 써야한다는 점을 시사했는데, 이는 사실 람다식의 권장사항과도 일맥상통하다.
람다식이 외부 상태에 영향을 주게 되거나 코드가 길어질 경우 가독성도 떨어질 뿐 아니라 의존관계가 생기고 그로인해 생길 부작용이 위험하기 때문에, 최대한 부작용이 없게끔 코드를 작성해야 한다.

Affirmation

코드숨 스프링 7주차 미션 스프링 시큐리티 학습
스프링 시큐리티 포스팅 했던 내용들 리마인드
알고리즘 스터디 시작
이펙티브 자바 포스팅 하나 이상
새로운 지식 습득보단 블로그에 포스팅하고 배웠던 지식의 반복 숙달