Hyunebee

제로베이스 스쿨 9월 이제 마지막 후기..

Hyunebee — Fri, 30 Sep 2022 18:10:17 +0900

수료했습니다~

팀프로젝트를 마치며..

끝으으으입니다.

팀프로젝트를 끝으로 이제 모든 교육과정이 끝났습니다. 다행이도 무사히 수료를 마치고 글을 작성하고 있습니다.

저는 백엔드 조원으로 팀프로젝트에 참여했습니다. 구성의 경우는 프론트 2명 백엔드 3명 + 전임강사님 + 제로베이스 진행 강사님까지 이런식으로 화상회의를 진행하였습니다. 총 5~6주의 기간동안 진행했으며 1주차에는 주제 2주차에는 문서작성 3~6주차에는 개발위주로 진행하였습니다. 이과정에서 주마다 한번씩 전임강사님의 피드백을 받아가면서 수정을 진행하였습니다. 6주란 기간은 생각보다 개발을 하기에 터무니없이 부족한 시간이라고 생각했습니다. 따로 모여서 하는게 아닌

개개인이 진행한 부분을 PR로 병합하고 통일하는과정이 생각보다 많이 걸렸기 때문입니다. 왜 의사소통이 중요한지 알게된 대목같았습니다. 그리고 확실히 전임강사님의 피드백은 실무위주에 피드백이라 더욱 좋았던것 같습니다. 실무에서는 어떤것을 사용하고 어떤식의 코드를 사용하는지 이런식으로 적용해보는것도 괜찮다. 이런식으로 조언을 해주셨습니다.

강의가 아닌 직접코드를 짜보면서..

어찌보면 위의 팀프로젝트와 이어지는 내용같습니다. 강의를 통해 배운 지식을 직접 사용하여 내것으로 만든다는게 쉬운일은 아닙니다. 분명 내가 필요한 기능을 구현하는데 모든 지식이 강의에 들어있지 않기 때문입니다. 강의에서 배운 내용을

찾아 내가 필요한 기능을 직접 구현하면서 내것으로 만드는게 참중요하다. 라고 느꼈습니다. 저의 경우 시큐리티에 대해서

토큰을 발급하고 사용하는 법만 알았지만 이렇게 사용할 경우 보안상의 문제가 있겠다는 피드백을 받고 bearer token을 만

들어 프론트에 송신해 일정기간 사용하지 않으면 refresh token을 사용해 다시 발급받을 수 있게 만들었습니다. 이과정을

진행하고 이해하는데 7~8시간정도를 소요한것 같습니다. 이렇게 직접 코드를 만들다 보니 더욱 기억에 오래남고 다음에

같은 문제를 발견하더라도 바슷한 방법으로 접근해 금방 문제를 해결할 수 있을것 같다고 생각했습니다. 뭐든 직접 만들어

보고 부딪혀보는게 개발자에게는 좋은거라 생각합니다.

취업전선에 한걸음..

취업 준비를 하면서 포트폴리오의 중요성을 많이 느끼는것 같습니다. 뭔가 내가 했다는 기록을 보여줄 수 있는게

개발자는 포트폴리오와 코딩테스트라고 생각합니다. 현재도 많이 미숙하지만 교육을 듣기전보다는 확실히 발전

중이라는것을 느끼고 있습니다. 그리고 취업을 할려면 자소서를 쓰고 지원을 해서 면접도 보고 경험을 하는것도

중요하다고 생각합니다. 여러분들도 미리미리 준비해두시면 좋으실거 같습니다.

아직 공부가 모두 끝난게 아니고 앞으로도 배울게 많은것 같습니다. 배우면 배울수록 부족함을 느끼고 있습니다.

여러분들 모두 끝까지 포기안하시고 진행하신다면 반드시 좋은결과를 얻으실 수 있습니다! 앞으로도 화이팅입니다.

(이 글은 데이원컴퍼니로부터 소정의 원고료를 지급받아 작성되었습니다.)

이제 마지막 달 남은 후기 (8월편) - 제로베이스 스쿨

Hyunebee — Wed, 31 Aug 2022 18:37:57 +0900

벌써 8월 아니 9월입니다. 7월에는 집안일과 몸이 아파서 공부를 많이 못한거 같아서 후회스럽습니다. 마지막 까지

