TIL-220226

토요일

소프트웨어의 품격 스터디

이번주는 스레드 안전성이라는 챕터명으로 경합 조건, 교착 상태, 동시성 레벨 등에 대한 내용들을 학습했다.
안그래도 동기화에 대한 내용이 항상 어렵게 다가왔어서 이번 내용도 쉽지 않았다. 스레드가 락을 획득하고 해제하는 흐름을 글로만 보니 이해하기 힘들었고, 특히 숨은 경합 조건에 대한 이야기에서 포기하고 싶었다..ㅎ

다행히 스터디 진행자였던 루이의 명강의와 제리의 보충설명을 통해 조금이나마 이해할 수 있게 된것 같다. 특히 루이가 직접 짜온 코드와 그린 그림들은 정말 👍👍

루이의 준비성을 보며 내 차례때 더 열심히 준비하지 못했던것을 반성하게 됐다. 다음번에 기회가 생긴다면 더 열심히 해보는걸로..😭

스프링 입문 강의

회원관리 예제에서 members 폴더 밑에 createMemberForm.html 파일을 추가하는 작업이 있었는데 실수로 createMemberForm을 생성했다. 아래와 같은 화면이 떴고 그냥 이름 바꿔서 생성하면 되겠지라고 생각하고 createMemberForm.html로 변경해서 생성했는데, 그때부터 문제가 발생했다. 저렇게 생성했더니 해당 이름의 파일을 다른 형식의 파일로 인식하도록 설정이 되어버렸다. 파일을 여러번 삭제 후 생성도 해보고, 인텔리제이를 껐다가 키기도 했지만 문제가 해결되지 않았고 결국 구글링을 통해 해결했다.. 함부로 엔터를 마구 누르지 말자 😭

 

일요일

알고리즘

Leetcode - Longest Substring Without Repeating Characters

• 돌릴때마다 성능이 달라지는데 최고가 뒤에서 13프로의 런타임 효율을 가졌다. 처참… 뭔가 더 좋은 방법이 있을텐데 아직 잘 모르겠다.

사다리 미션 5단계

브라이언의 코드리뷰를 받을 수 있는 기회를 놓치고 싶지 않아서 주말을 이용해 사다리 미션을 5단계까지 완성했다.
이전 단계에서는 유저 객체의 이름에 공백이 포함된 값을 저장하고, 사다리 자체에서 문자열 형태로 데이터를 가지고 있는 이상한 구조였다. 코드리뷰를 통해 toString 메서드는 가볍게 가져가야 한다는 피드백을 들었고, mvc 패턴에서 공통적으로 보이는 부분은 뷰에서 가지고 있어야 한다는 내용을 학습하게 되어서 문자열 형태의 데이터는 뷰로 옮기고 객체가 가지는 값들을 정상(?)적으로 만들었다.

구현하면서 생긴 한가지 고민은 의존성 주입에 관한 부분이다. 현재는 유저목록, 사다리, 당첨상품들을 만드는 각각의 Creator 클래스가 존재하고 GameService의 생성자에서 직접 Creator객체를 통해 값을 만들어 필드에 저장하는 형태로 구현했다.
하지만 직접 접근하는게 좋지 않아보여서 어떻게 바꿀지 고민하다가 2가지 선택지를 생각해보게 되었다.

1. 각 Creator 객체를 컨트롤러에서 만들어서 주입하는 방식

• 오로지 생성자에서 값을 만드는데 사용되는데 굳이 넘겨줘야할까?

1. 값 자체를 Controller에서 만들어서 값을 넘겨주는 방식

• 값을 생성하는건 결국 게임서비스가 가져야하는 책임이 아닐까?
• 컨트롤러에서 만들게 되면 해당 객체에 직접 접근이 가능해져서 문제가 되지는 않을까?

위의 고민들을 하다가 결국 그대로 pr을 날리고 브라이언의 의견을 물어보았다.
애초에 Creator가 존재하는게 이상한건가 싶기도 한데 답을 기다려봐야겠다.