TIL (Today I Learned)

// 2022.01.23

오늘 읽은 범위

// 3장. 함수

책에서 기억하고 싶은 내용을 써보세요.

• 의도를 분명히 표현하는 함수를 어떻게 구현할 수 있을까? 함수에 어떤 속성을 부여해야 처음 읽는 사람이 프로그램 내부를 직관적으로 파악할 수 있을까?

• 작게 만들어라

• 함수 하나당 추상화 수준도 하나로. 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다. 특정 표현 이 근본 개념인지 아니면 세부사항인지 구분하기 어려운 탓이다.

• 한가지 일만 하게 하라. 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.

• 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 함수 다음에는 추상화 수준 이 한 단계 낮은 함수가 온다. 즉, 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. 나는 이것을 내려가기 규칙이라 부른다.

• “

  코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다.” 한 가지만 하 는 작은 함수에 좋은 이름을 붙인다면 이런 원칙을 달성함에 있어 이미 절반은 성공했다. 함수가 작고 단순할수록 서술적인 이름을 고르기도 쉬워진다.

  이름이 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다. 함수 이름 을 정할 때는 여러 단어가 쉽게 읽히는 명명법을 사용한다. 그런 다음, 여러 단어 를 사용해 함수 기능을 잘 표현하는 이름을 선택한다.

• 함수 이름과 인수 사이에 추상화 수준이 다르 다. 게다가 코드를 읽는 사람이 현 시점에서 별로 중요하지 않은 세부사항, 즉 StringBuffer를 알아야 한다.

  테스트 관점에서 보면 인수는 더 어렵다. 갖가지 인수 조합으로 함수를 검증 하는 테스트 케이스를 작성한다고 상상해보라! 인수가 없다면 간단하다.

• 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다.

• 오류 처리도 한 가지 작업이다.

  함수는 ‘한 가지’ 작업만 해야 한다. 오류 처리도 ‘한 가지’ 작업에 속한다. 그러므 로 오류를 처리하는 함수는 오류만 처리해야 마땅하다. (위 예제에서 보았듯이) 함수에 키워드 try가 있다면 함수는 try 문으로 시작해 catch/finally 문으로 끝나 야 한다는 말이다.

• 어쩌면 중복은 소프트웨어에서 모든 악의 근원이다. 많은 원칙과 기법이 중

  복을 없애거나 제어할 목적으로 나왔다.

• 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 논문이나 기사를 작성할 때 는 먼저 생각을 기록한 후 읽기 좋게 다듬는다. 초안은 대개 서투르고 어수선하 므로 원하는 대로 읽힐 때까지 말을 다듬고 문장을 고치고 문단을 정리한다.

  내가 함수를 짤 때도 마찬가지다. 처음에는 길고 복잡하다. 들여쓰기 단계도 많고 중복된 루프도 많다. 인수 목록도 아주 길다. 이름은 즉흥적이고 코드는 중 복된다. 하지만 나는 그 서투른 코드를 빠짐없이 테스트하는 단위 테스트 케이 스도 만든다.

  그런 다음 나는 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한 다. 메서드를 줄이고 순서를 바꾼다. 때로는 전체 클래스를 쪼개기도 한다. 이 와중에도 코드는 항상 단위 테스트를 통과한다.

• 최종적으로는 이 장에서 설명한 규칙을 따르는 함수가 얻어진다. 처음부터 탁 짜내지 않는다. 그게 가능한 사람은 없으리라.

• 함수는 그 언어에서

  동사며, 클래스는 명사다.

• 프로그래밍의 기술은 언제나 언어 설계의 기술이다.