열심히 해보겠습니다. 이번달은 팀프로젝트 위주로 공부를 했던거 같습니다. 진짜 팀프로젝트는 꼭꼭 할 수 있으시

다면 한번쯤은 해봐야합니다. 저는 앞으로 프로젝트 해본것을 더다듬어서 취업 전선에 참여할 것 같습니다. 그때 까지

모두 열심히 달려봅시다~

팀프로젝트 시작 전 준비

팀프로젝트 시작전 준비운동..? 네카라쿠베 강사님들의 프로젝트들을 먼저 배우고 팀프로젝트에 들어갑니다. 스프링을 사용하기 이전부터 사용한 이후 차이 현업에서는 뭐가 쓰이고 좋다..? 자기 경험을 이야기 해주십니다. 코드를 짜면서 점점 짜임새가 갖춰지고 코드의 재사용성 등등 고도화 작업을 직접 느끼실 수 있습니다. 항상 느끼지만 아는만큼 보이는 것 같습니다. 첫번째 두번째 뒤로 가면서 뭐가 이래서 그렇구나 여기서 이런 이유로 사용하는 구나 등등을 느끼는것 같습니다. 역시 뭐든 직접 쳐보면서 느끼는게 가장 배움이 빠른것 같습니다.

팀프로젝트 시작

제로베이스를 선택한 가장 큰이유중 하나 우수 수강생을 선정해 팀프로젝트를 진행하는 과정이였습니다. 한달? 5주? 정도 기간을 잡고 진행했습니다. 방식은 백엔드 3 프론트 2 이런식으로 진행했습니다. 여기에 전임강사님이 1주일에 한번씩 피드백을 한시간 가량 해주십니다. 항상 느끼는 것이지만 프로젝트를 한번씩 진행하는것이 강의를 10개 듣는것 보다 배우는게 많은것 같습니다. 물론 기초적인 지식이 탄탄하다면 더욱이 진행이 빠르겠지만 모르는것을 직접 찾아보고 팀원들에게 물어보면서 진행하는 방법이 빠르게 성장하는법이라고 저는 생각합니다. 그렇기 때문에 우수 수강생에 들고 싶어서 노력을 했습니다. 팀원들이 잘이끌어주고 알려주셔서 지금 프로젝트를 마무리 하는 시점 많은것을 배우는 것 같습니다. 하면서 기초적인 api 작성 팁이나 그간 개발하면서 생각하지 않았던 restAPI 양식, 보기좋은 코드등등 서로 피드백 하면서 더욱이 발전한것 같습니다. 꼭 신청하신다면 한번 해보시는것을 추천합니다.

프로젝트를 진행하면서 더욱이 느끼는 리펙토링

사진을 보면서 사람이 점점 진화하듯 코드도 저의 코드도 리펙토링을 통해 진화하고 있었습니다. 프로젝트를 진행하면서 한번에 바로 기능을 만든적이 없던것 같습니다. 두번 세번 네번 테스트를 하고 여기서는 이렇게 코드를 짜는게 더 좋겠다. 여기 코드는 뭐로 빼면 좋겠다. 이건 사용 안한다 등등 리펙토링을 참 많이 한것같습니다. 물론 한번에 정확하게 딱딱 만드는건 어렵겠지만 그 횟수가 많아지면 많아질 수 록 지치게 되는 것 같습니다. 하다보면 저런 리펙토링에 대한 기술? 같은건 찾기 어려웠었습니다. 하지만 그런 강의도 제공하고 있더군요!부록으로 주시는거 같습니다. 클린코드 나 리펙토링 같은 강의들은 이론도 많이 섞여있지만 한번쯤은 ? 아니 두번 넘게 들어도 된다고 생각합니다. 이런 부분은 쌓이면 쌓일수록 좋다고 생각합니다. 저는 이론 공부를 재밌어 하는 편이여서 잘듣고 있습니다.

(이 글은 데이원컴퍼니로부터 소정의 원고료를 지급받아 작성되었습니다.)

절반 달려온 지금의 느낌 - 제로베이스 스쿨

Hyunebee — Thu, 30 Jun 2022 23:02:31 +0900

Part1 통과 소감

