함수를 어디까지 어떻게 분리해야 할까?에 대해 고민하고 있다면 => '쏙쏙 들어오는 함수형 코딩'을 읽어보자

Maria Kim·2023년 11월 22일
0
post-thumbnail


https://www.yes24.com/Product/Goods/108748841

오늘은 너무 너무 주니어 개발자 동료들에게 추천해 주고 싶은 책을 들고 왔다.

언제나 궁금하던, 하지만 해소할 수 없었던, 어떻게 하면 더 좋은 코드가 될까? 더 좋은 설계가 될까?에 대해 좋은 목표들을 알려준다. 어디까지 어떻게 함수를 분리해야 하는가에 대한 좋은 기준들을 제시한다.
(정답이 없는 개발이지만 조만간은 그래도 좋은 목표가 될 것 같다.)

또, 함수형 프로그래밍에 대해 알아보면 너무 이론만 있다던가, 실제로 적용이 어렵다던가, 아니면 너무 직접 적용한 사례만 있어 실제로 어떻게 써야 할지 사실 너무 모호했다면.
이 책을 읽으면 이제는 함수형 프로그래밍을 실제로 어떻게 적용할지 감이 잡힌다.

책 읽는 내내 계속 확장하면서 함수형 코딩을 연습 시켜주기 때문이다.
(혹시, 헤드 퍼스트 디자인 패턴을 읽은 분들은 거기서 매 챕터마다 연습시켜주는 느낌이랄까? 하지만, 그 책에서는 한 챕터에 한 개의 주제가 있었다. 그래서, 사실 익숙해지기 전에 다음 주제에 대해 넘어가버렸다. 사실 익숙해지기 전에 넘어가 계속 어려웠다. 하지만 이 책은 1개의 주제를 계속 책 내내 연습하는 느낌이다. 그래서 다 읽고 나면, 나 이제 잘 쓸 수 있을 듯?라는 자신감을 가지게 한다. 사실, 다 읽기 전 중간부터 코드로 달려가 당장 함수형으로 고쳐보고 싶은 충동이 들게 한다.)

인상 깊었던 내용

액션, 계산, 데이터

이렇게 나눌 수 있는 순간 끝난다.
3,4,5 장에서 자세히 다룬다.
이 분류가 껌이다? 굳이 이 책을 안 읽어도 되는 분이실지도?

얕은 복사

함수형 프로그래밍하면 불변성이 사실 제일 먼저 떠오르지 않는가?
그럼 사실 복사를 해야 하는데, 사실 제대로 알기 전에는 복사를 저렇게 많이 하면 성능상 문제가 생길 텐데 실제로 많은 곳에서 사용할 수 있을까 하는 의문이 든다.
하지만 얕은 복사와 구조적 공유를 통해 복사한다면 생각보다 많은 복사가 실제로 일아나지 않음을 알 수 있다. 불변성을 통해 얻을 수 있는 이점을 잘 설명하고 있다.

6장에서 자세히 다룬다.

계층형 설계

대략은 알고 있었지만 정확히 기준을 다시 정할 수 있었다.

  • 계층형 설계의 전반적 이해가 높아졌다.
  • 비즈니스 규칙, 도메인 규칙 등의 계층 분리를 이해하게 되었다.
  • 추상화 벽을 만들어 세부적인 구현 함수와 비즈니스 함수를 구분해 개발할 수 있게 되었다. 이를 통해, 코드 수정 필요시, 필요한 수준에 따라 해당 층의 수정만 되게 되었다.
  • 인터페이스 개념을 다시 정리할 수 있었다.
  • 어떤 함수에는 재활용에 더 초점을 맞춰 개발하고 어떤 함수에는 유지 보수에 용이하도록 설계해야 할지 구분할 수 있게 된다.
  • 어떤 함수부터 테스트해야 하는가를 알게 된다.

7,8,9장에서 자세히 다룬다.

고차함수를 통한 리펙토링

소소한 후기

사실 1 번에 모든 내용을 숙지하기에는 나한테는 많은 내용이 이었다.
또, 이번에야 제대로 알게 된 내용도 많아 한 번 더 읽어봐야 제대로 내용을 숙질 할 수 있을 것 같다.
그래도 내가 가진 질문들에 속 시원하게 알려주고 이해도 잘 되는 책을 찾아 너무너무 행복하다!

아 맞다. 그리고 이 책이 JS로 쓰여서 너무 좋다!!!! 요즘은 그래도 JS 코드가 적힌 책들이 많이 나오는 것 같다. 🥹🥳


최근 개발할 때 기획의 관점, 디자인의 관점에서도 코드를 구분해 개발하는 기준도 필요하다는 글을 봤다.

어디까지 함수를 구분해야 하는가에 대한 답을 찾을 수 도저히 찾기 힘들 때가 있었다. 생각해보면 그저 보기 편하게 하는 수준만을 고려해서였다.

하지만, 함수의 구분은 유지 보수의 이유, 재사용성에서 필요하다.
사람들이 내가 작성한 코드를 다시 보게 될 때는 유지 보수와 재사용을 하기 위해서이니까.

그렇다면 유지 보수는 언제 필요할까?
개발자의 기준에서는 더 나은 성능을 위해 구조를 변경하기 위해서가 한 이유가 될 수 있다.
또, 기획과 디자인의 변경에 따른 수정일 것이다.

그렇기 때문에, 개발의 관점도 중요하지만, 기획과 디자인에서 어떻게 서비스를 구분하고 있는지 파악하고 이를 코드에 잘 녹여 놓는 것이 중요한 것 같다.

profile
Frontend Developer, who has business in mind.

0개의 댓글