(TIL) 20210902

📕Facts(한 것)

---

• 노마드 코더 챌린지 참여하기 -> html, css를 활용한 실습
• 운영체제 수업듣기 -> 운영체제 개괄적 내용
• 클린 아키텍쳐 읽기 -> ADP에 관한 내용
• 프로그래머스 문제풀기 ->문자 압축하기

 

📕Findings(배운것)

---

클린 아키텍쳐에서 ADP, 의존성 비순환 원칙에 대한 내용을 읽었다.

"컴포넌트 의존성 그래프에 순환이 있어서는 안 된다."

 

'그래프에 순환이 있어서는 안 된다' 라는 내용을 어디선가 본 것 같았다.

아, MST, 최소 신장 트리에는 순환이 있어서는 안 된다고 했다. (크루스칼, 프림 알고리즘)

 

책에서는 의존하는 무언가를 끊임없이 수정하는 이른바 '의존성 무한루프'(본인 피셜)를 '숙취 증후군(the morning after syndrome)'이라고 부른다. 그리고 지난 수십년 동안 이 '숙취 증후군'의 해결책은 두 가지 방법으로 발전되었다고 말한다.

'주 단위 빌드(Weekly build)' , '의존성 비순환 원칙'

 

'주 단위 빌드'는 개발 일주일의 첫 4일 동안은 서로를 신경쓰지 않고 개발을 진행한다. 그리고 마지막 5일에 각각의 개발된 코드를 통합하여 빌드한다. 장점은 4일 동안 상대방을 신경 쓸 필요가 없다는 것이다. 그렇다면 단점은? 야근 혹은 토요일 근무가 필수가 되는 것이다.

별로 좋은 방법이 아닌 것 같다.

 

'의존성 비순환 원칙'은 개발 환경을 릴리즈 가능한 컴포넌트 단위로 분리하여 개발하는 것이다. 개발자가 해당 컴포넌트를 릴리즈하면 다른 개발자가 사용할 수 있게된다. 그리고 이 릴리즈 컴포넌트에 번호를 부여하고, 개발팀은 해당 컴포넌트를 지속적으로 수정하여 번호를 업데이트 시킨다. 이렇게 되면 다른 팀에서는 새로 개발된 버전의 릴리즈를 사용할지를 결정할 수 있고, 그렇게 되면 다른 팀에서 준비가 되었을때 새 릴리즈를 적용할 수 있는 선택 권한이 생긴다.

 

장점은 아주 명확하다. 어떤 팀도 다른 팀에 의해 좌우되지 않는다는 것. 단점은 없을 것만 같아 보인다. 

하지만 이 컴포넌트들 중 의존성에 '순환'이 생기는 순간 문제가 발생한다.

a -> b -> c ->a 의 의존 관계라고 생각해보면, a를 개발하고 릴리즈 하면, a에 의존관계가 있는 b는 개발을 시작한다. b에 의존관계가 있는 c역시 마찬가지이다. 하지만 a가 c에 의존관계가 있는 순간, a는 b와 호환되면서 동시에 c와 호환되어야 하는 상황이생긴다. 그렇게 되면, a, b, c, d는 거대한 하나의 컴포넌트가 되어버리고, 이 중 어느 것을 개발하더라도 '숙취 증후군'이 발생한다.

 

그렇기 때문에 각 컴포넌트들에 의존성 비순환 원칙이 중요한 것이다.

의존성 역전 원칙과 비슷한 맥락으로 이해하면 도움이 될 것 같다.

 

 

 

📕Feeling(느낀 점)

---

최소 격일 단위로 책을 읽고 정리하는 습관을 들이고 있다.

오늘 TIL에서 정리했으니, 모레 TIL에서 확인 가능할 것이다.

 

듣고 싶은 수업은 많은데, 학점은 제한되어 있고, 시간도 제한되어 있으며, 내 몸 자원도 한정적이라 더 배우지 못하는게 너무 아쉽다.

아쉬운 대로 빅데이터 수업을 추가로 수강신청했다.

 

📕여담

---