벌써 수강한지 3개월이 지나가고 있어요.. 현재는 Part1의 과제를 제출하고 작성하는 중입니다. 자바 기초부터 CS지식 데이터베이스 JSP 스프링 등등 많을것을 배웠습니다. 아직 정리가 필요하긴하지만 전체적인 느낌을 알고가는 Part1이라고 생각하고 무사히(?) 끝낸것 같습니다. 주마다 하는 코테는 아직도 적응중이라는게 함정입니다.

프로젝트와 Part1

이번에 Part1에는 2가지 프로젝트가 있었어요! 하나는 공공API 데이터를 파싱해서 데이터베이스에 넣고 불러오는 JSP와

데이터 베이스를 사용했습니다! JSP는 큰 설명이 없어서 처음에는 어렵긴 했지만 과제로 나오니 어찌저찌 처리하게 되더

라구요. 이게 돈의 힘인가.. 했습니다. 아니면 저도 발전이 있었나봐요! . 두번째 프로젝트는 스프링을 이용한 간단한 계좌

생성 프로젝트인데 이게 생각보다 어렵긴 했지만 강의를 보면서 하면 할만했던것 같습니다. 강의가 긴 분량으로 상세하게

설명해준 바탕으로 다시 재구성하는 느낌으로 만들어보았습니다. 벌써 Part1에만 몇개의 프로젝트를 진행한것 같아요

취업할때는 조금 저만의 스타일로 재구성해서 정리해야겠어요!

Part1의 전체적인 강의 후기

장점

저는 항상 느끼는건데 이론을 배우든 실기를 배우든 ex) 즉 예시가 많은것을 참좋아하는데 일단 강의가 풍부하고 스프링

같은 경우는 세심한 부분까지 알려주셔서 저는 엄청 만족했습니다. 실무에서 이것을 사용하는 이유와 강사님 경험에서

저같은 경우~ 해서 ~했었습니다. 라고 알려주시더군요 강의도 하시던 일에서 기반으로 만드셨던거 같습니다. 이런 부분은

취업시 도움이 많이 될것같았습니다.

단점

장점이 단점이 될수도 있는데 양이 너무많은것도 단점일 수 있겠습니다. 만약 자바를 한번도 접하지 못한 분들이 따라오기

에는 이해보다는 단순암기? 쪽에 가까울수도 있겠다. 라고 생각했습니다. 중간에 생략하는 내용은 별로없지만 그에 따라

양도 방대하기 때문에 후반에 갈수록 무엇을 병행하면서 하는게 조금 부담스러울수도 있겠다~ 라고 생각했습니다.

이번주와 저번주 집안에 일이 생겨서 프로젝트를 꼼꼼히 못보고 제출한게 조금 아쉽긴하지만 혼자힘으로 했다는것에 만

족하고 제출했습니다. 그래도 만족하지않고 앞으로도 열심히!

앞으로의 계획..

제로베이스를 선택하게된 이유도 어찌보면 스프링 강의를 듣고 프로젝트를 진행해보기 위해서 였습니다. 그만큼 꼼꼼하

고 예제가 많았던 백엔드 부트캠프가 제로베이스였습니다. 자바의 봄이라는 스프링 기초부터 천천히 쌓아올려야 겠습니

다. 앞으로의 강의는 프로젝트 위주로 진행되는 것같아 프로젝트를 하면서 모르는 부분은 구글링을 해야겠습니다. 더욱이

필요하다면 책을 사서 볼생각입니다. 또 주마다진행하는 알고리즘 테스트도 있으니 매일 2~3문제씩 풀면서 감은 유지해

야할 것 같습니다.

(이 글은 데이원컴퍼니로부터 소정의 원고료를 지급받아 작성되었습니다.)

Lombok

Hyunebee — Thu, 23 Jun 2022 10:39:06 +0900

Lombok :

@Setter , @Getter
-Java Bean 규약에 있는 setter, getter를 자동으로 생성해줌

@ToString
-Object에 기본 구현된 ToString 대신 객체의 데이터를 보여주는 ToString을 자동 생성

@NoArgsConstructor
-No Argument Constructor, 파라미터가 없는 생성자를 만든다.
-만약 필드가 final로 설정되어 있는 경우 컴파일러 에러가 발생한다. 필드가 final로 설정되어 있는 경우@NoArgsConstructor(force = true)옵션을 사용하면 final 필드를 0,false,null 등으로 강제 초기화를 하여 생성자를 만들 수 있다.

