티스토리

dev.jaieve 공부기록

검색하기

블로그 홈

dev.jaieve 공부기록

rimooworld.tistory.com/m

제이브 님의 블로그입니다.

구독자: 1

방명록 방문하기

주요 글 목록

[SSR vs CSR] SSR과 CSR 비교 및 사용시기 CSR에서는 HTML문서에서 모든 내용을 수신하지 않고 클라이언트 측 JavaScript 라이브러리를 사용하여 브라우저에서 콘텐츠를 렌더링하낟. 새 페이지가 로드될 때 브라우저는 서버에 새 요청을 하지 않고, 페이지가 브라우저에 로드될 때까지 콘텐츠가 렌더링되지 않기 때문에 검색엔진 순위에 부정적인 영향을 미칠 수 있다. 하지만 CSR Application에서는 Web Side Rendering이 더 빠른 경향이 있다고 한다. 개발자는 SSR과 CSR을 고려할 때 프로젝트의 규모, Application의 복잡성, 사용자수, 사용자 경험 우선순위 등의 요소를 평가하게 된다고 한다. 개인적으로 가장 표면적인 이유가 바로 사용자 경험 우선순위라고 생각했다. 사용자입장에서 화면 전체가 깜빡이는 것을 보게되고 U.. 공감수 0 댓글수 1 2022. 5. 4.
[SSR vs CSR] CSR(Client Side Rendering) 앞서 작성한 SSR과 비교되는 기법인 Client Side Rendering. 핸들바를 사용하면서 어렴풋이 구분하기 시작했다가, React를 공부하면서 그 차이에 대해 실감하면서 앞으로 내가 새로운 서비스를 기획 및 설계 단계에서 부터 만들 때, CSR를 효율적으로 사용할 수 있게 되길 바라는 마음으로 CSR에 대해서 정리해본다. 그렇다면 CSR이란 무엇일까? CSR이란? CSR은 브라우저에 내장된 JavaScript엔진을 사용하여 브라우저에서 콘텐츠를 렌더링하는 기법으로 Single Page Application(SPA)에서 사용한다. HTML문서 자체에서 모든 내용을 가져오지 않고, 첫 로딩에는 JavaScript 파일을 가진 원본 HTML문서가 전송된다. 이후 브라우저에서 사이트의 나머지 부분을 렌.. 공감수 0 댓글수 0 2022. 5. 4.
[SSR vs CSR] SSR(Server Side Rendering) 회사에서 타임리프를 쓰고 있지만, 레거시 소스코드에는 핸들바라는 CSR도 함께 사용되고 있다. 처음 Ajax에 대해 배우면서 CSR에 대해 알게 되면서, 화면의 깜빡임 없이 새로운 정보를 클라이언트에게 제공할 수 있다는게 무조건적으로 장점이라고 생각했던 시절이 있었다. Thymeleaf와 Handlebar를 함께 써보고, React 공부를 하면서 배우고 느낀 SSR과 CSR에 대해 정리해보고자 한다. 먼저 SSR! SSR이란? SSR은 서버의 HTML파일을 클라이언트를 위해 요청받은 정보에 대한 응답으로 완전히 렌더링된. 즉, 클라이언트에게 보여줄 data가 그려진 형태의 페이지를 전송해준다. 서버쪽에서는 클라이언트에게 콘텐츠를 전송하기 전에 전달할 data를 indexing 하는 것 과 같이 미리 가공.. 공감수 0 댓글수 0 2022. 5. 4.
[노개북] 클린코드 TIL(2022.03.04) - 수정중 DAY 10 🚀 오늘 읽은 범위 : 8 🔥 책에서 기억하고 싶은 내용 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보자! 🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면? 공감수 0 댓글수 0 2022. 3. 4.
[노개북] 클린코드 TIL(2022.03.01) DAY 8 🚀 오늘 읽은 범위 : 6장 객체와 자료구조 🔥 책에서 기억하고 싶은 내용 1. 자료추상화 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다.(p. 119) 2. 자료/객체 비대칭 객체는 추상화 뒤로 자료를 숨긴채 자료를 다루는 함수만 공개한다. 자료구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.(p. 119) 3. 디미터 법칙 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. ... 즉, 객체는 조회 함수(getter)로 내부구조를 공개하면 안된다.(p.123) 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보자! 1. 자료 추상화 추상인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 .. 공감수 0 댓글수 0 2022. 3. 1.
[노개북] 클린코드 TIL(2022.02.28) DAY 7 🚀 오늘 읽은 범위 : 5장 형식 맞추기 🔥 책에서 기억하고 싶은 내용 적당한 행 길이를 유지 소스 파일 첫부분은 고차원 개념과 알고리즘을 설명하낟. 아래로 내려갈수록 의도를 세세하게 묘사한. 마지막에는 가장 저차원 함수와 세부 내역이 나온다. 빈 행은 새로운 개념을 시작한다는 시각적 단서이다. 코드를 읽어내려가다 보면 빈 행 바로 다음 줄에 눈길이 멈춘다. 인스턴스 변수는 클래스이 맨 처음에 선언한다.(p.103) ... 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다. 또 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다. 그러면 프로그램이 자연스럽게 읽힌다. ... 그만큼 모듈 전체의 가독성도 높아진다.(p.104) 신문 기사와 마찬가지로 가장 중요한 개념을 .. 공감수 0 댓글수 0 2022. 2. 28.
[노개북] 클린코드 TIL(2022.02.22-23) DAY 5 🚀 오늘 읽은 범위 : 3장 함수 🔥 책에서 기억하고 싶은 내용 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.(p. 44) 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.[G34] 함수 당 추상화 수준은 하나로! 함수가 확실히 ‘한 가지’ 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다.(p. 45) 근본 개념과 세부사항을 뒤섞기 시작하면, 깨어진 창문처럼 사람들이 함수에 세부사항을 점점 더 추가한다.(p. 46) 서술적인 이름을 사용하라! 함수가 하는 일을 좀 더 잘 표현하므로 훨씬 좋은 이름이다. ... 함수가 작고 단순할수록 서술적인 이름을 고르기도 쉬워진다.(p.49) 객체를 생성해 인수를.. 공감수 0 댓글수 0 2022. 2. 23.
[노개북] 클린코드 TIL(2022.02.21) DAY 4 🚀 오늘 읽은 범위 : 다른 사람들의 TIL 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보자! leeq님 링크 1장을 읽고 작성한 TIL을 읽으면서 leeq님만이 느끼신 공감대에 대해서 알 수 있었다. 역시 공학계열이라면 무엇인가 일맥상통하는 부분이 있을 수 밖에 없다는 생각을 장난삼아 해봤다. leeq님의 개인적인 견해를 읽고 큰 공감을 했다. 작년 8월 회사에 첫 입사를 하고 클린코드에 대해 고민하면서, 이 책을 어떤 사람에게 추천하고 싶은지 고민해봤었는데 그 사람은 바로 sysout을 마구잡이로 뽑아내던 동기였다. 그리고 기본적인 Naming convension과 indent조차 지키지 않는 초보 개발자들에게는 이 책의 개념이 아무리 어려워도 프그래머로 돈을 벌어먹겠다는 생각을 해.. 공감수 0 댓글수 0 2022. 2. 22.
[노개북] 클린코드 TIL(2022.02.20) DAY 3 🚀 오늘 읽은 범위 : 2장 의미있는 이름 🔥 책에서 기억하고 싶은 내용 클래스 이름과 객체 이름은 명사나 명사구가 적합하다. ... 메서드 이름은 동사나 동사구가 적합하다(p. 32) 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야한다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.(p. 35) 일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.(p. 37) 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보자! 검색하기 쉬운 이름을 사용하라 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.(p. 26) 실제로 회사에서 특정 클래스.. 공감수 0 댓글수 0 2022. 2. 21.
[노개북] 클린코드 TIL(2022.02.19) DAY 2 🚀 오늘 읽은 범위 : 추천사 ~ 1장 깨끗한 코드 🔥 책에서 기억하고 싶은 내용 기능을 추가할수록 코드는 엉망이 되어갔고, 결국은 감당이 불가능한 수준에 이르렀다. 회사가 망한 원인은 바로 나쁜 코드 탓이었다. 프로그래머라면 누구나 당연히 나쁜 코드로 고생한 경험이 있다. 그렇다면 묻겠다. 어째서 나쁜 코드를 짰는가? 급해서? 서두르느라? 아마 그랬으리라. 제대로 짤 시간이 없다고 생각해서, 코드를 다듬느라 시간을 보냈다가 상사한테 욕먹을까 봐, 지겨워서 빨리 끝내려고, 다른 업무가 너무 밀려 후딱 해치우고 밀린 업무로 넘어가려고...... 모두가 겪어본 상황이다. 우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. (p.4) ... 다시 돌아와 나중에 정리.. 공감수 0 댓글수 0 2022. 2. 19.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.