230614 업무TIL

230614 수요일 업무 TIL

오늘부터 업무에 대한 TIL을 작성하고자 한다 :) 

 

[잘한 점] 

상황1) 커밋메시지에 [add],[edit]와 같이 태그값 다는 의견에 대해 팀원들에게 공유 

다른 팀과 같이 브랜치를 공유하고 있는데, 그 팀만의 커밋메시지 문화가 [add],[edit]와 같이 커밋메시지 앞에 자신이 어떤 기능을 구현하였는지에 대해 태그를 다는 것이었다. 우리팀의 경우 커밋메시지가 제각각이기도 하지만, 이렇게 앞에 기능구현의 경우 [add], 코드 수정의 경우 [edit]과 같이 태그를 달아준다면 더 명시적인 커밋메시지가 되지 않을까 라는 생각이 들었다. 

액션1) 해당 방식을 우리 팀에서도 적용해도 되는지 그 팀의 팀원에게 물어보았고, 좋은 인사이트를 공유해주셔서 감사하다는 의견을 남겼다. 팀원 톡방에 공유하였더니 좋은 반응이었고, 팀원들도 커밋메시지에 [add], [edit]와 같이 태그값을 달기 시작하였다. 

칭찬1) 팀의 발전을 위해 이런 사소한 것을 캐치하고 공유했다는 점에서 뿌듯하게 느껴졌다. 잘했다! 

 

상황2) 오늘부터 다시 버너리스트 쓰기 시작 

인턴 초반에는 버너리스트를 그래도 꽤 썼던 것 같은데, 정규직 전환이 되고 나서는 버너리스트에 대해 아예 까먹고 있었다.
액션2) 어제쯤인가 버너리스트에 대한 생각이 다시 났고, 퍼블리에서 버너리스트 쓰는 방법에 대한 글을 다시 읽은 후 버너리스트를 작성하기 시작하였다. 오전에 출근하자마자 버너리스트를 10분정도 작성하였고, 내가 무슨 업무를 언제 하는지에 대해 글을 작성하고 '이 시간 안에는 끝내야지'하는 생각이 있었기에 하루에 내가 원하고자 하는 업무를 끝낼 수 있었고 시간낭비가 줄은 것을 확인할 수 있었다. 

똑같은 시간을 투자하더라도 오늘 일했던 것들이 더 '끝냈다'라는 생각이 들었다. 

칭찬2) 내가 업무 시간에 어떤 일을 얼마나 했고, 그 시간에 구현한 코드나 업무에 대해 메모로도 남기니 내가 다음 타임에는 어떤 일을 해야 하는지 정확하게 파악하고 일을 시작할 수 있었고, 하루를 알차게 쓴 느낌이다. 

 

상황3) 다른 팀에서 들어온 질문에 대해 팀원들과 함께 공유 + 답변 공유 

액션3) 다른 팀에서, 팀원들이 모두 자리를 비우고 나밖에 없는 상황에서 문제점에 대해 공유를 해주셨다. 하지만 우리 중에는 그 문제를 해결할 수 있는 팀원이 없었고 우리 팀의 문제라기 보다는 다른 팀에서의 문제도 결합된 것이라 우리가 섣불리 나서서 해결할 수 있는 문제가 아니었다. 그래서 답변을 요청주신 다른 팀의 팀원에게 '다른 팀원분들과 의견을 나누고 다시 답변드리겠다'라고 말씀을 드리고, 팀원들과 함께 의견을 나누고 난 다음에 공유드렸다. 확실히 답변을 드리기 전에 팀원들과 함께 이야기를 나누니 혼자서는 이해하기 어려웠던 상황에 대해 더 깊은 이해를 할 수 있었다. 그리고 답변을 드린 후 팀원들에게 답변을 다시 공유하였다. 

칭찬 3) 하나의 문제에 대해 혼자서 고민하기 보다는, 팀원들이 같이 고민하고 팔로업하면 좋을 내용에 대해 같이 고민하고 이야기를 나누는 시간을 가졌다. 

 

상황4) QueryRunner을 처음 사용해보았고, API에 녹여냈다. 

액션4) 좋아요 수를 증가시키는 API를 작성하는데 이전에 팀원이 사용했던 QueryRunner을 사용해보았다. 처음 사용해본 것이었는데, 나름 구현이 어렵지 않았고 connect부터 에러처리, 쿼리 실행, 쿼리 해제까지 한 큐에 해결할 수 있어서 신기했다. 

칭찬4) 처음에는 어떻게 써야하나 막막했는데 시간을 두고 하니 적용하는데 그리 어렵지 않음을 깨달았다. (사실 내가 구현해야 하는 로직이 그리 어려운건 아니었다) 이 방법을 알려준 팀원에게 쿼리러너 사용해보니 재밌다고 했는데, 이렇게 하나씩 해나가면 된다. 쿼리 연습하는 좋은 방법이다 라고 쿼리러너 사용후기에 대해 칭찬을 해주었다. 