@RequiredArgsConstructor
-final 필드 또는 @NonNull이 적용된 필드에 대한 인수가 포함된 생성자를 생성한다.

@AllArgsConstructor
-모든 필드에 대한 생성자를 생성한다.이 어노테이션으로 생성자를 생성할 때 모든 필드값이 적용되어야 한다.

@Data
-Getter, Setter, ToString, Equals등등 다양한 기능을 모두 제공

@Slf4j
-해당 클래스의 logger를 자동으로 생성

@Transactional
-선언적 트랜잭션 처리를 지원
-이 방식이 선언적 트랜잭션이고, 적용된 범위에서는 트랜잭션 기능이 포함된 프록시 객체가 생성 되어 자동으로
commit or rollback을 실행한다.

예외처리

Hyunebee — Thu, 16 Jun 2022 21:06:20 +0900

REST API로 예외 처리하기

전역 처리시 @RestControllerAdvice, ControllerAdvice

@ExceptionHandler 컨트롤러 기반 예외 처리

HTTP Status code를 변경하는 방법

@ResponseStatus

ResponseEntity 활용

예외처리 우선순위

1. 해당 Exception이 정확히 지정된 Handler

2. 해당 Exception의 부모 예외 Handler

3. 이도 저도 아니면 그냥 Exception(모든 예외의 부모)

@ResponseStatus 사용

@ResponseStatus(value = HttpStatus.FORBIDDEN)
@ExceptionHandler(IllegalAccessException.class)
public ErrorResponse handleIllegalAccessException(IllegalAccessException e) {
    log.error("Illegal Exception : ", e);
    return new ErrorResponse("ACCESS_DENIED", "Illegal Exception occurred.");
}

ResponseEntity 사용

@ExceptionHandler(IllegalAccessException.class)
public ResponseEntity<ErrorResponse> handleIllegalAccessException(IllegalAccessException e) {
    log.error("Illegal Exception : ", e);
    return ResponseEntity
            .status(HttpStatus.FORBIDDEN)
            .header("header", "some value")
            .body(new ErrorResponse("ACCESS_DENIED", "Illegal Exception occurred."));
}

필터와 인터셉터

Hyunebee — Thu, 16 Jun 2022 20:14:46 +0900

필터

스프링 외부에 존재 서블릿에서 제공하는 공통처리 기능

스프링 내로 요청이 들어오기 전과 스프링의 요청이 나갈 때 처리 기능을 함

조금더 low level의 처리가 가능하다.

인터셉터

스프링에서 제공하는 공통처리 기능

실제 매핑된 Handler 확인 가능

조금 더 상세한 조건식과 세부적인 스펙을 통해 구체적인 시점에 구체적인 동작이 가능하다.

AOP와 비교한다면 AOP는 인터셉터보다 더 구체적인 조건과 동작을 가진다.

실습

아래는 @Component를 통해 자동으로 스프링 컨테이너 부착

@Component
@Slf4j

public class LogFilter implements Filter{
    @Override
    public void doFilter(
            ServletRequest request, ServletResponse response, FilterChain chain //외부 -> filter -> 처리 -> filter -> 외부
    ) throws ServletException, IOException {
        log.info("Hello filter : " + Thread.currentThread());
        chain.doFilter(request, response);
        log.info("Bye filter : " + Thread.currentThread());
    }
}

간단한 get요청에 따른 filter장착

필터는 자동으로 컨테이너에 부착되지 않음으로 RegistrationBean을 해줘야함

@Configuration
public class WebConfig {
    //필터는 자동으로 컨테어너에 부착되지 않음 등록시켜줘야함
    @Bean
    public FilterRegistrationBean loggingFilter(){
        FilterRegistrationBean<Filter> filterFilterRegistrationBean = new FilterRegistrationBean<>();
        filterFilterRegistrationBean.setFilter(new LogFilter());
        filterFilterRegistrationBean.setOrder(1);
        filterFilterRegistrationBean.addUrlPatterns("/*");


        return filterFilterRegistrationBean;
    }
}

인터셉터 등록

인터셉터 또한 이 상태로 둔다면 클래스와 다름없음 등록을 해줘야함

