230114 TIL

TIL을 작성하는 것을 습관화 해야겠다.

매번 들어오는 지식의 양은 많은데 이것들으 내것으로 만들지 못한채 하루가 지나고 시간들이 지나면 금새 이 많은 지식들이 휘발된다.

 

이것들을 처음부터 다 내것으로 만들며 지금까지 왔다면 어마어마한 성장을 했을 것이라고 확신할 수 있다.

매번 들어오는 지식들을 내것으로 만들지 못하고 당장 있을 프로젝트만 코드를 긁어오고 구글링해서 단순히 해결하고 당장의 상황만 벗어나려고 애쓰다보니 내것이 된 정보들은 많이 없다고 느껴진다.

 

이번 실전 프로젝트도 그렇다.

 

2주간 꽤나 많은 지식들을 나는 받아들였지만 정작 내것이 된 부분은 적다.

어떻게 해야 내것으로 만들수 있을까? 라는 생각에 나는 남들보다 시간을 더 써서라도 아침은 개인 스터디, 저녁은 했던 내용들을 정리하고 하루를 정리하는 TIL작성이 필요하다고 느꼈다.

 

습관화 하도록 하자.

 

우선 이번 실전 프로젝트에서 가장 크게 다가온 것은 멘토님의 피드백 이였다.

주니어 개발자로써 잘 알지도 못하면서 너무 많은것을 알려고 하는게 독이 된다고.. 많은 것을 아는것도 중요하지만 그보다 중요한것은 정확하게 아는것. 나는 정확하게 아는것이 부족했다. 현재 코드만 대충 짜집기 할줄 알지 어떻게 프로그램이 돌아가는지에 대해 설명을 하라고 하면 못할 것이다. 정말 구멍이 뻥뻥 뚫려있어서 막연하게 정보만 안다. 이것이 더 위험하다고 생각한다. 애매하게 알기에 설명은 못하고, 애매하게 안다고 생각하기에 처음부터 공부하는 것을 꺼릴 수도 있고, 애매하게 알기에 응용해서 써먹으려고 하면 삐그덕 거릴 수 밖에 없는게 당장 나의 상황이다.

 

그렇기에 계속해서 가장 기본부터 갈고 닦는 것이 중요하다.

기본을 모르면 응용도, 대처도 못할 것이고 더 많은 지식이 들어온다면 머리속은 더 꼬여서 무엇도 해결하지 못할 것이다.

기본부터 갈고 닦으며 천천히 올라가자.

 

퍼사드 패턴(Facade pattern)

패턴에 대해 구글링도 하고 내가 알아보려고 이것저것 문서들을 찾아보고 영상들을 보고... 사실 뭔말인지 하나도 이해가 안됐다. 그냥 아,,, 그렇구나 하고 끝이였고 머리속에는 뭔지 하나도 모르는 내용이였다.

 

이번테 멘토님에게 피드백을 받을때 Entity를 직접 사용하지 말고 Dto에 담아서 사용하는 것이 좋다고 하셨다.

신입 개발자, 아니면 개발자 중 누군가 등 예시를 들어주며 Entity를 직접 다룰 경우 휴먼에러 가능성이 있기 때문이라고 하셨다. 그 말씀을 듣고 우리도 Entity를 직접 다루는 것이 아닌 Dto를 사용해서 로직을 구현하기로 했다.

 

응 ? 하지만 말이 쉽지 로직으로 구현하다 보니 이해가 안되는 부분도 많았다. DB에 값을 조회, 저장할때는 DB와 접하는 Entity를 사용해야 하는데 이때도 Dto로 해야한는건지, 무조건 다 Dto로 해야하는거지 ? 막상 다루려다 보니 헷갈리는 부분이 많았다.

 

그리고 어느부분에서는 Entity를 직접 사용하고, 어느 부분에서는 Dto를 사용하고, 우리는 처음 말한 Entity를 직접 다루지 않기 위해 사용한건데 오히려 코드의 통일성이 떨어지고 더 복잡해지는 듯한 기분을 느꼈다.

 

Repository와 접하는 서비스 계층, Controller와 접하는 서비스 계층을 분리해서 사용하면 ?

뭔가 우리가 생각하는 정보가 조금씩 정리가 되는 아이디어라고 생각했고 이 질문을 다시 멘토님에게 드렸다.

멘토님은 이 부분이 퍼사드 패턴이라고 현업에서도 많이 사용되는 패턴이라고 하셨다.

 

퍼사드패턴에 대한 자세한 내용은 완벽하게 머리에 있진 않지만 어떤 느낌인지는 감이 잡히기 시작했다.

더 깊게 파는 시간도 가져봐야겠다.