---

[개선점] 

문제1) 분명 저번에도 본 내용이었는데, 다시 보니 새로웠던 개념들에 대하여 

원인1) 내가 처음으로 그 개념에 대해 접할때 깊게 보지 않고 '이런 것이 있구나~'하고만 넘겼었다. 분명 어디서 들은 개념인데 설명하라고 하면 못할 것 같은 느낌이었다. 그 개념을 구현하면서 '아 이런 개념이었지'하고 생각하며 곱씹었다. 

액션플랜1) 앞으로 하나의 개념에 대해서 새로 알게 된다면, 내가 누군가에게 설명을 할 수 있거나 정말 제대로 알겠다!라는 느낌이 스스로 들기 전까지는 그 개념에 대해 파악하지 못했다는 것을 인지하고, 업무가 끝나고 나서라도 그 개념을 이해하는데 시간을 쏟도록 하자. 

 

문제2) Run을 했을때 에러가 없거나 하면 작은 기능이라도 바로바로 커밋을 하자. 

원인2) 하나의 기능을 '완성'하고 나서야 커밋을 날리려고 하니 다른 팀원들이 했던 이전 작업들에 대해 Merge가 되지 않은 상황이었고, Local에서의 내 코드와 다른 코드와 병합하는 작업을 거쳐야했다. 작은 기능이 하나라도 제대로 구현이 되고 테스트 후 커밋을 날렸더라면, 코드 Merge를 하면서까지 커밋을 날릴 필요는 없었다. 

액션플랜2) 작은 기능이라도 구현이 된다면, 바로 커밋을 날리도록 하자. 

---

[배운점] 

배움1) 커밋메시지를 작성할때 기능추가면 [add], 코드(로직)수정이면 [edit]와 같이 앞에 태그값 달기 

의미1) 다른 팀원들이 내 커밋메시지만을 보고도 내가 어떤 기능을 구현했구나를 더 명시적으로 파악할 수 있다. 

 

배움2) MessageQueue vs http 통신 둘 중에 뭐가 더 나을까? 

의미2) 둘다 비동기 통신을 하고 queue로 이벤트를 처리한다. 그러나 MessageQueue의 경우 중간에 buffer 역할을 하는 queue가 하나 더 있다는 차이점이 있다. 

-> 이거에 대해서 기능 만들어보면서 더 파악이 필요할 것 같다. 

 

배움3) countBy,insertBy, existsBy 

의미3) 

countBy -> 데이터의 수를 세는 작업 / 쿼리문 : SELECT COUNT(*) 

insertBy -> DB에 새로운 레코드 추가 / 쿼리문 : INSERT INTO 

existsBy -> DB에서 조건에 해당하는 레코드의 존재 여부 확인. Boolean값 반환  / 쿼리문: SELECT EXISTS 

어느 한 블로그 포스팅을 보았는데, SQL Insert시 중복검사는 countBy보다 existsBy가 낫다고 한다. 순회 검색 중에 중복되는게 단 하나라도 있는 경우 그 즉시 쿼리를 종료하는게 existsBy인데, 모든 데이터의 개수를 세는 countBy보다 압도적으로 좋은 성능을 보인다고 한다. 

 

배움4) HTTP POST 요청과 GET요청의 차이 (개선점 1번과 연결되는 문제) 

의미4) API를 계속해서 만들고 있는데, 저 둘의 차이에 대해 아직 명확하게 인지를 하지 못하고 있었던 것 같다. 

HTTP POST 요청 : 데이터를 '서버'로 전송하여 해당 데이터를 처리하거나 저장. 

-> POST 요청의 경우 데이터를 DB에 쌓아야 하는데 어떻게 쌓아야 할까?라는 고민이 있었는데 POST 요청을 하면 된다. 

HTTP GET 요청 : 서버로부터 데이터를 '가져와서' 사용된다. 데이터 검색 & 조회에 사용된다. 

서버에서 데이터를 읽어와 클라이언트에게 응답으로 보여준다. 

-> 서버는 GET 요청을 받으면 요청에 따라 데이터를 검색하여 응답으로 제공한다. 

 

배움5) NestJS에서 모듈 파일에 내 entity와 repository만 작성했을 뿐인데 Duplicate identifier라는 TypeError 발생 

의미5) 다른 팀원의 코드를 긁어와서 내 코드로 이식했는데도 같은 에러가 생겼다. 그래서 팀원에게 방법을 물어보니 IntelliJ를 껐다 켜보라는 단순한 방법..으로 해결했다. 가끔가다 이렇게 말을 안듣는다. 

 

20230615 TIL로 돌아오겠습니다 :) 

읽어주셔서 감사합니다.