230706 목요일 업무 TIL

'오늘 나에게 한마디' 

오늘도 화이팅! 

 

'오늘의 고민' 

- pagination을 궁극적으로 적용해야 하는 이유가 뭘까?에 대해 생각해보았다. 결국 클라이언트는 서버에게 데이터 요청을 보내고, 서버는 클라이언트가 요청한 데이터를 전달하는데 만약 데이터가 100만건,1000만건 이렇다면.. 서버에서 클라이언트까지 도달하는 시간도 오래 걸리고 과부하가 걸릴 것이다. 이럴때 pagination을 적용하여 데이터를 나눠서 보낼 수 있는 것이다. 

 

[잘한점] 

상황1) 원래 알고 있던 정보와 다르게 팀원이 푸쉬를 해서 그 이유를 직접 찾아가서 물어보았다. 

액션1) 원래 address 같은 경우는 ILike나 toLowerCase() 처리를 하는데, 팀원이 ILike 처리를 삭제했다고 해서 물어보았다. 그랬더니 위에서 또 toLowerCase()로 비교하는게 있어서 이중으로 처리가 되니, 하나만 처리를 하기 위해 ILike 처리를 삭제했다고 한다. 

칭찬1) 원래 알고 있던 상식에서 빗겨간 내용이어서 왜지?하고 궁금해하고 있었지만, 그걸 해결하기 위해 팀원에게 직접 찾아가 이유를 들은 자세가 좋았던 것 같다. 

---

[개선점] 

문제1) 아직 다른 팀원의 코드를 보는 속도나 이해도가 많이 떨어지는 것 같다. 

원인1) 개인적으로 문법공부도 많이 안되어있는 것 같고 쿼리빌더나 SQL 사용 등에 있어서 아직 익숙하지 않아 이해하는데 오래걸리고 계속 찾아보게 된다. 한 책에서 봤는데 이렇게 계속 찾아보는 것도 기억하려고 하지 않아서 발생한다고 하는데, 이런 악순환의 고리를 좀 끊어야겠다고 생각했다. 

액션플랜1) 문법공부를 플래시카드나 종이를 이용해서 앞뒤로 연습할 수 있도록 만들어야겠다. 그래서 출퇴근이나 집에 와서 복습하는 용도로 해야겠다. 매일 10개씩이라도 문법을 일단 외우는 연습이 필요하다고 생각했다. 

---

[배운점] 

배움1) NestJS보다 코프링(Kotlin + Spring)이 배포속도 등의 측면에서 더 빠르다고 한다. 

의미1) 코프링을 딥하게 써보지 않았고, 일단은 NestJS도 지금 날아다니는 수준이 아니라 두 차이를 아직 크게 실감하지는 못하고 있다. 언젠가 깨닫는 순간이 오기를..ㅎ

 

배움2) 예를 들어 (@Query('walletAddress') address:string) 이라는 파라미터가 있다고 하자. 여기서 walletAddress는 property이자 데코레이터 식별 문자열이며, address가 실제 데이터이다. 즉 walletAddress라는 이름의 쿼리 매개변수를 받아와서 해당 값을 address 변수에 할당하는 역할을 한다 

의미2) 문득 REST API 요청문을 보다가 @Query() 안에 들어가는 매개변수와 그 옆에서 타입 정의를 해주는 변수는 무슨 차이가 있을까?라는 생각이 문득 들어 찾아보았다. 결국 타입 지정해주는 쪽이 실제로 사용할 데이터이니 더 주의깊게 봐야겠다고 생각했다.