독서일지 - 비전공자를 위한 이해할 수 있는 IT 지식 후기 📖

드디어 이 책을 다 읽었다.
처음에 코드스테이츠 필독서로 추천받았던 책이었던 기억...이 있는데
그때는 이 책을 선택하진 않았다.
이제서야 읽기 시작해서는 4일 만에 틈틈이 읽고 클리어했다 (밀리의 서재 최고)
그때는 왜 그렇게 읽기 싫어했는지..ㅋㅋㅋ 이렇게 금방 읽을 걸

---

일부 정리

하이브리드 애플리케이션 (150p)

웹과 애플리케이션이 혼합된 애플리케이션
(네이티브와 브라우저 혼합)

• 네이티브 애플리케이션 : IOS 프로그램을 개발하기 위한 프로그래ㅔ밍 언어인 스위프트, Objective-C / 안드로이드 프로그램을 개발하기 위한 프로그래밍 언어인 자바, 코틀린. 이 언어들로 개발한 애플리케이션. 원래 정해놓은 언어들을 사용해 운영체제 자체의 기능을 하용하기 때문에 '네이티브'라는 말이 붙는다. 수정하는 데에 넘어야할 산이 많다. 특히 iOS 심사가 굉장히 빡셈. 그리고 심사가 끝나도 사용자들이 직접 업데이트를 해주어야 반영이 된다. 네트워크를 최소한으로 이용하도록 코딩한다면 인터넷이 느린환경에서도 빠르게 동작한다.
• 브라우저를 애플리케이션 특정부분에 올리는 방식: 운영체제 안에 브라우저가 내장되자 새로운 방식으로도 개발이 가능해졌다. 애플리케이션 특정 부분에 브라우저를 올리는 것. 그리고 HTML 파일을 불러올 URL을 설정해 두는 것이다. 수정하기 좋다는 장점이 있다. 서버의 HTML, CSS, Javascript만 수정하면 따로 심사를 받거나 설치할 필요 없이 새로고침할 때 반영이 되기 때문. 하지만 네트워크에 종속되기 때문에 와이파이나 모바일 네트워크가 느리게 되면 그 세 개를 다운로드 할 동안 사용자들은 기다려야 함.

어느 부분이 웹이고, 어느 부분이 네이티브 애플리케이션인지 구분

힌트! 스마트폰으로 모바일 브라우저에 접속해 포탈사이트 탭을 꾹 눌러서 천천히 떼어본다. 그럼 회색 박스가 나옴 -> 이 회색 박스는 HTML의 '링크'에 대해 브라우저가 보여주는 애니메이션(버튼 눌렸음!) -> 웹이라고 추측가능.
그리고 API문서를 살펴보는 방식이 가장 확실하다.

캡처하느라 조금 고생

관계형 데이터베이스(159p)

데이터관리의 주요 방법론 - 엑셀을 생각하면 쉽다

데이터의 고유 번호를 가짐. 데이터를 철저히 관리할 수 있고, 쉬운 예로 동명이인 이슈도 없어진다. 수정 시에도 한 부분만 수정하면 끝남

관계형 데이터베이스 관리 시스템(RDBMS)

MSSQL, Oracle DB, MySQL, MariaDB 등...
각 프로그램들은 다른 특징을 가지고 있지만 구분할 필요는 없고 이게 관계형 데이터베이스 관리시스템이라는 것을 알고 있으면 됨!

데이터가 서버에 있는가? 클라이언트에 있는가? (166p)

개발자의 상황, 개발 단계, 회사 사정에 따라 다 달라질 수 있다.
이때도 API 문서에 모든 답이 나와있음!
항상 무관심해서는 안되고 회사의 개발 결과물을 잘 파악하고 있어야 한다.
데이터가 서버에서 불러오는지, 클라이언트에 있는지 구분하는 것.
(때로는 에버노트처럼 두 곳 모두에 있는 경우도 있다. 에버노트는 오프라인에서 글을 쓸 수 있고 -> 이것을 온라인으로 연결하면 업데이트를 할 수 있음)
원활한 소통을 위해 꼭 확인해야 할 것.

Client : 로컬, 내부 DB, 네이티브, 클라/ 클라이언트, 프론트/ 프론트엔드
Server : 서버, API 요청, (그냥)DB, 백/ 백엔드

요청 용어 정리 (215p)

API 문서 이모저모 (220p~)

텍스트와 이미지 출처 구분하기

예시를 위해서 우리 프로젝트에서 썼던 API 문서를 가져와봄..

불러오는 기능인 GET. 게시물 정보를 불러온다.
파라미터는 함수의 인자(덧셈 함수에서 1+3=4 라고 하면, 1과 3이 파라미터이고 4가 결과값이다). 즉 게시물 정보를 불러오기 위해서는 questionId가 필요한 것.

Response 아래 JSON을 보고 출처를 파악하는 것이다.
만일 이곳에 content, image가 있다면, 이 부분의 정보는 서버에서 불러 오고 있다는 것을 알 수 있ㄴ는 것.
이 부분을 수정하고 싶다면, 클라이언트가 아니라 서버 개발자가 해야하며, 데이터만 고치면 업데이트 없이 결과가 반영될 것이다.
모든 텍스트와 이미지를 하나하나 뜯어서 봐야한다. "장소, 일시, 필요포지션, 버튼 안에 있는 수정, 삭제 텍스트, 상단바 이미지들"까지 모두!

만약에 디테일 페이지에 대한 API 문서 설명에 '구체적 정보는 우선 웹으로 처리합니다' 라고 적혀 있고 , 아래 get detail에 '완성된 디테일 웹 페이지의 주소를 보내줍니다' 라고 적혀 있고, Response를 누르면 상세페이지 주소를 가져온다고 되어있다면,
상세페이지는 완성된 HTML CSS Javascript결과물을 가져와서 보여준다는 것을 알 수 있다.
웹개발자가 HTML, CSS, Javascript 를 완성해서 해당 페이지를 불러올 수 있는 주소를 알려주면, 그 주소를 서버 개발자가 API로 제공해준다. 그러면 그 주소를 애플리케이션 개발자가 받아서 브라우저 위에 띄워주면 된다.
나머지는 브라우저가 알아서 HTML, CSS, Javascript를 불러올 것.

한 번 구분해놨다고 해서 계속 쓸지 아닐지는 모르니 항상 문서를 업데이트 할 것

API 문서를 분석하는 목적은 " 완벽한 분석 " 이 아닌 " 원활한 커뮤니케이션"

---

4장, API와 JSON, 그리고 7장 데이터베이스 파트는 프론트엔드 입장에서 보기에 설명이 아주 쉽게 나와있다. 그래서인지 아주 술술 읽히는 기분.ㅎㅎ
프로젝트 때 경험했던 내용들을 알려주는 부분이라 더 재미있었다.
이제 오늘도 개발자가 안된다고 말했다 를 읽을 건데, 이 책은 예전에도 읽고 싶었던 책이라서 조금 기대 중! 벌써 14% 읽었다. (벌써??) 다시 한번 말하지만.. 밀리의 서재 최고.... ㅎㅎ