오늘 진행한 것들 🤔

• 리액트 공부
  • 타입스크립트로 리액트 프로젝트 진행
    • 타입 지정하는법 학습 
    • 인터페이스로 props 를 넘기는 법 학습 (파라미터로 넘기는법)
  • 테일윈드 / styled component 학습
    
    • 테일윈드가 컴포넌트 내부에 선언될시에 코드가 정신이 없어지는 것을 방지하기 위해서 스타일드 컴포넌트에 테일윈드를 적용하는법을 배웠다.
  • 커스텀 훅 응용
  • Material UI 응용
• 프로젝트 진행
  • 메인페이지 뼈대 템플릿 구성
  • 메인페이지 보드 구현
  • 커스텀 모달 구현
  • 커스텀 네비바 구현 (모바일용)
  • 반응형 템플릿 구현

오늘 겪었던 문제 🤔

• 반복문으로 리스트를 반환해주는 컴포넌트를 생성시에 타입스크립트가 타입 오류를 내뿜는 문제가 있었다.
  • 이유는 단순히 컴포넌트는 단 하나만의 영역을 반환해야 하는데 array 타입을 반환해서 생기는 문제였다.
  • <> 와 </> 로 감싸주면 오류가 발생하지 않는다.

오늘의 배운점🤔

• 커스텀 훅을 응용해보았다.
  • 검색을 해보니까 단순히 state 로 상태만 관리하게 된다면, 값이 변경될때마다 해당 컴포넌트가 리렌더링이 된다는 사실을 알게 되었다.
  • 내가 누군가..? 나는 직전까지 백엔드를 찍먹해봤던 응애 개발자.. 나에게 있어서 성능 하락은 용납되지 않는다.
  • 코드를 조금이라도 줄이고, 반복되는 핵심 로직은 밖으로 빼낼 필요가 있었다.
  • 리액트 같은 경우에는 백엔드와 비슷하게 성능을 신경써야 하는 부분이있었다.
  • 백엔드같은 경우에는 데이터베이스 접근 빈도라던가, 한번에 여러개의 데이터를 불러올때의 속도라던지.. 가 있다고 친다면, 프론트엔드는 리렌더링 되는 횟수가 성능에 영향을 끼치는것 같았다.
  • 거기에 가장 좋은 코드는 유지보수가 가능한 코드가 아니던가 ..?
  • 그래서 알아낸게 useCallback 과 커스텀훅이었다
    
    • 커스텀훅 같은 경우에는 핵심 로직을 굳이 밖에다 빼놓을 필요도 없고, 코드를 줄이고 싶고, 밖에다 주구장창 state 와 effect 를 적어둘 필요를 줄여준다.

• 리액트의 꽃은 아무래도 컴포넌트의 재사용성을 높여서 최대한 블록 끼워맞추기 처럼 이랬다 저랬다 하는데 지장이 없도록 하는게 아닐까.. 라는 생각이 든다.
• 리액트에서 제공해주는걸 백분 활용해서 컴포넌트를 만들다보면 차곡차곡 쌓여서 정말 홈페이지를 구성하기 너무 간편해진다. 제이쿼리로 주구장창 당장 확인도 ㅇ잘 안되는 코드를 작성했을때 얼마나 답답했던지.. 리액트 최고

오늘 진행한 것들 🤔

• 토이프로젝트 진행
  • 랭킹 페이지 구현

• 팀 토이 프로젝트 진행 
  • 많은 오류들의 무수한 악수 요청을 받았다. 모두 수정 완료.
  • 전체 뷰를 구현했다. (템플릿은 엉망이고... 기능만 확인하는 용도로 구현한 것 같다.)

오늘 겪었던 문제 🤔

• 랭킹 페이지에서 캐릭터 이름을 검색할때 몇위인지 나오는게 아닌, 해당 캐릭터 이름을 가진 캐릭터 안에서의 랭킹이 출력되었다.
  •  해당 부분은 내림차순으로 리스트를 반환할때마다, 캐릭터의 랭킹 카운트를 같이 조회하도록 해서 순위 자체를 같이 받아와서 출력하도록 구현하였다.
  • 따라서 한번의 출력당 총 11번의 검색을 진행한다.

오늘의 배운점🤔

• 정말 api 하나 짜는데 10분 걸린다고 치면 프론트 하나에 30분정도를 소요하게 되는것 같다.
• 대충 구현하려고 해도 다른 신경써서 구현한 부분들과 조화롭지 못한 탓에. 자꾸 똑같은 실수를 반복하고있다.
• 나 자신과 타협을 해야겠다는 생각이 들었다. 앞으로도 이런식으로 프로젝트를 진행하면 내 정신과 몸은 남아나지 않을것. 곧 개발에대한 흥미가 떨어질 수 있다는 소리이다.

