220528 팀프로젝트 회고
gcp 배포 서버를 옮기다.
gcp기간에 비해 무료 크레딧이 별로 안남아 다른 계정으로 옮기려고 한다. 현재 도메인은 사용 중이라 서버를 새로 판다음 도메인을 옮겼다. 생각보다 시간이 많이 걸리기도 했고, 끝나고 나니깐 좀더 괜찮은 방법도 떠올라 이곳에 남기려고 한다.
- 새로운 vm머신, 새로운 클러스터, 새로운 Mysql 서버를 open
이 중 Mysql 서버를 새롭게 만들고, 새로운 클러스터에 연결했다. 그리고 이전에 있던 Mysql 데이터를 '미리' 새로운 Mysql서버에 옮겼다. 지금 끝내고 나니 데이터를 옮기고, 바로 새로운 Mysql데이터에 연결을 해놓았으면 좀더 수월했을 작업이었다. - gcp secret 파일 관리
이 곳에서 제일 많은 시간을 허비 했다. gcp 시크릿 파일을 만들어야하 하는데, 만들 때 오타가 났었다ㅠ. 간단하게 고치고 저장했는데, 문제는 데스트에서 계속 오류가 뜨는 것이었다. 중간 중간 타이핑 한 것들이 많아 다시 확인 해보고 pod도 restart해봤지만 안되었다. 결국 시크릿 파일에 문제밖에 없다고 생각하고 지웠다가 다시 생성하니 되버렸다 ㅠ. - 도메인 이동
헷갈리기도 했고! 옮기면 때 조금 매끄럽지 못 한 점이 있었기 때문에 다시 정리 하려고 한다.
헷갈렸던 것은 클러스터를 만들고 ingress 연결 후 https에 등록 할 때, 도메인을 통해 인증서를 발급한다. 우선 ingress 주소를 도메인에 등록해야 하는 줄 알고, 미리 옮길 서버에 도메인을 등록하는 작업을 해버렸다. 그러다보니 팀원들이 중간에 연결 주소를 바꿔야 하는 불편을 겪었다.
그럼 정리하자면 Mysql을 미리 새로운 서버를 연결해 놓고, 새로운 서버의 https 인증서가 active 된것으 확인 한다음, 마지막으로 DNS를 함께 옮겼다면 중간에 크게 주소를 바꿔야 하는 일은 없었을 것이다.
클린코드를 위한 점검
개발보다는 점검하기로 해서 클린 코드를 위해 지난번 참조 링크를 통해 쭉 봤다. 그런데 메소드 명이나 변수 명은 현재 상황으로 변경하는 것이 쉽지 않았다. 프론트 개발에서 여러 페이지에 쓰기 때문이다. 변수명 하나라도 바꾸면 프론트 개발코드 여러곳을 바꿔야 했다. 결국 교훈은 만들 때 오타없이 깔끔하게 만들어야 했다.
코드 리팩토링
클린 코드가 지나가고 이제 좀더 안정적이고 수월한 방법으로 리팩토링에 대해서 공부해야 한다. 로직을 깔끔하게 디자인 하고, 일관성 있게 보수 하려고 한다. 하지만 여전히 헷갈리는 것이 있는데 'querybuilder'의 사용이다. 이전에 queryBuilder 가 좀더 안정적이라고 Docs에서 봤다. 그렇지만 구체적으로 어떤 부분이 안정적인지 이해도가 없는 것은 사실이다. query부분에서 손쉽게 'relation'하는 것에 대해서는 'querybuilder'를 딱히 쓰지 않고 있다. 정렬이나 조건이 두개 이상 들어가는 것에 대해서는 QueryBuilder를 사용 하려고 한다.
더 나아가 Mysql 구문에 대해서도 공부할 필요성을 느꼈다.
API 문서화에 대해서 알아보다
잘 된 프로젝트 github에 가보면 필수적으로 README와 api docs가 있는 것을 보았다. 감탄을 하면서 보기도 했지만, 어느정도 양식은 구글에 나와 있을거 같다고 생각했다... 검색이 부족했던건지 아무리 찾아도
괜찮은게 없었다. restAPI 에대해서 Swagger는 대표적으로 있었던것 같은데... graphql관해서는 찾기가 어려웠다. 마크다운과 리드미 작성 팁에 대해서 찾아봐서 내일 적용해야겠다.
참조
[[ Code Refactoring ] 코드 리팩토링에 대해서 알아보자,tasddc tistory, 2022년05월28일 접속]
https://tasddc.tistory.com/85?category=1008182
