안정적인 프로덕트를 위한 코드 구조와 관리

모든 요소들은 생명주기를 가지고 있다. 

 

생명주기는 왜 있어야할까? 

코드로 만들어진 가상세계에도 생명주기가 있어야 할까?

> 모든 자원들이 유한하기 때문에 생명주기가 있다. 

예를들면 컴퓨터 시스템 내의 파워,시스템 등등이 유한하다. 지금은 빠르지만 미래에는 느리게 느껴지는 속도

지금은 많은 용량같지만 나중에 가면 작은 용량이 되기도 한다.

생명주기를 가진 요소들이 변화에 잘 어우러져서 하나의 서비스를 만드는데 효과적인 전략을 취할 수 있다. 

이게 라이프사이클을 충분히 이해해서 잘 구성된 것을 잘 구조화된 아키텍쳐라고 할 수 있다. 

 

프론트앤드를 구성하는 요소들

모듈, 함수, 컴포넌트 등의 생명주기는 얼마나 될까?

강의에서는 1년정도라고 생각한다고 한다. 

대부분의 코드가 굉장히 오래 쓴다고 하더라도 프론트앤드에서는 1년 이상가지 않는다고 생각한다고 한다.

 

(우리 서비스에 묵히고 묵었던 에디터를 4년만에 걷어내고 새로운 에디터로 교체하는데 참 오래되고,,

진작에 바꿨어야 한다고 생각한다. 새로운 기능들이 들어오고 더 다채로운 에디터가 되었다. 기존 레거시 코드를 보며 4년간 이 서비스를 버티게 해준 고마운 코드라고 생각이 들었다.)

 

짧은 주기로 변하는 어플리케이션을 부분적으로 잘 갈아끼우려면, 어떤 전략을 가지고 있어야 하는지에 대해 생각해 본다면 답은  각각의 생명주기가 다른 요소들끼리 요소를 쪼개고 독립적으로 운영될 수 있도록 만드는 것이다.

 

그렇다면 우리는 어느 기준으로 컴포넌트를 나눠야 할까?아래 4가지 유형으로 분류해보겠다. 

-  유형별로 분류

html, css,

code- bussiness logic, rule(외부에서 받는 config 등등),

data, state,

effect(animation, network 등 비동기로 이루어지는 작업들, event... )

 

 이런것들이 뒤얽히면 문제가 발생한다. html과 css가 섞여있는 상황이나 코드랑 data가 바뀌는 부분들이라면 나중에 반드시 문제가 발생한다. 이런것들은 개개별로 꼭 분리를 해놓아야 한다. 

 

- 변형 주기별 분류

Design, Visual,

Struct (단일 디자인에 여러화면들이 어떻게 인터렉션되어 화면이 전환되는지),

Config (어딘가에 접근하기 위한 정보들 - 앱의 코드와 상관없이 변경될 수 있음),

Assets (이미지 등의 정적파일들),

Information (약관, 대표자정보)

 

약관이나 대표자 정보등의 정보들은 자주 바뀌는 내용이 아니라 html요소에 하드코딩 되어있는 경우도 많이 있다.

하지만 약관이 자주 바뀌는 경우도 종종 있다. 이러한 서비스일 때 변경될 때마다 코드를 수정해서 배포를 한다면 비효율적으로 리소스가 낭비가 된다. 이런 것들이 분리되어 관리된다면 운영 리소스를 줄일 수 있다.

 

- 오너십

Library 

Framework

Service

 

오너십 관련은 우리회사가 변경과 관련되서 법적이나, 기술적 권리를 가지지 않는 것들이다. 

라이브러리나 프레임워크에서 업데이트를 하면 서비스에는 늦게 적용이되거나, 카카오 인증 등 외부서비스를 사용했을 때, 오류상황에 대비해 놓는다면 우리 회사에서 만든 코드가 아님에도 발빠른 대처를 할 수 있다. 

 

- 위치

Internal (내부서비스)

External (외부서비스)