20 01 회고 - ChoDragon9/posts GitHub Wiki

공개 가능한 ID(예를 들어 게시판 글의 ID이다)에 상태 저장 방법은 두 가지가 있다.

첫번째는 URL을 통해서 하는 것이고, 두번째는 브라우저 저장소에 하는 것이다.

둘 다 사용자가 조작 가능하고, 코딩 방법에서 차이가 있다. 하지만 URL은 현재 페이지의 정보를 URL를 통해 명확히 노출할 수 있다. 하지만 브라우저 저장소는 알 수 없다.

고민 끝에 URL로 상태 관리하는 것이 비용측면으로 효율적이다.

브라우저 저장소를 사용할 경우 발생하는 케이스는 다음과 같다.

• URL 변경 시 상태가 유지되어 의도하지 않은 데이터를 API로 호출한다.
  • API로 호출하여 에러 발생될 경우 부자연스러운 에러 처리가 발생된다.
• URI 측면에서 부자연스럽다. 같은 주소인데 다른 정보를 처리하게 되는 것이다.

객체지향은 객체의 책임을 할당하고 협력한다. 메시지를 통해 협력하며 상태 변경을 캡슐화한다. 자료구조를 만들어 사용하기 보다는 객체를 통해 행동을 수행한다.

함수형은 가변 상태를 최소화한다. 가변으로 발생하는 사이드 이팩트를 멀리하기 위해 불변성을 추구한다.

불변 객체를 만들면 되지 않을 까? 메소드를 실행하면서 새로운 객체를 반환하는 것이다.

메모리를 수정하지 않고 새로운 객체를 만드는 것은 불변성과 영속성을 이루게 된다.

하지만 협력 객체가 깊을 수록 깨지기 쉬우며 불변 객체를 만드는 것은 함수형 디자인 패턴이다.

객체지향의 사상인 객체에 역할과 책임 할당으로 분할하고 협력하면 상태전이가 발생한다. 하지만 함수형은 비파괴적인 상태전이로 구성되며 안전성을 강조한다.

결론적으로 공전하기 힘드며 하나의 패러다임을 사용하여 설계를 하는 것이 합리적이라 생각한다.

프런트 영역에서는 백엔드 응답은 외부 의존성이다. 100퍼센트 약속데로 응답이 올것을 보장할 수 없다는 의미이다. 실수를 하든, 커뮤니케이션 미스로 응답형식이 바뀌든, 사이드 이펙트가 발생하든 써드 파티 서버 때문에 예상치 못한 예외가 백엔드 서버에 발생하든 다양한 경우가 있다.

정상적인 동작을 보장하지 못하는 상황을 항상 염두해서 프런트 코드를 작성해야한다. 오류를 빨리 발견되야 하며 오동작을 해서는 안된다.