오늘 진행한 것들 🤔

• 토이프로젝트 진행
  • 계정 탈퇴 구현
  • 계정 모험단 정보 출력 로직 구현
  • 테스트 코드 작성
  • 계정 프로필 아이콘 설정 (모험단 캐릭터로) 구현

오늘 겪었던 문제 🤔

오늘 해결한 오류 🤔

오늘의 배운점🤔

• API는 몇개 안짰지만.. 프론트를 엄청 오래 만지고있다.. 나도 얼른 협업 하고싶다.. 🫠

내일도 화이팅!

오늘 진행한 것들 🤔

• 토이프로젝트 진행
  • Querydsl 추가
  • AOP aspect 추가
    • 유저 인증 체크 Aspect
    • 게시글/댓글 검증 체크 Aspect
    • 모험단 자동 등록 Aspect (캐릭터 조회시에)
  • 캐릭터 랭킹 테이블 로직/뷰 구현
  • 모험단 자동 등록 로직/ 모험단 랭킹 뷰 구현
  • 책임 분리 
    • 결합도 조절 (도메인별로 따로 관리할 수 있도록 분리)

오늘 해결한 오류 🤔

오늘의 배운점🤔

• 크게 배운점도 없고.. 크게 오류난것도 없는.. 아주 무난한 하루..
• 흐음...

내일도 화이팅!

오늘 진행한 것들 🤔

• 토이 팀 프로젝트
  • 예외처리 설계
  • 테스트코드 작성법 설계
  • 뷰 구현

• 토이 개인 프로젝트
  • 코드 리팩토링
  • 테스트 코드 작성
  • AOP를 활용한 중복 코드 제거 (Validation, 인증)

오늘 겪었던 문제 🤔

• AOP 인증 체크 관련 문제
  • Pointcut 을 선언하지 않고, 파라미터를 체크하지 않은 단순 security context holder 에서 authentication 객체를 가져와 체크를 하게되면, authenticationprincipal 객체가 null일때 처리를 못하고 null pointer exception 이 발생하게 되는 문제가 있었다.
    • @Before 로 args < 로 principla 객체를 가져와서 모든 메소드에 principal 객체를 (인증이 필요한 메소드) 매개변수로 넣어주고 체크를 해서 처리하도록 했다.

오늘의 배운점🤔

• • 팀 프로젝트 설계를 끝냈다.
    • 다행히 팀 프로젝트 난이도가 크게 높지 않아서 설계가 예상했던것보다 얼마 안걸렸다.
    • 오늘 내가 놀랐던건, 라이브 코딩으로 다른거를 참고하지 않고 테스트 코드에 대해서 팀원들에게 설명을 해주는데  한순간의 막힘도 없이 쭉쭉 써내려가고 있었다 ㄷㄷㄷㄷㄷ
    • 한두달전에 비하면 정말 폭풍성장했다는걸 오늘 느꼈다.
  • 스프링 AOP 를 알게 되었다.
    • 전에는 AOP 관련 강의를 들어도 이해가 전혀 가지 않았는데.. 오늘 드디어 감을 살짝 익혔다.
    • 따라서 중복되는 코드들에 적용을 시켜보았다. 전체적으로 봤을때 인증 관련 검증과 (객체가 null인지) binding validation 에서 사용할 수 있을것 같아서 적용시켜보았다.
    • 인증 관련은 before 로 메소드 호출 전에 확인을 했고, validation (binding result 타입을 이용한 에러 메세지 전송) 은 around 로 메소드 호출 도중에 체크를 하고, 문제가 없다면 계속 수행하도록 구현했다.
    • 코드가 굉장히 짧아졌다.
      • 인증 관련은 인터셉터를 이용해서 접근을 가로챌까 생각을 했지만, aop는 단순히 어노테이션 혹은 패키지명을 적어주고 정의만 해주면 클래스 두개로만 처리가 가능했지만, 인터셉터는 각 컨트롤러 별로 클래스를 따로 생성해 관리해야할것 같았다.
      • 인터셉터로 게시판까지 처리를 하고, aop를 적용시켰는데 너무 비교가 되어서 aop를 남기고 인터셉터 관련 메소드와 클래스는 제거했다.
      • aop의 편의성을 지금 알게되었다.... 지금이라도 알게되서 너무 다행이고 앞으로 코드를 작성할때 얼마나 많은 도움을 받을 수 있고, 한걸음 더 나아가 고민거리를 던져줘서 재미까지 챙겨주는 aop.. 사랑해요

오늘 진행한 것들 🤔

• 토이 팀 프로젝트 
  • 게시판 만들기 설계
    • 데이터베이스 설계
    • API 엔드포인트 설계
    • 비즈니스 로직 설계
