👨💻 패러다임
이번 주는 좀 더 철학적인 면에서 고민해 볼 수 있는 주간이었다. 객체지향과 함수형 프로그래밍에 대해서 배워 볼 수 있었는데, 각 패러다임이 지닌 특징(객체지향은 다형성,상속성, 함수형은 순수함수 등)에 대해 공부해보고 이것들을 적용해 보게 되었다. 6명의 동료들과의 코드 리뷰를 통해 느낀 점은 결국 이러한 패러다임은 개발자들이 코드를 받아들이는 데 있어서 직관적이기 위함이고, 결국 협업을 위해 원칙을 정한 것이라고 느꼈다. 물론 우리 6명은 각자 생각했던 방식이 달랐고 그 부분에 토의해보면서 좀 더 정확한 원칙을 배울 필요성이 느껴졌다. "클린 코드", "클린 아키텍처", "리팩토링2" 최근에 관심이 생긴 책인데 얼른 봐야겠다.
👨💻 백엔드와 프론트의 경계는 어디인가
이번 주 프로젝트에서는 백엔드를 맡게 되었는데, 데이터 모델을 짜고 프론트 분들에게 "이런 api 서버를 만들테니 이렇게 데이터를 보내 주세요"라는 방식으로 진행을 하였다. 그리고 대부분의 비지니스 로직들이 서버에서 처리가 되고 프론트에서는 그 데이터를 표시하는 뷰 작업이 대부분이 되었는데... 문득 프론트 분이 "아 저는 정보만 받아오게 만들면 되는건가요?"라고 얘기하셔서, 엇 충격을 받았다.
나는 사실 프론트엔드 지망생인데, 결국 서버에 이렇게 해달라 요청하고 결과값만 받아와서 표기만 하는 건가? 하는 생각이 들었다. 사실 서버에서 할 일을 프론트에서도 할 수 있다고는 생각하는데, 요즘 토이프로젝트로 하는 주식데이터를 서버에서 그냥 db에 쿼리 날려서 find한 결과값을 요청할 수도 있고, 그냥 전체 주식 데이터를 담아와서 프론트에서 필터해 버릴 수도 있는 거 아닌가...? 좀 더 복잡한 서비스 (예를 들면 툴이나 에디터)라면 다르겠지만 프론튼엔드의 경계가 어디인가, 내가 하고 싶은 건 뭐지? 하는 생각이든다..
음... 프론트의 중요한 요소는 상태관리가 아닐까 싶어요! 데이터를 받아오고 그 데이터가 변경 되었을 때 이를 어떻게 감지하고 효율적으로 다시 렌더링을 할 것인지가 관건이 아닐까 생각을 해봅니다! 물론 변경된 데이터가 서버에 저장이 될 수도, 안 될 수도 있겠구요 ㅎㅎ 그리고 데이터 가공 문제는 저도 경계가 모호하다고 생각을 하는데 개인적으로 자주 발생할 수 있는 요청에 대해서는 미리 서버 측에서 가공을 한 데이터를 갖고 있는 것이 좋다고 생각을 하고 매번 변칙적인 데이터를 처리해야 한다면 프론트에서 처리를 하는 것이 좋다고 생각을 합니다. 그 많은 클라이언트를 서버 한 대가 감당하긴 힘들테니까요! 개인적인 주니어 개발자의 의견이었습니당... 성현님 화이팅하세요!