@Slf4j
public class LogInterceptor implements HandlerInterceptor {
    @Override
    //요청시 try와 같은 느낌
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        log.info("preHandle Interceptor : " + Thread.currentThread());
        log.info("preHandle handler : " + handler);
        return true;
    }

    @Override// 요청이 성공하면
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
        log.info("postHandle Interceptor : " + Thread.currentThread());
    }

    @Override// 요청이 성공하든 실패하던
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        log.info("afterCompletion Interceptor : " + Thread.currentThread());

        if (ex != null) {
            log.error("afterCompletion exception : " + ex.getMessage());
        }
    }
}

해당 @Configuration에 WebMvcConfigurer를 구현 addInterceptors를 추가해줘야 한다.

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1).addPathPatterns("/*")
                .excludePathPatterns("/css/*", "/image/*");
    }

    //필터는 자동으로 컨테어너에 부착되지 않음 등록시켜줘야함
    @Bean
    public FilterRegistrationBean loggingFilter(){
        FilterRegistrationBean<Filter> filterFilterRegistrationBean = new FilterRegistrationBean<>();
        filterFilterRegistrationBean.setFilter(new LogFilter());
        filterFilterRegistrationBean.setOrder(1);
        filterFilterRegistrationBean.addUrlPatterns("/*");



        return filterFilterRegistrationBean;
    }
}

해당 로그들을 보면 filer -> 인터셉터 -> 처리 -> 인터셉터 -> filter순인것을 확인가능

스프링 MVC의 기본 HTTP요청 매핑

Hyunebee — Thu, 16 Jun 2022 19:11:14 +0900

Controller와 restController의 차이

Controller : 응답값이 기본적으로 HTML을 주도록 되어 있음

RestController : 응답값으로 Rest API 요청에 대한 응답(주로 JSON)을 주도록 되어 있음

축약형 매핑 어노테이션 -> 스프링4.3 부터

@GetMapping : 데이터를 가져옴
@PostMapping : 데이터를 전송함
@PutMapping : 전체 수정
@PatchMapping : 일부 수정
@DeleteMapping : 삭제

스프링 HTTP 요청 파라미터 전송

파라미터를 넘기는 법(Get, Delete)

1. PathVariable : id를 path에 넣는것을 선호

@PathVariable(”id”) String identity;
하지만 이름이 같으면 생략 가능
여러개를 넣을 수 있음

(" ")안의 내용과 String ?? 이름이 같으면 생략가능하다.

2.query-params : 추가적인 정보들 입력 요청시 /order/orderId=?&orderAmount

게시판의 검색 필터 페이징에서 많이 사용
@RequestParam 사용법

PathVariable처럼 이름을 동일하게 하면 자동으로 받아줌
- Map, MultiValueMap으로 요청 받는 방법 -> 하나의 키에 여러값이 있을 경우

파라미터를 넘기는 법(Post, Put, Patch )

@RequestBody : http body 정보를 편리하게 받을 수 있음 주로 사용하는 메시지 포맷은 JSON(현재 사실상의 표준) @RequestHeader : http header 정보를 편리하게 받을 수 있음

Valudation, Data Binding, SpEL

Hyunebee — Thu, 16 Jun 2022 13:12:09 +0900

Validation - 유효성 검증

주로 사용자 or 타 서버의 요청에 대해 잘못된 내용이 있는지 확인하는 행위

Validation

1. 데이터 검증

필수 데이터의 존재 유무, 값의 범위, 특정 형식 데이터 등

2. 비지니스 검증

서비스에 정책에 따라 데이터를 확인하여 검증

Spring Validation

스프링은 웹 레이어에 종속적이 지 않고 2가지 방법으로 진행 -> 둘다 데이터 검증에 가까움

1.Java Bean Validation

JavaBean 기반으로 간편하게 개별 데이터 검증 어노테이션으로 검증 방법을 명시해줌

위 사진 처럼 dto에 어노테이션에 명시후

아래 사진처럼 @Valid를 RequestBody에 달아 검증을하고 이상이 없을시 메서드 내부를 실행한다.

2.Spring validator 인터페이스 구현을 통한 validation

support는 Validator가 동작할 조건을 정의해준다. 주로 class의 타입을 비교한다. validate()에서 원하는 검증을 진행

Data Binding

사용자나 외부 서버의 요청 데이터를 특정 도메인 객체에 저장해서 우리 프로그램에 Request에 담아주는 것을 뜻한다.

