(TIL) 20222021, 만들면서 배우는 클린 아키텍처

📕Facts(한 것)

---

• 스타트업 면접
• DB 트랜젝션과 락에 대해서 더 공부
• 비슷한 프로젝트를 진행하는 분과 컨텍
• 정규화와 비정규화에 대한 고찰
• 만들면서 배우는 클린아키텍처 독서(단일 책임 원칙)

 

📕Findings(배운 것)

---

어제에 이어 오늘도 면접을 진행했다!

 

첫 오프라인 직장 면접이어서 많이 설레면서 떨렸다.

 

편한 분위기에서 나의 프로젝트와 내가 해온 것들에 대해서 설명했고,

내가 평소에 추구하는 개발 방향, 협업 방식, 테스트코드에 대한 생각 등을 이야기 했다.

(내 스스로 나의 부족한 점을 잘 숨기지 않았을까 싶다)

 

트렌젝션과 락에 대한 질문이 들어왔는데, 사실 락에 대한 개념이 잘 탑재가 되어 있지 않아서

길게 설명을 못했다. 그래서 오늘 공부했다.

 

아래의 글을 보고 트렌젝션과 락에 대해 알아보자.

---

그리고 정규화와 비정규화에 대해서 좀 더 공부의 필요성을 느겼다.

정규화의 장점, 비정규화의 장점 등에 대해서 좀 더 공부하고 많은 생각이 필요할 것 같다.

 

이것 역시 아래 글에서 알아보자.

 

---

단일 책임 원칙에 대해서 상당히 많은 관심을 가지고 있는 나는, 이를 어떻게 하면 잘 처리할 수 있을가에 대해서 많은 고민을 해봤다.

사실 단일 책임 원칙이라하면 아키텍처 SOLID 원칙 중의 하나로 알고 있는 것이 대부분일텐데,

나는 이 5가지 원칙중에서 가장 중요한 것이 아닐까 생각한다.(물론 다른 것도 다 매우 중요하다.)

 

단일 책임 원칙이란 말 그대로 한 가지 책임을 가지는 원칙이다.

 

이렇게만 얘기하면 감이 잘 오지 않는다. 다 한가지 책임을 지는 거 아닌가? 라고 생각하기도 쉽다.

 

하지만 정확하게 풀자면 단일 책임 원칙 보다는 '단일 변경 이유 원칙' 이 좀 더 본래의 의미에 가깝다고 할 수 있다.

 

그도 그럴 것이 실제 정의는 '컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.' 이다.

 

그럼 느낌이 팍 온다. 아, 오직 한 가지 이유로만 변경이 일어난다면 문제가 발생했을 때 '범인은 쟤구나!' 라고 바로 알 수 있지 않겠는가?

 

그렇기 때문에 다른 컴포넌트에 대해서는 전혀 신경을 쓸 필요가 없어진다!

 

하지만 이 한가지 원칙으로는 완벽해지지 못한다.

 

이것은 의존성 역전 원칙이 보장되어야 가능하기 때문이다. 

 

의존성 역전 원칙에 대해서는 다음 글에서 살펴보자.

 

 

📕Feeling(느낀 점)

---

요즘 나를 원하는(?) 회사들이 꽤 있어서 감사하다. 정말로.

 

조금 더 열심히 해서 세상에 보탬이 되는 그런 개발자가 되고 싶다.

 

📕여담

---