오늘 공부할 내용

• 오전 복습
• 오후 수업
• 저녁 수업
• TiL 정리 및 Git & 블로그 업데이트

오늘 공부한 것 & 배운 내용

어제 수업 복습

• MockMvc 인코딩 문제를 해결해나가는 과정에서 스프링 부트에 Characterset filter를 적용하는 과정에서 최신 블로그글에서 정보를 보고 적용하는데 그것도 이미 오래된 정보가 되는 경우에 대해서 말씀해주셨다

  • 위의 예처럼 오래된 정보를 재생성 하는 경우도 생기기 때문에 정보를 찾을 때는 항상 공식문서를 기준으로 찾는게 좋은 방법이라는걸 보여주신 것 같다

  • 하지만 때로는 공식 문서 외에서 자료를 찾아야 되는경우도 분명히 있기 때문에 그럴때 어떻게 더 좋은 자료들을 찾을 수 있는지 연습해보는것은 도움이 많이 될 것 같다

  • 참고로 MockMvc 인코딩 문제는 MockMvc를 생성할때 filter를 달아줌으로 해결이 가능한 문제였다(MovckMVc 자체에 인코딩문제)

• Presentation Layer단에 진행하는 테스트 종류에는 브라우저 테스트, 호출 테스트(.http), mockMvc테스트가 있고 브라우저 테스트가 가장 정확하지만 시간이 오래걸리고 반복적인 작업을 하다보면 실수로 테스트를 누락하는 경우가 생길수 있어 반복이 가능한 정확도는 비교적 낮지만 반복이 가능한 mockMvc테스트와 병행하여 진행하다고 배웠다

  • 브라우저 테스트를 진행해야 하지만 개발 환경상 하나하나 진행하지 못하는 경우가 많기 때문에 호출 테스트나 mockMvc테스트가 필요한게 아닐까 생각이 들고 적절히 보완하면서 기능들을 테스트해나가는게 좋은 방법 인 것 같다
  • 개발 서버 테스트 -> 베타서버 테스트-> 운영서버 테스트 식으로 여러번의 검증 절차를 밟아 가면서 변경내용을 서비스에 적용해나간다는 것도 말씀해주셨는데 누군가 개발을 ''달리는차에 바퀴를 바꿔 끼는 작업''이라고 말했던게 떠올랐다

• 어제 수업중에 가장 강조하신 내용을 오류(장애)를 대하는 태도에 대해서 말씀해주셨다

  • 프로그래밍 과정중에서 오류는 발생할 수 밖에 없는 것이기 때문에 오류가 생기는 것이 당연하니 이런 오류를 빨리 찾아내고 고치는 방향으로 개발을 해나가는게 좋은 개발 방식이다.
    • 오류를 빠르게 잡아낸다는 것은 비용과 직결된 얘기로 개발자의 생산성으로 이어진다
  • 컴파일 에러 -> 테스트 에러 -> Springboot run에러(스프링 컨테이너 띄웠을대 에러 - runtime 초기) -> 브라우저, 실환경 runtime에러(대부분의 장애는 여기서 발생) -> 논리적인 runtime에러(100원을 이체했는데 1000원이 빠져나간다든지)
    • 앞에서 뒤로 갈수록 비용이 많이들어가는 에러이고 특히 논리적인 에러의 경우 발견하기도 어렵고 발견시점에는 고객들에게 피해가 가서 소송등 막대한 피해가 발생할 수 있다
    • 그렇기 때문에 목표는 오류들을 최대한 앞쪽에서 발견할 수 있도록 개발을 해나가는 것이고 그렇기 때문에 변수에 final을 붙여서 다른곳에서 수정이 불가능하게 한다던지 테스를 열심히 짜서 사전에 이런 오류들을 발견할 수 있도록 하는 것이다.
      • c에서 다중상속에 에러가 자꾸 발생하니 java에서는 언어적으로 다중상속을 막아서 컴파일 에러나게 한것이 이런 에러를 방지하기 위한 대표적인 예라고 하셨다
    • 또한 잘 만든 테스트란 자바코드를 고치면 바로 테스트 에러가 발생하되 이상적으로는 SRP가 완전히 지켜져서 고친곳 한군데서만 에러가 발생해야 되고 현실적으로는 어렵기 때문에 최소한의 범위에서 에러가 발생해야되는게 잘만든 테스트의 기준이라고 하셨다
  • 이런 오류를 대처해 나가는 방식의 개발 방식 혹은 태도는 습관이고 방향이기 때문에 처음부터 인식하고 공부를하고 개발을 해나가면 좋은 개발자가 될수있을 것이라고 하셨다
  • => 개인적으로는 이렇게 좋은 개발자가 되는 부분들이 나에게는 동기부여가 많이 되는 것 같다. 대단한 기능을 만들기보다는 신뢰성있고 소통가능하고 확장가능한 코드를 만들 수 있는거 자체가 의미가 있어보이고 또 추구해야할 방향이라는 걸 확인할 때마다 좋은 개발자가 되고 싶은 마음이 샘솟는다

