✅ 한 것들
- 클린 아키텍처
- 경력기술서 수정 및 지원서 제출
- Project GNC
📖 클린 아키텍처
14장 컴포넌트 결합
ADP: 의존성 비순환 원칙
컴포넌트 의존성 그래프에 순환이 있어서는 안된다.
(컴포넌트는 유니티로 치면 asmdef로 어셈블리 나누는 거)
의존하던 무언가가 고장나면 그거 고치느라 개발이 지연되는 숙취 증후군이 발생할 수 있다.
프로젝트 규모가 커지면 숙취 증후군 때문에 stable 빌드를 몇 주씩이나 못 뽑게 된다.
해결책은 '주 단위 빌드'와 '의존성 비순환 원칙'이다.
주 단위 빌드
- 중간 규모 프로젝트에서 흔하게 사용된다
- 일주일의 첫 4일 동안은 서로를 신경쓰지 않는다
- 금요일이 되면 변경된 코드를 모두 통합하여 시스템을 빌드한다
- 프로젝트가 커지면 금요일 하루 만에 통합을 끝마치지 못하게 된다
점진적 빌드
- 개발 환경을 릴리스 가능한 컴포넌트 단위로 분리한다
- 개발자는 해당 컴포넌트가 동작하도록 만든 후에 배포한다
- 다른 팀은 새 릴리스를 적용할지 말지 결정한다
- 통합은 작고 점진적으로 이루어진다
의존성 구조에 순환이 생기면 숙취 증후군을 피해갈 수 없다.
서로서로 의존해버리면 그것들이 하나의 거대한 컴포넌트가 돼버리기 때문이다.
모두 항상 정확하게 동일한 릴리스를 사용해야 하고,
A를 고치면 B와 C도 반드시 빌드하고 통합해야 한다.
컴포넌트 사이의 순환 끊기
- 의존성 역전을 적용한다
- A와 B가 모두 의존하는 클래스를 새로운 컴포넌트로 이동시킨다
컴포넌트 구조는 시스템에서 가장 먼저 탑다운으로 설계할 수 있는 방식이 아니다.
시스템이 성장하고 변경될 때 함께 진화하는 것이다.
컴포넌트 의존성은 애플리케이션의 기능을 기술하는 일과는 거의 관련이 없기 때문이다.
컴포넌트 의존성 다이어그램은 프로그램의 빌드 가능성과 유지보수성을 보여주는 지도이다.
SDP: 안정된 의존성 원칙
안정성의 방향으로(더 안정된 쪽에) 의존하라.
모듈을 만들 때 변경하기 쉽게 설계했어도,
의존성을 매달아 버리면 변경하기 어려워진다.
반대로 말해, 해당 모듈에 의존하는게 없으면 변경하기 쉽고 안정적이라는 뜻.
불안정한 컴포넌트도 있고 안정된 컴포넌트도 존재하는게 정상이다.
안정한 쪽이 불안정한 쪽에 의존하게 된다면 의존성 역전을 적용하라.
SAP: 안정된 추상화 원칙
컴포넌트는 안정된 정도만큼만 추상화되어야 한다.
안정됐는데(의존하는 모듈들이 많은데) 구체적이라면 관리도 어렵고 변경 시 고통스럽다.
데이터베이스 스키마 같이 변동성이 높으면 곤란하지만,
유틸리티 라이브러리 같이 변동성이 낮으면 해롭지 않다.
반대로 아무도 의존하고 있지 않은데 추상화돼있으면 의미가 없다.
🎮 Project GNC
아이템과 인벤토리 구현
- 흐름 : 땅바닥에 있는걸 주워 > 툴바에서 빈 공간을 찾아 > 없으면 인벤에서 빈 공간을 찾아 > 빈 공간이 없으면 못 먹어 > 빈 공간을 찾았으면 그 박스에 데이터를 넣고 UI도 업뎃해 > 나중에 박스들을 어떻게 저장할지만 생각하면 됨
- Inventory는 InvenBox만 안다. InvenBox 안에 type과 count가 있다.
- 어제 짜놨던 구조와는 살짝 달라짐
- 넣기까지 구현 완료
