📕Facts(한 것)

📕Findings(배운 것)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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