ultra_dev

+프로젝트에 REST API를 사용한 이유: 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하기 때문에 사용(소통 및 협업 용이) REST API 말고 다른 비교할만한 것:GraphQL, 쿼리를 활용해서 한번의 요청으로 많은 데이터를 가져올 수 있는 방법.장점 : 필요한 최소 정보만 별도 요청이 가능하기에 효율적이고, 엄격하게 정의된 데이터 유형은 클라이언트와 서버 간의 통신 오류를 줄여줌단점 : 고정된 요청과 응답만 필요할 경우에는 Query 로 인해 요청의 크기가 RESTful API 의 경우보다 더 커짐.File 전송 등 Text만으로 하기 힘든 작업들을 처리하기 복잡👓정리(X)두서 없는 글 리소스를 프로그래밍 규약에 맞게 전달 하는것URI 규약에 맞게 리소스를 ..

객체지향프로그래밍(Object-Oriented-Programming) : 객체들의 집합으로 프로그램의 상호 작용을 표현하며 데이터를 객체로 취급, 객체 내부에 선언된 메소드를 활용하는 방식 객체지향 프로그래의 특징 추상화 : 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것 캡슐화 : 객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것 -> 중요한 데이터를 쉽게 바꾸지 못하도록 함, 분리로 인한 코드 재사용성 증가 상속성 : 상위 클래스의 특성을 하위 클래스가 이어 받아서 재사용하거나 추가, 확장하는 것 -> 코드의 재사용 측면, 계층적 관계생성, 유지 보수성 측면에서 중요 다형성 : 하나의 메서드나 클래스가 다양한 방법으로 동작하는 것. 대표적으로 오버로딩과 오버라이딩이 ..

☑️뭔가 자꾸 값이 잘못 들어가는 것들이 있어서 수정 하느라 시간을 많이 날렸다. ☑️테스트코드.. 단위 테스트나 클래스 별로 돌리면 돌아가는데 패키지 별로 돌리면 또 안되고 스트레스다.. ☑️애초부터 설계가 잘못된 것 같다. id가 아니라 객체를 들고 있으면서 연관관계도 맺어가면서 설계 했어야 공부했던 것들을 써먹을 수있었을텐데 아쉽다.. 낯선 방식으로 하려니 더 신경쓸게 많은 것 같다 ☑️QueryDSL 적용 중.. 생각보다 만능이 아닌 것 같다..? 📋 다음주 목표 ✏️ QueryDSL 적용 끝내고 다른 기능들 완료하기 ✏️ 레디스 공부 ✏️ 캐시 공부

📌 queryDSL 공부 뭔가 공부하면서 쿼리에 대해 알게 되서 좋았다. 확실히 쿼리를 알아야 성능 최적화를 하는데 도움이 될 것 같다. 프로젝트에 적용해보려고 했는데 자꾸 뭔가 해야할 게 생겨서 다음주쯤에야 뭔가 써먹을 수 있을 것 같다 ㅠ 내일은 aws ec2 배포 목표로 달려야하는데 아 뭔가 걱정된다.