과거의 내가 미래의 나에게

최근 제품에 대한 테스트 혹은 자동화 테스트의 중요성에 대해 평소보다 더 실감하고 있다. 기능이 추가되거나 버그의 수정이 이루지거나 혹은 리팩토링을 진행했을 시, 내가 기껏 만들어놓은 코드들이 정상 작용할 지에 대한 두려움은 항상 깔려있고 개발을 완료한 후 직접 하나하나 눌러보면서 간단한 알파테스트를 진행해보지만 동일한 화면에서 매번 같은 테스트가 진행되고 있지는 않은 것 같다. 한 화면에 대한 QC 리스트를 작성하여 이에 따라 테스트를 진행하면 되지만 기능의 추가수정이 있다면 QC 리스트도 같이 업데이트가 되어야할텐데 이러한 작업도 생각보다 공수가 드는 것이다.테스트를 한다는 것은 서버에서 기능 단위로 작업한다고 생각하면 좀 더 쉽게 와닿았다. 하지만 화면을 그리는 프론트단은 어떤식으로 테스트를 하는 ..

새로운 기능이 담긴 페이지를 작업하고 있다. 해당 페이지에서는 일정 시간마다 API 통신을 요청하여 새로운 데이터를 받아와 화면에 표출하는 것인데, 나는 가벼운 마음으로 setInterval을 통해 이를 작업하려 했다. 그러나 setInterval이 정확한 시간을 보장하지 않는다는 정보를 듣고 큰 느낌표를 띄웠고! 오늘 이에 대한 이유를 명확히 분석해보는 시간을 가져보려한다.  n초 뒤에 실행하는 것이 아닌 타이머 API들let first = new Date().getTime()// setIntervalsetInterval(()=>{ const second = new Date().getTime() console.log(second - first) first = second},1000)// setTi..

원래는 웹서버를 마저 공부해야하지만... ngnix는 본격적으로 책을 통해서 공부해보고 싶기에 일단은 넘어가고 나중에 다시 쓰겠다. 오늘은 웹 브라우저가 웹 페이지에 대한 정보를 받은 후 어떻게 표출하는 지에 대해 공부해보았다.  렌더러 프로세스웹 브라우저는 발전해오면서 단순한 구조의 프로세스에서 사용자 인터페이스와 렌더링 사이의 중개자 역을 하는 브라우저 프로세스, 페이지 로드에 필요한 요청을 하거나 HTTP(s) 프로토콜을 통해 서버와 통신하는 등의 네트워크 프로세스 등 다양하고 모듈화 된 구조로 발전하였고 이런 여러 모듈들을 통해 브라우저를 구성하게된다. 이 중 오늘 집중할 것은 렌더러 프로세스이다. 렌더러 프로세스는 브라우저에서 서버로부터 받은 자원을 해석하고 화면에 표출하는 역할을 한다. 다양한..

저번 글에는 chunked를 봤는데, 개발자가 임의로 데이터로 끊어서 보내는 것 외에도 일정 크기로 쪼개서 보내는 것을 테스트해봤다. 그리고 이번 공부로 깨달은 바를 또 서술하겠다.  Stream과 Buffer그 전에 조금만 더 추가로 이론을 보충하자면... 파일을 전송할 때의 방식은 Stream과 Buffer로 나뉜다(다른 방식도 있지만 대표적인) 스트림은 데이터가 연속적으로 흐르는 통로를 뜻하며 데이터가 입력됨과 동시에 바로 출력하게 되고, 버퍼는 데이터를 일시적으로 저장하여 일정 크기만큼 모은 후 한 번에 처리하거나 전송하는 방식이다.스트림은 데이터를 실시간으로 바로 처리할 수 있어서 실시간 응용에 유리하며 또한 메모리 사용량을 최소화한다는 장점이 있다. 버퍼는 데이터를 일정량씩 모아서 처리하므로 ..

개발하고 있는 플랫폼 중에 필터값을 입력하고 검색 버튼을 누르면 백엔드에서 해당 필터에 맞게 데이터를 넘겨주고 이를 화면에 뿌리는 기능이 있다.흔한 기능이지만 백엔드에서 데이터의 가공시간이 상당히 오래걸리는 작업이었고 그만큼 화면에서는 한 번 검색 시 로딩 시간이 무척 길어서 사용성이 꽤나 저해되고 있었다. 그러던 와중 문득 헤더에 transfer-encoding: chunked가 있다는 것을 떠올렸고, 이를 보니 큰 데이터를 클라이언트에 쪼개서 보낼 수 있다는 것을 생각해냈다. 이를 직접 테스트해보기 위해 프론트는 vue로 백엔드는 express로 하여 이것저것 테스트해보았다. 이 과정에서 배운 것들을 기록해보겠다.  먼저 Transfer-encoding: chunked가 무엇이냐?Transfer-en..