1 클래스로 만들 것과 모듈로 만들 것의 구분
-> 클래스 : 여러 개을 인스턴스를 만들때 -> 자바의 클래스라고 생각하면 됨
-> 모듈 : 하나만 존재해도 되는 경우 일반적으로 해당 페이지에서만 한번 사용해도 될 경우 -> 자바의 static 메서드로 구성된 클래스
컴포넌트(클래스)는 여러번 다시 쓸 것 같은 것을 만들면 되고,
모듈은 대체로 한번만 사용되는 것으로 만들면 된다.
기능은 웬만하면 모두 분리해서 사용하는 것이 좋다.
ajax 부분은 따로 뺀 js파일로 작성해서 caching을 하면 더욱 효율적인 코드로 작성할 수 있다.
2 화면을 쪼개 단위별로 모듈 만들기
-> 화면을 쪼개는 단위 : 응집도 생길 만한 크기. 대부분은 기준 엘리먼트로 하위 엘리먼트를 찾는데 이때 기준 엘리먼트가 모듈의 단위가 일반적임.
3 뷰 와 모델 나누고 상호작용하도록 만들기
-> UI을 제어하는 뷰 영역과 데이터를 제어하는 모델 영역을 구분 -> 신규
실행하는 부분은 따로 js파일로 만들어서 모듈화한다. 기능과 실행을 함께 섞어 놓지 않는 것이 좋다.
4 뷰 내에서 적절한 엘리먼트 탐색과 이벤트 바인딩
-> 엘리먼트 탐색 : 기준 엘리먼트 기준으로
-> 이벤트 바인딩 : 기준 엘리먼트를 기준으로 event delegation 만듬.
5 상호의존 피하기
-> 상호 의존적인 코드는 제거하기
상호 의존적인 코드(순환 참조)는 버그의 원인이 되는 경우가 많다.
.amd.js파일은 define되어 있어서 requirejs에서 사용할 수 있게 되어있다.
r.js는 requirejs가 만든 것을 하나로 빌드 시켜주는 역할
BE 코드 리뷰
A 메소드
B 메소드
log -> Advice클래스를 만들고, weaving(객체가 실행될 때, 어드바이스의 메소드가 실행되는 것을 의미)
EJB는 분산처리용, 컨테이너가 대신 만들어준다.
가장 중요한 것은 비지니스 로직이기 때문에 불필요한 로그를 일일이 찍어줄 필요가 없다.
프로그래머는 비지니스 로직에 더욱 집중할 수 있게 됨.
DAO와 Service에서 인터페이스를 사용하면 확장성이 높아져서 좋아지게 된다.
FE 코드 리뷰
requirejs는 실무에서 거의 사용하지 않음
AWS로 버지니아에 있는 서버의 ping이 150ms이라고 치자
50mbps라면 5mb정도도, 150ms면 초당 600kb를 받을 수 있다.
요청이 가고, 요청이 오는 시간은 비슷하다.
그렇기 때문에 요청이 최소화되어야 한다.
네트워크는 재요청 시간에 비용이 매우 크다.
requirejs는 모듈이 굉장히 크고 대부분의 경우 거의 쓰지 않을 때 사용하는데, 그래도 너무 요청이 많다.
EJB 로컬 객체, 원격 객체를 같이 쓰고 싶었는데, 굉장히 불편함.
할 수 있는 한 동기적으로 할 수 있도록 코딩하는 것이 좋음
webpack 도전~?
webpack을 사용하면 require처럼 commonjs를 다 묶어줌
프로토타입 상속으로 하면 됨
MVC -> 에어비엔비에서 별점을 매기는 기능에 욕설을 제거하는 로직을 넣고 싶다. 그러면 MVC중 어디에 넣어야 할까?
DB
Model DAO
Reputation Service(Domain Model) - 여기에서 욕설을 걸러야 한다.
Controller(뷰의 내용을 모델에 전달하고, 모델의 내용을 뷰에 전달하는 것 외에는 컨트롤러의 역할이 아니다. 컨트롤러에서 우리가 욕설을 필터링한다면, View가 달라질 경우, 컨트롤러가 달라지게 되는데, 그렇게 되면 서비스가 이를 제어해야한다.)
View
MVVM(첫번째 M이 Model이라는 것에 대한 이견은 없다. 그런데 V V M 에서는 이견이 나뉜다.
JSTL/EL/XAML 이것들은 기본적으로는 view다. 모델의 데이터를 view 영역에서 이것들이 어떻게 보여줄 것인지는 다른 문제이다.
이것들은 여러가지 뷰로 보여줄 수 있다. 하나의 뷰는 여러개의 모델을 참조할 수 있고, 하나의 모델 또한 여러개의 뷰에 갈 수 있다.
여기에서 모델을 어떻게 뷰에 뿌릴지를 결정하는 것, 뷰의 범위는 스크립틀릿, JS를 포함하면서 유동적으로 변화할 수 있고, 뷰는 여러가지 이름으로 불린다.
원래 MVC는 데스크탑 어프리케이션의 아키텍처다. 워드, 인텔리제이와 같은 것들 말이다. HTTP를 중간에 어떻게 끼워 넣느냐에 관한 문제가 WebMVC이다.
MVC, MVP는 별로 중요하지 않은 문제이다. 80년대에 나온 문제로 당시에는 브라우저가 없었고, DOM구조도 아니기 때문에, element로 되어있지도 않았다. 아주 간단한 행위 조차도 굉장히 많은 분량의 코딩이 필요했다.
하나의 기능이 어디에 뭉쳐있는게 더 자연스러운지에 대한 측면에서만 고려하면 된다.
Interactive Application Architecture Pattern 이라는 글을 보면 MVC에 관한 아주 상세한 설명이 나와있다.
<-Component->
Active Passive
컨텐츠 중심이면 Active한게 낫다.(기능 단위, 하나의 컴포넌트에서 api를 이용해서 db에 갔다 오는 것)
하나의 요청이 여러 컴포넌트에 영향을 미쳐야하는 경우를 보자.
지도를 검색할 경우, 출구를 찾아주는 부분, 지도 부분 등이 바뀐다고 하면,
하나의 요청에 따른 결과가 다른 컴포넌트들을 바꿔야 한다.
여기서 ajax는 따로 존재하며, 그로 인한 결과를 다른 컴포넌트에 영향을 주게 된다.
이런 컴포넌트를 Passive한 컴포넌트라고 한다.(응집성이 높은 어플리케이션에서 사용된다, 컴포넌트끼리는 참조하지 않고, 루트만들 참조해야한다)
서비스를 만들때는 내가 만들고 싶은 서비스의 Hirarchy가 어떤 형태를 띄는 게 더 효율적인지를 고려해서
만들어야 한다.
CSS를 잘 아는 것이 굉장히 중요하다. 직접 공부해야함.
translateX는 GPU가속으로 레이어를 올리는데, 오히려 더 느려질 수 있음
CSS를 그릴 때, 나를 변경하면 다른 애들을 변경시켜야하는 경우가 있다.
position : absolute를 주면 이를 줄일 수 있음.(reflow가 일어나지 않는다)
GPU에 올리고, 나머지를 계산해야되면 무의미하다.
모바일은 CSS를 잘아는 것이 중요하다. 제일 쉬운 책,
서비스의 성격, 메인페이지, 서브페이지, 3~4페이지 이상을 보면
공통적으로 쓰는 것들을 나눠서 웹팩으로 묶어 놓으면 이득을 볼 수 있다.
하나만 보고 간다면 별로 나눠 놓으면 이득이 없다.
구글 소스에는 자바스크립트가 한뭉텅이 들어있는데 스크립트를 가장 빨리 전달할 수 있다는 장점이 있다.
캐시라는 것은 항상 좋은 것은 아님.
캐시는 실시간을 포기하고 다른 비용을 세이브하는 개념이다.
새로 서비스를 배포해야되면 문제가 된다. 그래서 배포시점마다 타임스탬프를 넣어서 배포하는 게 일반적이다.
instanceof관계는 instanceof를 판단하는 다른 메소드가 있어서 그것으로 판단한다.
es6의 클래스 문법을 es5로 다시 바꿀 수 있고, 그것을 transfy한 코드를 다시 보면 많은 도움이 될 것.