오늘 TIL 3줄 요약

• 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.

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

• 대가 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다.

TIL (Today I Learned) 날짜

2022. 04. 27

오늘 읽은 범위

3장. 함수

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

함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다.

• 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다.

• 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다. (..중략..) 근본 개념과 세부사항을 뒤섞기 시작하면, 깨어진 창문처럼 사람들이 함수에 세부사항을 점점 더 추가한다.

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

• (함수) 이름이 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다.

• (함수) 이름을 붙일 때는 일관성이 있어야 한다. 모듈 내에서 함수 이름은 같은 문구, 명사, 동사를 사용한다.

• 함수에서 이상적인 인수 개수는 0개(무항)다.

• 입력 인수를 변환하는 함수라면 변환결과는 반환값으로 돌려준다. StringBuffer transform(StringBuffer in) > void transform(StringBuffer out)

• 플래그 인수는 추하다. 함수로 부울 값을 넘기는 관례는 정말로 끔찍하다. 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까! 참이면 이걸하고 거짓이면 저걸 한다는 말이니까

• 단항 함수는 함수(이름)와 인수(이름)가 동사/명사 쌍을 이뤄야 한다.

• 함수는 객체 상태를 변경하거나 아니면 객체 정보를 반환허가나 둘 중 하나다.

• 함수는 '한 가지' 작업만 해야 한다. 오류 처리도 '한 가지' 작업에 속한다.

• 소프트웨어 개발에서 지금까지 일어난 혁신은 소스 코드에서 중복을 제거하려는 지속적인 노력

• 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. (..중략..) 먼저 생각을 기록한 후 읽기 좋게 다듬는다. (..중략..) 처음부터 탁 짜내지 않는다. 그게 가능한 사람은 없으리라.

• 함수는 그 언어에서 동사며, 클래스는 명사다.

• 프로그래밍의 기술은 언제나 언어 설계의 기술이다. 예전에도 그랬고 지금도 마찬가지다.

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

• 도움되는 글이 너무 많았다. 함수는 한 가지를 해야하고, 잘 해야하고, 그것만을 해야한다. 함수 작성시에 짧게 짜야 한다는 것은 알고는 있었지만, 내 함수들은 책에 나오는 깨어진 창문처럼 함수에 세부사항이 점점 추가되어 거대해졌다. 다 필요한데 어떻게 줄여야 하나 싶었는데, 3장 함수의 첫번째 규칙 '작게! 더 작게!' 함수를 짧게만 만드려다 보니 안되었던것 같다. 기능을 작게 나누고, 더 작게 나누면 자연스레 함수는 짧아지겠다. 또, 함수를 짧게 작성해야하니 덩달아 함수명도 짧게 축약해서 지었고, 시간이 지나면서 짧게 축약된 함수명을 알아채지 못했고, 같은 기능의 다른 함수들이 중복되어 만들어졌었다. 소프트웨어서 모든 악의 근원인 중복을 수도 없이 만들어냈던 것 같다.

• 변수명 파트도 도움이 되었지만, 함수파트는 마음에 새겨지는 구절이 많았다. 함수는 그 언어에서 동사며, 클래스는 명사다. 기억저편에 알고 있는 개념을 이렇게 멋지고 짧은 문장으로 설명해주다니.. 너무 부러운 문장력이다. 앞으로 개발자의 길을 계속 걷는 동안 시스템을 (구현 할) 프로그램이 아니라 (풀어 갈) 이야기로 여기게 되어 좋은 코드 글짓기를 할 수 있게 되길 바래본다.