• 개인 토이 프로젝트
  • 테스트 코드 작성과 리팩토링

오늘 겪었던 문제 🤔

오늘 해결한 오류 🤔

오늘의 배운점🤔

• 처음으로 팀 설계를 진행해보았다.
  • 확실히 같이 진행하는 인원이 있으면 재미도 두배, 안정성도 두배인것같다.
  • 내가 개인 프로젝트를 진행할때 놓칠 수 있을만한 부분을 다 챙겨가는거같다.
  • 특히 api를 설계할때, 기존의 개인 프로젝트는 단순한 틀만 만들고 꾸준한 수정을 진행했던 반면, 팀으로 진행하니 미리 여러 api들을 설계 후 진행해 크게 어려울게 없을것 같았다.
• 테스트 코드 작성
  • 테스트 코드 작성에 대해서 대해서 새로운걸 알게되었다.
    • 하나의 메소드가 하나의 책임만을 갖고있어야 한다는것.
    • 해당 부분을 인지하고 테스트 코드를 작성할때, 알아서 코드도 리팩토링을 하게 되더라.
    • 테스트코드를 매번 밀린 숙제 하듯이 작성했었는데, TDD의 필요성을 점점 느끼고있다.
    • 팀프로젝트를 계속 진행할 일이 생긴다면.. TDD 방식으로 개발을 하는게 맞을까... 라는 생각을 꾸준히 해왔는데, 맞다 라는 쪽으로 기울어지고 있는것 같다.
  • 내가 짜놓은 코드의 문제점에 대해서 또 한번 깨닳았다.
    • 하나의 책임만을 갖고있어야 하는데, 메소드가 여러개의 행동을 동시에 진행한다던지, 그러한 비즈니스 로직이 여러개 존재했다.
    • 마찬가지로 , 스프링이 여러 기능을 제공해주는데 단순히 자주 쓰는 기능만 사용하고, 다른 기능들은 찾아서 활용해볼 노력조차 하지 않고있었다.
      • 대표적으로 어드바이스, AOP, 인터셉터이다.
        • 인터셉터 같은 경우에는 매번 인증을 확인하는 절차라던지, 그걸 컨트롤러단에서 똑같은 코드를 몇번을 반복하며 처리하고있었다.
        • 정말 쓸데없는 짓이었다. 인터셉터로 단순히 메소드 하나만 띡 만들어주면 그 반복되는 몇줄 혹은 몇십줄의 코드가 깔끔하게 처리되는것이다.
        • AOP같은 경우에는 현재 프로젝트상 성능 확인이 필요한 부분 (캐릭터 상세 조회시에 한번에 10번 이상의 api를 호출함) 이라던가, 쨋든 공통적으로 처리되어야 하는 부분 (인터셉터와는 별개로)은 또 따로 메소드로 뺄 수 있지만, Util 클래스가 아닌 이상 주입을 시키기 애매한 클래스에서 동작하는 메소드가 존재할 때도 있다.
          • 이럴때 AOP를 사용하여 적절한 행동을 실행하도록 정의 하고, 어노테이션만 붙여주면 공통적으로 실행하기 때문에 관리가 편해진다.
        • 어드바이스 또한 글로벌 예외처리로 매번 꾸준히 컨트롤러에서 캐치를 해준다거나 할 필요 없이 따로 클래스 하나만 생성해 각 예외를 어떻게 잡을지만 처리한다면 문제가 해결된다.
      • 공통적으로 공통된 행동을 분리시킴에 있어서 효과적인 방안을 제시해준다.
      • 이래서 본인이 사용하는 프레임워크에 얼마나 이해도를 갖고있느냐가 결국 유지보수를 하기 쉬운 코드를 만들 수 있는 지름길이 된다.. 공부가 답이다.
      • '객체지향'은 정말 코드를 짜면 짤수록 내가 더 부족함을 느끼게 하는 단어이다.. 나태해지지말고 꾸준히 해야겠다.
    • 별개로 몇달동안 내가 코딩인지 코딩이 나인지 모를정도로 살아왔는데.. 점점 한계가 오는거같다. 이대로 가는게 맞는것일지.. 방안을 찾아봐야겠다.
  • 내일도 화이팅!

오늘 진행한 것들 🤔

• 토이 프로젝트 진행
  • 뷰 템플릿 수정
    • 해시태그 기능 수정
      • Tagify 를 이용한 태그 분리
      • 현재 존재하는 태그를 검색해 추천해주는 로직 구현
  •  

오늘 겪었던 문제 🤔