• DTO (Data Transfer Object )

  • DTO와 VO의 차이

    • 둘다 값을 가진 객체라는 것은 같지만 DTO는 값을 전달하기 위해 사용되고 VO는 값을 담기위한 객체로 entity도 vo처럼 볼수 있다
    • DTO를 통해 view 에서 controller로 데이터의 전달이을 하게 된다
      • 둘다 presentation layer이지만 프론트엔드 영역과 백엔드 영역사이에서 정보의 전달이 일어나는 부분이라고 생각해야 한다
    • 입력받는 값을 모두 파라미터로 전달하면 파라미터가 너무 늘어나서 좋지않은 코딩이 되기에 DTO객체를 만들어 객체 단위로 파라미터를 받아주게 된다
      • 해당 dto로 모두 받아주지못할 경우 새로운 dto로 만들거나 파라미터로 빼주기도 한다
    • jason으로 입력받은 파일을 객체에 변수에 넣어주는 것을 바인딩이라고 한다

  • Jason -> DTO의 경우 Jaon은 모두 String 임으로 Dto의 변수에 맞게 파싱을 해서 값을 넣어주게 되는데 이과정에서 String을 해당 자료형으로 파싱할수 없는 경우 에러가 발생하게 된다

    • DTO의 변수를 모두 String으로 하면 이런 문제는 해결되겠지만 이후에 또 파싱하여 사용할때 문제가 발생할 수 있기 때문에 최대한 자료형을 맞추어서 전달해주어 여기 단계에서 에러를 해결하고 나가는게 더좋은 방식이다

• Json(JavaScript Object Notation)

  • 데이터를 주고받는데 사용되는 문서의 양식
    • jason.org에서 자세한 정보를 알 수 있다
  • 이전에 파일방식, xml방식을 거쳐 현재 거의 표준처럼 사용되는 포멧이 되었다
    • .yml 파일도 변형된 json 포멧이라고 보면된다
  • 객체, 문자열, 숫자, key/value(map), 배열(List), boolean, null만 지원한다
    • 객체는 {}안에 들어가는데 json이 {}으로 시작해 스스로 객체임을 뜻한다
    • 또한 객체안에 객체가 있게 {}을 중첩하여 사용하여 계층 구조를 사용할 수 있다
  • 코드가 아니라 데이터 이기 때문에 주석이 없다

• Ajax

  • joson이 데이터 규격이라면 ajax는 통신 규격이다
    • json을 주고받는 통신규격이라고 생각하면 된다
    • 클라이언트 사이드에서 랜더링 할때 ajax를 통해 백엔드에서 만들어놓은 api를 사용해 jason형식으로 서버에서 데이터를 가져와서 랜더링을 하는데 사용된다
  • 클라이언트 사이드랜더링과 서버사이드 랜더링을 이해해야 한다
    • 클라이언트 사이드 랜더링은 클라이언트 쪽에서 웹페이지를 생성하는 것을 뜻한다
      • 페이지를 통으로 랜러링 하는 것이 아닌 부분부분 나누어 랜더링해서 여러번 서버와 통신하게 된다
        • 그렇기 때문에 장애가 생기더라도 전면장애가 아닌 부분장애가 발생하게 된다
      • 클라이언트의 성능이 좋아져서 서버의 부화를 줄일 수 있어서 전체적 속도가 올라갈 수 있게 된다
      • 이를 비동기 방식이라고 하고 반대로 서버사이드랜더링을 동기 방식이라고 한다.
    • 브라우저가 캐싱을 하고 필요한 데이터만 가져와서 채우는 방식으로 진행되기 때문에 빠르다
      • 서버사이드에서는 캐싱이 이루어지지 않고 모두 다 받기 때문에 느리다
    • 현재는 클라이언트 사이드 랜더링이 주로 사용되기 때문에 백엔드는 클라이언트 사이드 랜더링에 필요한 데이터를 넘겨줄 api를 잘 개발해주면 된다.
      • 이렇게 분화된 이유는 클라이언트 단이 굉장히 복잡해져서 서버 관리자가 모두 하기는 어려워져서 역할에 분리가 일어났기 때문이다.
      • 일종의 SRP가 일어나게 된것이고 점점더 분화가 이루어져서 각각의 전문성을 살리게 됬다
  • 프론트엔드와의 협업
    • 이전에 서버에서 뷰와 데이터를 모두 관리하던 것이 이제는 철저히 뷰는 프론트에서하고 백엔드에서는 데이터만 담당하게 된다
    • 그것을 위해 API개발에 필요한 url정보와 어떤 데이터를 넘겨줄지에 대한 협의가 필요하다
    • 설정을 통해 바인딩 과정에서도 개입할 수 있기 때문에 나중에 이부분은 필요할때 활용하면 된다

• Object Mapper

  • Jason을 오브젝트로 매핑해주는 클래스이다.
    • Java에 Serialziable 인터페이스 있지만 Java에서만 사용할 수 있고 버전에 따라 또 갈리기 때문에 플랫폼상관없이 사용할 수 있는 Json을 활용하기 위해 ObjectMapper를 활용하게 된다
  • 구현체는 다양한 형식의 파일 포멧이 될 수 있지만 현재 json이 주류이기 때문에 spring에서는 json mapper인 jackson을 기본적으로 지원한다

내일 공부할 내용

• 주간 수업 복습
• 알고리즘 과제
• 프로젝트 진행
• TiL 정리 및 Git & 블로그 업데이트