• 대가master 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이 야기로 여긴다. 프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 좀 더 표현 력이 강한 언어를 만들어 이야기를 풀어간다. 시스템에서 발생하는 모든 동작을 설명하는 함수 계층이 바로 그 언어에 속한다. 재귀라는 기교로 각 동작은 바로 그 도메인에 특화된 언어를 사용해 자신만의 이야기를 풀어간다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 이번 장은 공감되기도 하고, 또 프론트엔드 개발할때는 적용이 어려운 면도 있다고 생각하며 읽었다. 함수 컴포넌트에서는 인수(프롭)도 필연적으로 많아지고, 컨디션에 따라 if나 case 로직을 구성해야하는 경우가 아주 많기 때문이다.

• 지난 챕터에서도 추상화 정도를 어떻게 일관적으로 하며, 어느정도로 추상화 하는것이 좋은가에 대해서 고민을 하며 읽었었다. 이번 챕터에 따르면 함수는 하나의 일만, 한가지의 추상화레벨만 가져야 한다. 그런데 컴포넌트(함수)를 무조건 하나의 일만 하도록 잘게 쪼개는게 어쩔때는 더욱 뎁스를 늘이고 한눈에 로직플로우를 캐치하지 못하게 한다고 느낀다.

• 또 한가지는 협업하는 동료마다 함수추상화 정도가 달라서 누구는 이정도 작은 함수는 뭉치고, 누구는 컴포넌트 독립성과 추상화를 위해 잘게 쪼개어 구현한다. 이는 선호도의 문제와도 연관ㅇㅣ 있고, 개발 속도에도 영향이 있다. 풀리지 않는 고민이다.

• 그래도 함수단위가 절대적으로 일관성이 없다하더도, 글을 읽듯이 코드의 논리 흐름이 읽어지도록 작성한다면 보완이 된다. 함수는 동사이다. 라는 말에 철저히 공감하며, 문장을 잇고 움직이게 하는 역할은 동사가 하기 때문에 함수가 어떤 역할을 하는지 명확히 하는 것은 중요하다고 느낀다.

• 이를 위해서 네이밍을 잘해야한다. 실제 구현이 하는 일과 함수이름이 일치하지 않아서 코드를 파악하는데에 오래걸린적이 너무도 많다. 혹은, 함수 내부로직을 전부 파악하지 않더라도 이름만 보고 예측할 수 있다면(그리고 예측대로 동작한다면) 최고다. 결국엔 궁극적으로 이정도의 역할을 할 수 있는 함수가 필요하기 때문에 우리는 좋은이름짓기, 함수 쪼개기, 리팩토링에 에너지를 쓰는 것 아닌가!

• 함수형 프로그래밍, 리턴값을 바로 예측하기 쉬운, 사이드이펙트가 없도록 하는. Fxts, remeda 등 활용하기를 시도하는데 이런 라이브러리를 활용해 함수 구현을 하면 함수역할이 명확히 드러난다는 점은 마음에 든다. 그치만 가끔은 너무 추상화되어있어 지식이 없는 사람은 일일히 어떤 동작이 되는지 예견하거나 찾아봐야 할 수도 있다는 점, 우리가 익숙해져있는 일상언어에서처럼 명령형 혹은 절차적으로 이해하기 어렵다는 점이 단점이겠다.

• 확실한 건, 좋은 코드를 짠다는 건 복잡한 알고리즘이나 로직을 짜는 것이 아니라, 그 복잡한 알고리즘과 로직을 처음 보는 사람이 읽어도 쉽게 읽을 수 있도록 짜는 것이다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 예시코드가 자바로 작성되어 있어 조금 낯설었다. 타입스크립트를 주로 쓰는 입장에서 강타입 언어를 써보는 경험도 필요하다고 생각하고 있었고. 또 클래스, 인터페이스도 요즘 프론트엔드 개발에서 점점 접하기 어려워지고 있어서 종종 과거의 구현들에 관심을 가져보는 것도 좋은 코드란 뭔지, 프로그래밍 패러다임의 변화를 이해해보는데에 좋을 것 같다.

• https://m.blog.naver.com/knix008/220700047637 함수의 추상화에 관한 블로그