• 문제라기보단 성능관련 문제가 있었다.
  • Tagify의 옵션중 input이 자바스크립트의 keyup과 기능이 거의 똑같았는데, keyup 관련 기능을 구현할때, 매번 고민한던게 있었다.
    • 글자마다 ajax 통신을 해버리면 안녕 이라는 결과를 검색할때 6번의 통신을 하게된다.
    • 프론트에서 해결할 수 있을거같아서 스쳐지나가듯이 찾아봤던 기억중에 setTimeOut 이라는 메소드가 있었던거 같아서 엄청 검색을 했었다.
    • 한글로 검색하기엔 적절한 태그를 찾지 못했고, 영어로 검색했을때 다행히 나같이 생각을 한 외국 개발자가 있었다.
    • 전역변수로 timeout 변수를 만들어주고, 마지막 입력을 하기 직전까지 매 입력마다 변수에 메소드를 저장하고, 마지막 입력 직전까지는 실행되야하는 메소드를 모두 null처리 시켜서 없애주고, 마지막 메소드만 실행할 수 있도록 변경했다.
    • 해당 로직은 나중에 검색어 로그 조회라던가, 비슷한 로직으로 캐릭터 검색등등 여러 부분에 쓰일 수 있을거같아서 기록을 해야겠다 다짐했었다.

오늘 해결한 오류 🤔

오늘의 배운점🤔

• setTimeout 과 clearTimeout
  • 좀더 효율적으로 이벤트를 다루기 위해서 알고있어야 할 것 같았다.
  • 닉네임 중복조회 같은 로직에 keyup에 사용하면 좋을거같다.
• 노드 모듈을 스프링부트에서 사용하는법
  • 기존에 꾸준히 제이쿼리 플러그인을 로드해서 사용중이었는데, npm을 스프링부트에 적용시키는 법도 있더라.
  • 단순히 resources 폴더에 진입 후 npm init -> install 패키지 를 하고 핵심 js파일을 로드해오면 됐었다.
  • 생성자가 클래스를 읽어오지 못해도 프론트에서 정상적으로 로드가 되더라... 앞으로는 npm으로 더 사용하기 쉽게 설치해야겠다.

오늘 진행한 것들 🤔

• 토이프로젝트
  • 전체 코드 리팩토링
  • 알림 기능 추가
    • Sse 를 활용한 알림기능 구현
    • 알림 뷰 구현
    • 알림 링크 클릭시 확인된걸로 변경하도록 구현
  • 캐릭터 정보 불러올시에 스프링 Async 기능을 이용해 비동기처리로 받아오도록 구현했다. (속도가 조금 빨라졌으려나..? 실감이 되지 않아서 불안정한 작업을 할 바엔 돌려놓는게 좋겠다라는 생각으로 두고보고있다. 하지만 캐릭터 정보는 내가 처리하는 데이터가 아닌 외부에서 안전한 데이터를 가져오는것이니.. 아직 확실하지 않다.)

오늘 겪었던 문제 🤔

• 해당 기능을 구현할때 보통 프론트쪽에서 세션스토리지에서 토큰정보를 가져와서 구현하는 글들을 많이 보았는데 나는 세션스토리지를 쓰지 않던 상황이라 로그인시에 세션에 로그인 정보를 저장하고 뷰의 헤더에 로그인 정보를 인풋밸류로 저장해 로그인을 안했을땐 anonymousUser 로 입력하도록 하고, 로그인시에는 계정이름을 입력하도록 한 후에 구독을 하도록 했더니 동작이 되었다.

오늘 해결한 오류 🤔

오늘의 배운점🤔

• Sse (Server - sent - event) 를 알게되었다.
  • 기존에 알림기능을 구현했지만, 실시간으로 알림을 전달하도록 하는 기능은 구현하지 못해서 약간 애물단지? 굳이 구현했어야했나? 하는 느낌으로 Notification 도메인이 남아있었다.
  • 마찬가지로 생각해보니 구조상 알림이 생성되어야 하는 동작에서 컨트롤러단에서 서비스를 분리해 로직을 실행한게 아닌, 각 도메인 서비스별로 레포지토리를 주입시켜서 생성시키고 있었다. 이건 결합도가 높아질 수 있는 행동 (이런식으로 코드를 짜게되면 부품처럼 사용하지 못하게 된다. )
  • 따로 알림 서비스와 컨트롤러를 생성하고 분리를 진행했다. 훨씬 깔끔하고 보기 좋았다.
  • 마찬가지로 알림이 필요한 기능에 단순히 Sse 메소드만 집어넣으면 전송이 되었다.
  • 거기에 +@ 로 부트스트랩의 toast 에 대해서 알게되었다.
  • 이제 alert() 가 아닌 토스트에 메시지를 띄워도 되겠다는 생각이 들었다...... 굿