1.Converter<S,T> Interface

S(Source)라는 타입을 받아서 T(Target)이라는 타입으로 변환해주는 Interface

내부 구조

x-auth-user는 Json 형식의 문자열 @RequestHeader를 살펴보면 x-auth-user의 헤더를 XauthUser객체로 받을려고함 이때 아래 사진의 converter를 사용하게 됨

해당 컨버터는 Spring bean에 등록 -> 스프링 내에 ConversionService라는 내장된 서비스에서 Converter 구현체 Bean들을 Converter 리스트에 등록-> 이때 <S,T>가 일치하게 되면 해당 Convert가 동작

2.Formatter

특정 객체 ↔ String간의 변환을 담당

print : API 요청에 대한 응답을 줄 때, Date형식으로 된 데이터를 특정 locale에 맞춘 String으로 변환 parse : API 요청을 받아올 때, String으로 된 "2021-01-01 13:15:00" 같은 날짜 형식의 데 이터를 Date로 변환하도록 함

SpEL(스프링표현언어)

스프링에서 주로 많이 활용되는 부분

@Value("${config.value}")와 같은 방식으로 설정값을 주입 받는데 활용

이떄 ""안에 들어있는 문자열을 평가해서 결과값을 만들어 낸다. 리터럴과 메서드도 같이 호출할 수 있다.

예시

OOP와 스프링

Hyunebee — Fri, 10 Jun 2022 16:27:27 +0900

OOP를 왜 사용할까?

소프트웨어의 복잡성을 제어하고 관리하기 가장 쉬운 대중적인 방법이다.

OOP란?

데이터(상태)와 로직(행위)이 응집되어 상호 교류하여 동작하도록 만드는 기법(ex) 상속, 캡슐화, 다형성)

1. 분류 > Class

Class는 프로그램의 코드를 체계적으로 분류하고 같은 역할을 하는 코드를 응집성 있게 모아준다.

2. 교체 > 유지보수

경우에 따라 특정 모듈을 통째로 변경해야 할 수 도 있음

OOP를 잘하려면?

SOLID 원칙을 준수!

1. SRP - 단일 책임 원칙 : 한 클래스는 단일의 책임을 가져야 한다.

단일? 책임? 둘다 모호함

2. OCP - 개방 폐쇄의 원칙 : 확장에는 열려있고, 변경에는 닫혀있다.

수정하지 말고 신규 클래스를 추가하자!

3. LSP - 리스코프 치환 법칙 : 서브 타입은 언제나 기반타입으로 교체할 수 있어야 한다.

상속받는 클래스는 부모 클래스와 동일한 동작을 해야 재활용 가능성이 높아진다.

실무에서는 상속을 잘 사용하지 않음

1. 상속 시 오버라이드를 한것과 아닌것의 혼란

2. 상속 오버라이드를 잘못하면 로직충돌 -> Fragile base class

3. 기능을 너무 확장하거나 변경하면 재활용성 낮아짐

Fragile base class
부모 클래스의 변경에 의해 자식 클래스가 영향을 받는 현상
자식 클래스를 점진적으로 추가해서 기능을 확장하는 데는 용이하지만 높은 결합도로 인해 부모 클래스를 점진적 으로 개선하는 것은 어렵게 만든다.
자식 클래스가 부모 클래스의 구현 세부사항에 의존하도록 만들기 때문에 캡슐화를 약화 시킨다.

또 다른 상속의 문제점
https://velog.io/@swucs/10%EC%9E%A5-%EC%83%81%EC%86%8D%EA%B3%BC-%EC%BD%94%EB%93%9C-%EC%9E%AC%EC%82%AC%EC%9A%A9

4. ISP - 인터페이스 분리 원칙 : 인터페이스 또한 단일 책임을 갖도록 분리해야 한다.

5. DIP - 의존성 역전 원칙 : 하위 모듈의 변경이 상위 모들의 변경을 요구하는 의존성을 끊어 내야 한다.

기존 라이브러리 사용 -> 다른 라이브 러리로 변경시 강결합이라면 코드 전체를 수정해야할 수 도 있음

스프링과 SOLID

https://www.javaguides.net/2020/07/three-tier-three-layer-architecture-in-spring-mvc-web-application.html

