TIL,일일 회고

본 글은 소프트웨어 테스트 종류에 대해서 공부한 지식을 정리한 글입니다.단위 테스트 (Unit Testing) 설명가장 작은 단위의 코드, 즉 함수나 메서드 같은 개별 모듈을 테스트합니다.목적각 모듈이 독립적으로 올바르게 동작하는지 확인. 통합 테스트 (Integration Testing) 설명서로 다른 모듈이나 서비스가 함께 동작하는지를 테스트합니다.목적모듈 간의 인터페이스나 데이터 흐름이 예상대로 작동하는지 확인. 시스템 테스트 (System Testing) 설명통합된 전체 시스템을 테스트합니다.목적소프트웨어가 전체적으로 요구사항을 충족하는지 확인. 기능 테스트 (Functional Testing) 설명소프트웨어의 기능이 명세서에 따라 올바르게 동작하는지 테스트합니다.목적소프트웨어의 모든 기능이 제대..

본 글은 배포의 종류(Canary, 블루-그린, 롤링)에 대해서 공부한 지식을 정리한 글입니다.서론과거에는 소프트웨어 개발과 배포가 비교적 단순한 과정이었습니다. 서비스의 새로운 버전을 출시하는 데 수개월 또는 수년이 걸리는 것이 일반적이었으며, 이로 인해 각 버전은 매우 큰 변화와 함께 사용자에게 제공되었습니다. 이러한 방식은 전통적인 모놀리틱 아키텍처에서 주로 사용되었고, 배포와 업데이트 과정에서 상당한 리스크를 동반했습니다. 그러나 기술의 발전과 함께 소프트웨어 배포의 방식은 크게 변화했습니다. 현대의 소프트웨어 개발 환경에서는 서비스를 더 작게 분할하고(MSA), 이를 더 자주 배포(Deployment)하는 방식으로 전환되었습니다. 이러한 변화는 소프트웨어의 복잡성을 줄이고, 각 서비스의 독립적인..

본 글은 CI/CD에 대해서 공부한 지식을 정리한 글입니다. 지속적인 통합 (CI, Continuous Integration)이란❓전통적인 소프트웨어 개발 과정에서는 개발자들이 각자 독립적으로 작업한 후, 통합 단계에서 많은 문제를 겪곤 했습니다. 이 과정에서 발생하는 문제들은 종종 통합이 완료된 후에야 발견되며, 이로 인해 디버깅과 수정에 상당한 시간이 소요됩니다. 이러한 문제를 해결하고, 코드 품질을 유지하며, 빠르게 변경사항을 배포할 수 있는 방법이 필요했습니다. 이러한 필요성에 의해 Continuous Integration (CI)가 등장하게 되었습니다.  CI는 소프트웨어 개발 프로세스에서 코드 변경사항을 주기적으로 통합하고, 자동화된 테스트를 통해 문제를 조기에 발견하여 해결하는 방법론입니다...

본 글은 @RequestParam을 사용할 때 파라미터를 final로 선언하는 이유에 대해서 공부한 지식을 정리한 글입니다.처음 원본 코드는 위와 같이 user_id를 매개변수로 받을 때 final로 선언하지 않았습니다. 그런데 코드리뷰를 받다가, @RequestParam을 사용할 때 final로 선언하면 좋다고 조언을 해주셨습니다. 그 이유는 다음과 같습니다.  불변성 보장final 키워드를 사용하면 해당 파라미터는 메서드 내에서 값이 변경되지 않는다는 것을 보장합니다.이는 코드의 가독성을 높이고 버그를 방지하는 데 도움이 됩니다. 특히 멀티스레드 환경에서는 불변성이 중요한 역할을 할 수 있습니다.코드 명확성 파라미터를 final로 선언하면 해당 파라미터는 메서드 내부에서 변경되지 않으므로, 코드의 ..