TIL (Today I Learned)
2022.04.27
오늘 읽은 범위
3장. 함수
책에서 기억하고 싶은 내용
지금까지 경험을 바탕으로 그리고 오랜 시행착오를 바탕으로 나는 작은 함수가 좋다고 확신한다. - 43page
이 말은 중첩 구조가 생길만큼 함수가 커져서는 안 된다는 뜻이다. 그러므로 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다. -44page
함수는 한 가지를 해야 한다. 그 한가지를 잘 해야 한다. 그 한가지만을 해야 한다. -44page
한 가지 작업만 하는 함수는 자연스럽게 섹션으로 나누기 어렵다. -45page
근본 개념과 세부사항을 뒤섞기 시작하면, 깨어진 창문처럼 사람들이 함수에 세부사항을 점점 더 추가한다. -46page
위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. 나는 이것을 내려가기 규칙이라 부른다. - 46page
핵심은 짧으면서도 '한 가지'만 하는 함수다. -46page
이름이 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다. -49page
서술적인 이름을 사용하면 개발자 머릿속에서도 설계가 뚜렷해지므로 코드를 개선하기 쉬워진다. -49page
함수에서 이상적인 인수 개수는 0개(무항)이다. 4개 이상(다항)은 특별한 이유가 필요하다. 특별한 이유가 있어도 사용하면 안 된다. 인수는 어렵다. 인수는 개념을 이해하기 어렵게 만든다. - 50page
최선은 입력 인수가 없는 경우이며, 차선은 입력 인수가 1개뿐인 경우다. -51page
함수에 인수 1개를 넘기는 이유로 가장 흔한 경우는 두 가지다. 하나는 인수에 질문을 던지는 경우다. boolean fileExist("MyFile")이 좋은 예다. 다른 하나는 인수를 뭔가로 변환해 결과를 반환하는 경우다. - 51page
인수가 2-3개 필요하다면 일부를 독자적인 클래스 변수로 선언할 가능성을 짚어 본다. -53page
예)
Circle makeCircle(double x, double y, double radius);
Circle makeCircle(Point center, double radius);
함수의 의도나 인수의 순서와 의도를 제대로 표현하려면 좋은 함수 이름이 필수다. 단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야 한다. ex) writeField(name)
부수효과를 일으키지 마라! 많은 경우 시간적인 결합이나 순서 종속성을 초래한다. -55page
함수를 자게 만든다면 간혹 return, break, continue를 여러 차례 사용해도 괜찮다. 오히려 때로는 단일 입/출구 규칙보다 의도를 표현하기 쉬워진다. 반면, goto문은 큰 함수에서만 의미가 있으므로, 작은 함수에서는 피해야만 한다. -61page
최종적으로는 이 장에서 설명한 규칙을 따르는 함수가 얻어진다. 처음부터 탁 짜내지 않는다. 그게 가능한 사람은 없으리라. -62page
오늘 읽은 소감은? 떠오르는 생각
오늘도 책을 읽으면서 안도감을 느낀다. 특히 결론에 나온 내용 "처음부터 탁 짜내지 않는다. 그게 가능한 사람은 없으리라."은 항상 좋은 변수, 함수 이름이 생각나지 않던 나에게 위로를 해주는 것 같다. 왜이리 이름 짓기가 어려운지... 정말 변수이름을 지었다가도 다시 보면 마음에 들지 않았던 적이 얼마나 많은지 모른다. 그런데 왠지 다른 사람들은 항상 쉽게 탁 짜내는 것 같아서 자괴감이 들었었는데 개발자라면 항상 안고 가야하는 그런 어려움이라는 것을 알게되는 것 같다.
급할 때는 한가지 일만 하는 함수로 나누기가 얼마나 귀찮은지 그냥 여러가지를 다 때려박고 실행만 되는 쓰레기를 짜고 싶은 유혹이 들때가 있다. 미래의 내가 고생하고 있을 모습을 생각하면 다시금 소스코드를 수정하는 경우도 있지만 다시 소스코드를 살펴볼 때면 그냥 빨리 결과물을 보려고 급하게 짜고 넘어간 것들이 보여서 다시 수정하는 경우도 있다. 다른 사람들의 좋은 코드를 보고나서 내 코드를 보면 다시 고치는 경우도 있다. 이렇게 성장하면서 고쳐가는게 개발자의 삶인 것 같다.
너무 급하게 생각하지말고 좋은 코드 많이 보고, 이런 좋은 책들에서 이미 이런 고민해본 사람들의 의견을 참고하며 매일매일 고쳐나가다보면 언젠가는 나도 한번에 탁 하고 좋은 코드를 짜내지는 못해도 두세번 고치면 꽤 쓸만한 코드를 내놓는 개발자가 될 수 있을 것 같다는 희망을 가져본다.
댓글