본문 바로가기

TIL

(126)
POJO(22.11.05TIL) 오늘 클린코드 북스터디에서 AOP 부분을 읽었다. 로버트 마틴 아저씨는 계속해서 POJO를 사용해야 한다고 울부짖었는데 POJO가 어떤것인지 몰라서 정확한 메시지는 이해하지 못했다. 하지만 전달하려는 메시지는 어떤 것을 설계하던지 간에 가장 간단한 방법으로 구현해야 한다는 것이라고 들렸다. 스프링 주차때 잠깐 POJO를 본 것 같은데 정확히는 모르는 것 같아서 한번 찾아보았다. POJO란 POJO의 풀네임을 한번 살펴보자. Plain Old Java Object => 오래된 방식의 간단한 자바 오브젝트를 의미한다. 더 정확하게 말하면 자바 언어 사양 이외에 어떠한 제한에도 묶이지 않은 객체라고 할 수 있다.(특정 기술의 상속과 구현을 하지 않은 객체) 근데 간단한 자바 오브젝트인데 왜 이렇게 있어보이는 ..
모범답안(22.11.04TIL) 인터뷰 시간에 뽀그로타이머를 리뷰받으면서 노아님의 코드를 볼 기회가 생겼다. 지금까지 메가테라에서 트레이너 님의 코드들을 직접 볼 기회가 없었기 때문에 모범적인 코드는 어떻게 다른가 파헤쳐보았다. 추상화 레벨 역시 고수의 코드는 가독성이 뛰어나다. 프론트엔드에서 추상화 레벨에 대해 까맣게 잊고있었는데, 노아님의 컴포넌트들을 보면 전부 jsx 마크업 부분이 styled components로 추상화레벨이 맞춰져있다. 적절한 네이밍까지 하니 각각의 마크업이 어떤 역할을 하는지 바로바로 파악할 수 있었다. 응집도 높은 코드 이번 과제에서 타이머의 카운트다운에 대한 로직을 구현할때 일시정지, 끝났을때 등등 예외처리를 진행하면서 곳곳에 로직들이 흩뿌려져 있었는데, 노아님의 코드는 countdown이라는 메서드 안에..
AJAX(22.11.03TIL) 오늘은 공부하면서 얼핏 들어본 AJAX라는 친구에 대해서 한번 알아보자! AJAX란? 먼저 AJAX의 정의부터 알아보자면 Asynchronous JavaScript And XML이다. 조금더 풀어쓰면 서버와 비동기적으로 데이터를 주고받는 자바스크립트 기술을 의미한다. 이렇게 말하면 전혀 와닿지가 않으니 먼저 서버와 데이터를 어떻게 주고받는지 부터 한번 알아보자. 요청과 응답 우리가 브라우저에서 원하는 내용 (유튜브, 네이버 웹툰...)을 보려면 서버에 원하는 데이터를 요청해야 한다. 서버는 우리가 요청한 데이터를 찾아서 돌려준다(응답). 하지만 서버에 데이터 요청을 보낼때는 두가지 규칙을 지켜야 한다. 1. 정확한 데이터 URL을 전달해야 한다. 2. GET요청을 통해서 URL을 전달한다. GET요청을 ..
FLUX(22.11.02TIL) 어제 TDD에 이어서 이번주 핵심키워드인 FLUX를 왜 써야할까에 대해서 다시 조사해보았다. Flux, 왜 필요할까? 플럭스는 단방향 데이터 흐름을 보다 예측가능하게 관리할 수 있는 클라이언트 사이드 웹 어플리케이션 아키텍쳐이다. 초기의 웹 어플리케이션에서는 단순한 문서 열람만 하면 되었지만 AJAX, REST가 나오면서 클라이언트 사이드에서 복잡한 로직을 처리할 필요가 생겼다. 근데 왜 단방향 데이터 흐름이 필요할까? MVC의 양방향 데이터 바인딩의 문제점 플럭스 이전에는 MVC패턴을 이용해서 프론트엔드 코드를 작성했다. 하지만 프레임워크를 구현하면서 MVC에서는 실제 개념과 다르게 계층끼리 서로 업데이트를 시키는 양방향 데이터 바인딩이 발생한다. 결국 어플리케이션이 복잡해지기 쉽다. 이로 인해서 디버..
왜(22.11.01TIL) 인출을 하다가 컴포넌트만 테스트하는게 보여서 기존과 테스트 방식이 좀 다르게 느껴졌다. 강의에서 나온 내용이니 프론트엔드는 원래 컴포넌트만 테스트하나보다~ 라고 생각을 했다. 혹시몰라서 질문 게시판에 여쭤보았는데 내가 잘못 생각하는 부분을 짚고 넘어갈 수 있었다. 답변 홀맨님과 아샬님께서 해주신 답변은 당연히 비즈니스 로직을 테스트해야된다였다. 이번주차에서 하고있는 내용은 스프링으로 치자면 WebMVC 테스트에서 MockMVC부분이라고 생각하면 되는데, 한마디로 모킹에 관련된 강의 내용이라고 보면 된다. 비즈니스 로직을 제대로 테스트하기 위해 부수적인 수단을 배우는 주간이라고 생각하면 된다. 테스트는 항상 핵심 부분인 비즈니스 로직을 우선적으로 테스트 해야하고, 핵심적인 부분으로 내려갈수록 프레임워크들의..
부수효과(22.10.31TIL) 주말간 useEffect를 정리하면서 반복해서 나온 키워드가 있다. 부수효과. DOM업데이트를 수행한 이후에 부수효과를 일으키는 함수들을 effect라고 하고 useEffect를 통해 effect를 처리한다고 한다. 근데 부수효과가 도대체 뭐하는 친구인지 궁금해서 한번 정리해보았다. 부수효과란? 프로그래밍에서 부수효과란 함수가 어떤 동작을 할때 input - output 이외의 다른 값을 조작한다면 이 함수에는 부수효과가 있다고 표현한다. 리액트에서는 state와 props를 받아 UI를 그리는 주 기능외에 일어나는 모든 부수적인 효과를 side effect라고 할수 있다. 함수 컴포넌트에서의 부수 효과는 렌더링이 아닌 외부 세계에 영향을 주는 어떠한 행위라고 할 수 있다. 실제로 어떤 것들이 있는지 살..
테스트하기 좋은 코드?(22.10.30TIL) 어제 모킹에 관해서 아샬님의 영상을 보고 문득 테스트하기 좋은 코드는 무엇일지 궁금해져서 검색하다가 조졸두님의 블로그 글에서 좋은 내용을 찾았다. 테스트하기 좋은 코드는 어떤 건지 한번 살펴보자! 테스트가 필요한 곳 일단 테스트가 어디에 필요한지부터 고민해보자. 우리가 핵심을 기울여서 검증해야 할 곳은 비즈니스 로직이다. 결국 도메인을 우선으로 테스트해야 한다는 것이다. UI Layer를 검증하기 위해 대부분의 시간을 쏟고 있다면 주객이 전도된것이다. 테스트를 짜기 어려운 이유 보통 테스트에서 어려움을 겪는 이유는 어려운 구현체를 테스트하려고 하기 때문이다. 결국에는 실제 코드의 구조가 잘못되었기 때문에 테스트하기가 어려워진다. 극단적으로 말하면 테스트하기 쉬운구조로 코드를짰을때 모킹도 거의 필요없다고 ..
모킹(22.10.29TIL) 강의에서 모킹에 대한 내용이 많이 나왔는데, 모킹을 어느 수준까지 구현 해야하는지 판단이 서지 않아서 아샬님의 유튜브 영상을 참고하였다. 모킹을 써야하는 이유? 모킹은 빠르고 생산성 있는 개발을 위해서 우리가 대역을 맡을 수 있는 객체를 새로 만들어서 사용하는 것이다. 우리가 임의로 정하는 만큼, 모킹을 적절히 이용하면 이득이 되지만, 모킹에 에너지를 너무 많이 쏟으면 주객전도가 되어있을 확률이 높다. 아샬님이 말씀해주신 모킹으로 인해 구조가 잘못되어 있는 케이스를 살펴보자. 1. 모킹을 너무 많이해서 어렵다 설계가 잘못 되었을 확률이 높다. 보통 모킹을 필요로 하는 부분은 많지 않다. 2. 설계가 제대로 되었는데, 모킹을 많이해야한다? 본질이 아닌 부분을 짚고 있을 가능성이 크다. 보통 핵심 로직으로 ..
가고싶은 회사 찾아보기(22.10.28TIL) 오늘 코딩인터뷰를 하면서 이전보다 텐션이 떨어진것을 노아님께서 캐치해주셨다. 동기부여를 해주시려고 가고싶은 회사가 있는지 여쭤 보셨는데, 다시 한번 현실을 자각하는 시간을 가질 수 있었다. 좋은회사? 고등학생들이 가고싶은 대학교를 견학가는 것처럼 목표로 하는 회사를 미리 정해두는 것도 동기부여를 할 수 있는 방법중 하나라고 생각한다. 근데 좋은회사를 내가 어떻게 판별하지? 어떤 기준으로 좋은 회사를 파악할 수 있는지 노아님에게 여쭤보았다. 일단 매출이 잘나오는 회사를 가자. 스타트업 한파라고 불리는 요새는 일단 안정적으로 돈이 나와야 한다. 이 기준으로 1차로 회사를 걸러야 한다. 입에 풀칠은 해야 성장을 생각하던지 하겠지? 회사에 개발팀이 있나? 개발팀이 없는 경우는 보통 사수도 없고 혼자서 주먹구구식..
단위 테스트(22.10.27TIL) 오늘 클린코드 북스터디에서 단위테스트에 대한 내용을 읽었다. 사실 귀찮다는 이유로 단위테스트를 제대로 안짚고 넘어가는 부분들이 많아서 조금 찔리는 구절이 있었다. 특히 코딩도장 같은경우에 실제 코드에서 여러 메서드로 분리했음에도 귀찮다는 이유로 그냥 핵심 메서드 하나만 가지고 테스트를 진행한다. 먼저 단위테스트가 왜 필요한지 알아보면서 반성하는 시간을 가져보자. 단위 테스트를 왜 해야 할까? 테스트를 짜는 이유는 기존에 쌓여있는 테스트를 믿고 걱정없이 새로운 코드를 짜도 쉽게 문제를 파악할 수 있는 통제 가능성에 달려있다. 그리고 또 한가지 중요한 기능이 있다. 테스트 코드만 보고도 이 프로그램의 스펙을 알 수 있어야 한다. 그러기 위해서는 당연히 가독성이 중요하겠지? 그래서 무조건 하나의 테스트에는 하..