230616 금요일 업무TIL

이번주는 한 주 동안 정말 정신이 없었습니다. ㅠㅡㅠ 

그래도 한 주의 마무리를 하게 되어 기뻤습니다! 

 

[잘한점] 

상황1) 퇴근할때 즈음에 팀원이 제시한 방향성에 대해 처음에는 이해가 잘 가지 않았다. 내가 DB와 엔티티에 필요하지 않은 column을 넣었다는 것이었다. 

액션1) 퇴근하면서 팀원이 제시한 방향에 대해 곰곰히 생각을 해보니, 팀원이 말한 상황에 대해 이해가 갔고, 팀원이 제시한 방향성에 동의했다. 그래서 팀원에게 내가 이해한 내용이 맞는지 팀내 메신저로 그 상황이 이해가 되었다고 말을 했고 감사하다는 메시지를 남겼다. 

칭찬1) 퇴근하고 나서 그 방향성에 대해 바로 잊은것이 아닌, 길가면서 팀원이 제시한 방향성을 이해하려고 노력했고, 이해한 후에 내가 필요없는 column을 넣었다는 것을 인지하게 되었다. 

 

상황2) 프론트엔드 팀원이 내가 작성했던 API에서 문제가 있다고 확인해달라는 요청이 왔다. > 결국 내가 잘못 작성한것이 아닌, 팀원이 API 호출을 잘못하고 있었다. 

액션2) 내가 작성했던 API를 다시 되돌아보며, 팀원에게 '어떤 API를 사용하고 있나요? 지금 사용하는거 말고 다른 API로도 호출을 해봤나요?'라고 질문했다. 

칭찬2) 내 코드를 다시 되돌아보고, 팀원이 현재 처한 상황을 정확하게 인식하려고 노력했다. 

-> 이래서 API 문서화가 중요하다는 것을 이 글을 쓰면서 다시금 깨달았다. 

 

+) 행동으로 옮기지는 않았지만, 고민했던 점 

하나의 작업에 대해 백엔드 팀에서 나 포함 3명의 팀원이 그 일을 담당한다(+프론트엔드) 그리고 백엔드 파트 중에 1명은 이 작업에 대한 담당자이다. 

그리고 이 하나의 작업에 대해 슬랙에 단톡이 있는 상황이고 이 안에 서비스기획자와 개발자들이 모두 모여있다. 

하지만 이 작업에 대해 신규 작업이 필요했는데, 이 작업을 한 팀원이 전체적으로 공지한 것이 아닌 > 담당자에게만 노티를 주고 그 담당자가 다시 남은 2명의 작업자(담당자)들에게 커뮤니케이션을 하는 일이 있었다. 

 

다시 한번 정리하자면 

1) 슬랙 단톡방 : 1명의 서비스기획자 + 백엔드 담당자들 + 프론트엔드 담당자들 -> 서비스기획자가 개발자들에게 신규 작업에 대해 노티하는 단톡방 

 

그런데 여기서 1명의 프론트엔드 개발자가 백엔드 팀의 1명의 담당자(총괄?)에게만 신규 작업에 대한 노티를 준 상황. 

그리고 백엔드 1명의 담당자가 > 다른 담당자 각각에게 다시 노티하는 상황. 

굳이 이럴 필요가 있나 싶었다. 

 

나같은 경우는 1)번의 단톡방에서 서로 커뮤니케이션한다면, 서비스기획자도 그 톡방 안에 있으므로 만약 개발 담당자가 잘못된 내용을 요청했을 경우 서비스기획자가 바로잡아 주는 등의 역할을 할 수 있다고 보는데 굳이 백엔드 1명의 담당자에게만 노티하고, 그 백엔드 1명의 담당자가 다시 여러 명의 담당자들에게 요청사항을 전달하는 것이 효율적인가?라는 생각이 들었다. 

(뭔가 너무 주저리주저리 쓴 것 같다..ㅎ) 

---

[개선점] 

문제1) 다른 팀원들은 이미 캐치하고 있었던 점들은 나는 다른 팀원들에 비해 늦게 알았다. ex) collectionAddress로 조회하거나 slug로 조회하거나 둘 중에 하나로 처리될 수 있도록 API를 작성해야 하는 것 

원인1) 나의 일에만 몰두하여 다른 팀원들이 짠 코드를 제대로 분석하지 않았었다. 나는 코드를 Commi&Push하면서 내 코드만 잘 올라갔는지만 확인하는데 한 팀원은 다른 팀원들이 어떤 내용을 Commit&Push 하는지 팔로업하여 위에서 상황1)과 같이 다른 팀원이 실수를 했거나 잘못된 점에 대해 지적을 해줌으로써 다른 팀원이 올바른 방향으로 코드를 짤 수 있도록 도와주는 것을 보았다. 이로써 '팀'으로 일하고 있는 나는 내것만 챙기기에 바빴던 것 같다.

액션플랜1) 앞으로 해당 브랜치에 Commit&Push를 날릴때 내 코드만 확인하는 것이 아닌 다른 팀원들의 코드도 파악함으로써 현재 어떤 방향으로 팀에서 코드가 작성되고 있는지, 이로써 내가 어떤 방향으로 코드를 작성해야 하는지 파악하는 습관을 들여야겠다. 

 

 

---

[배운점] 

배움1) 백틱을 쓰는 이유에 대해 크게 다가오지 않았는데, 백틱을 쓰는 이유에 대해 다시금 깨닫게 되었다. 

상황은 다음과 같다. 'walletAddress :: ${walletAddress}'라고 한다면, 터미널에서 {walletAddress}에서 postman 요청 시에 보냈던 walletAddress 값을 그대로 읽어올 줄 알았는데 walletAddress에 대한 값이 출력되지 않았다. 

의미1) 백틱은 템플릿 리터럴로, ex) this.logger.debug(`wallet Address is : ${walletAddress}`);라고 한다면, 템플릿 리터럴은 ${} 이 형태 그 자체로 이해하기로 했고, ` 백틱을 써줘야 ${walletAddress}에서 요청 시 보냈던 walletAddress 값을 터미널에서 제대로 읽어올 수 있었다. 

배움2) Slug의 의미와 역할 

백엔드에서는 slug를 쓰면 좋다?라고 얼핏 듣기는 했다. slug에 대해 설명하라고 하면 url에서 /photos 와 같이 모음집?이라고 마냥 이해를 했었는데 아니었다. 

의미2) slug의 의미에 대해서 다시 찾아보니 '페이지나 포스트를 설명하는 '핵심 단어의 집합'이라고 한다. slug를 URL에서 사용하게 된다면, 검색 엔진에서 더 빨리 페이지를 찾아주고(핵심 단어의 집합이므로) 검색 엔진의 정확도가 높아진다고 한다. 이래서 백엔드에서 slug로 조회하면 더 좋다는 것을 깨달았다.