1.Presentation layer: 응용프로그램의 기능과 데이터를 사용자에게 제공하는 응용프로그램의 사용자 인터페이스입니다.

2.Business logic (or Application) layer: 이 계층에는 애플리케이션의 핵심 기능을 주도하는 비즈니스 로직이 포함되어 있습니다. 의사 결정, 계산, 평가 및 다른 두 계층 간에 전달되는 데이터 처리와 같습니다.

3.Data access layer (or Data) layer: 이 계층은 데이터베이스와 상호 작용하여 응용 프로그램 데이터를 저장하고 복원합니다

스프링은 표준적인 레이어 별 역할을 나눠주기 때문에 SRP를 도와줌 각 Class마다 역할이 더 명확해짐

Git 사용법

Hyunebee — Mon, 6 Jun 2022 09:28:33 +0900

Git 사용자 설정

git config : Git에 관한 설정을 추가/삭제/변경하는 명령어

1. System 설정 파일 : 모든 시스템 사용자에게 적용
2. Global 설정 파일 : 한 사용자의 전체 Git Repository에 적용
3. Local 설정 파일 : 하나의 레포지토리에 적용

git config -- ~로 사용

ssh key - github연동

1. ssh-keygen 명령어 사용
2. 이름설정
3. 비밀번호 설정
4. cat으로 내용확인후 key에 복붙하기

git 초기화

git init -> 해당 폴더 자체가 Local Repository가 된다고 생각하면됨

명령을 실행하면 .git/ 폴더 생성
config등 다양한 설정파일이 들어있음

.gitignore

사용자가 git에 등록되지 않길 원하는 파일 또는 폴더들의 목록을 저장
.gitignore에 등록된 파일들은 커밋 시 자동으로 제외됨

- 폴더 : /폴더명 (예: /docs)
- 파일 : 파일명.확장자 (예: test.txt)
- 폴더 안 파일 : /폴더명/파일명.확장자 (예: /docs/test.txt)
- 폴더 안 특정 확장자 파일 전부 (예: /docs/*.text)
- 폴더 하위 모든 특정 확장자 파일 전부 (예: /docs/**/*.txt)

https://www.toptal.com/developers/gitignore/ gitignore생성 사이트

Git 기본 공간 구조

Working Directory : 작업하는 파일이 있는 폴더
Staging area : Git에 등록할 파일들이 올라가는 영역(깃에 등록하기전에 임시거처(?))
Local Repository : 로컬 Git 프로젝트의 메타데이터와 데이터 정보가 저장되는 영역
Remote Repositroy : 온라인 상의 저장소

Git 기본용어

origin : 원격 (Github 등의 온라인 저장소)에 있는 코드
head : 내가 지금 작업하고 있는 로컬 브랜치
add : Working Directory에서 Staging Area로 등록하다
commit : Staging Area에 등록된 파일을 Local Storage로 등록
Commit Message : commit 시 함께 작성해 저장하는 메시지 (메모)
push : Local Storage에서 변경된 파일들을 Remote Repository로 등록
fetch : Remote Repository의 변경된 파일들을 Local Repository로 전달
merge : Local Repository의 변경사항을 Working Directory로 전달
Branch : 독립적으로 어떤 작업을 따로 진행하기위한 가지
checkout : 사용할 다른 브랜치를 지정

Clone

Git Remote Repository에 있는 내용을 복사해 나의 PC로 저장
1.HTTPS를 사용 -> 보안에 취약
2.SSH -> 권장하는 편이다.

ADD, COMMIT, PULL, PUSH

ADD : 변경된 파일 중 Repositroy에 올림
Commit Add: 등록된 파일들을 한 덩어리로 만들고 메시지를 추가해 로컬저장소에 올려줌
Push : 원격저장소에서도 반영을 해줌
Pull : 원격 저장소의 변경사랑을 로컬 저장소로 가져옴으로 동시에 작업소스와 합쳐줌

Fork 복제

다른 사람의 원격 저장소에서 어떤 부분을 수정하거나 추가 기능을 넣고 싶을때 해당 원격 저장소를 내 원격 저장소에 그대로 복제하는것
Clone과는 내 로컬에 저장 원격에 저장 이런 부분이 다름

Pull Request

다른 사람에게 내 브랜치를 Merge해 달라고 하는 요청