개발자 99% 커뮤니티에서 수다 떨어요!
TIL (Today I Learned)
// 2022.02.23
오늘 읽은 범위
// 3장. 함수
책에서 기억하고 싶은 내용을 써보세요.
함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. - 44p
함수가 확실히 ‘한 가지’ 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. - 46p
핵심은 짧으면서도 ‘한 가지’만 하는 함수다. 위에서 아래로 TO 문단을 읽어내려 가듯이 코드를 구현하면 추상화 수준을 일관되게 유지하기가 쉬워진다. - 47p
함수가 작고 단순할수록 서술적인 이름을 고르기도 쉬워진다.
이름이 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다. -49p
함수에서 이상적인 인수 개수는 0개(무항)다. 다음은 1개(단항)고, 다음은 2개(이항)다. 3개(삼항)는 가능한 피하는 편이 좋다. 4개 이상(다항)은 특별한 이유가 필요하다. 특별한 이유가 있어도 사용하면 안 된다. - 50p
함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다. 둘 다 하면 안 된다. 객체 상태를 변경하거나 아니면 객체 정보를 반환하거나 둘 중 하나다. - 56p
함수는 ‘한 가지’ 작업만 해야 한다. 오류 처리도 ‘한 가지’ 작업에 속한다. 그러므로 오류를 처리하는 함수는 오류만 처리해야 마땅하다. - 59p
중복은 문제다. 코드 길이가 늘어날 뿐 아니라 알고리즘이 변하면 네 곳이나 손봐야 하니까. 게다가 어느 한곳이라도 빠뜨리는 바람에 오류가 발생할 확률도 네 배나 높다. - 60p
소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 논문이나 기사를 작성할 때는 먼저 생각을 기록한 후 읽기 좋게 다듬는다. 초안은 대개 서투르고 어수선하므로 원하는 대로 읽힐 때까지 말을 다듬고 문장을 고치고 문단을 정리한다. -61p
대가 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다. 프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 좀 더 표현력이 강한 언어를 만들어 이야기를 풀어간다. 시스템에서 발생하는 모든 동작을 설명하는 함수 계층이 바로 그 언어에 속한다. 재귀라는 기교로 각 동작은 바로 그 도메인에 특화된 언어를 사용해 자신만의 이야기를 풀어간다. -62p
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
클린 코드를 읽으면서 가장 많이 하는 행위는 반성이고, 이번 챕터를 읽을 때도 마찬가지였다. 여러 가지 기능을 수행하는 함수를 만들기 일쑤였고, 기능을 제대로 알 수 없는 이름을 함수에게 부여했으며, 함수가 여러 개의 인수를 받도록 했고, 반복되는 부분도 있었으며, 오류 처리를 한 함수 내에서 수행한 적도 많았다. 이번 챕터를 읽으면서 내가 나의 협업자, 그리고 그 협업자 중 하나인 미래의 나를 얼마나 고려하지 않으며 코딩을 했는지 반성할 수 있었다.
소프트웨어를 짜는 행위는 여느 글짓기와 비슷하며, 원하는 대로 읽힐 때까지 다듬는 과정이 필요하는 구절과 대가 프로그래머는 시스템을 구현할 프로그램이 아닌 풀어갈 이야기로 여긴다는 말이 정말 인상깊었다. 내가 작성한 코드를 누구라도 잘 읽어낼 수 있도록 계속해서 다듬는 과정을 습관이 되도록 노력해야겠다는 생각이 들었다. 리포트를 쓸 때나, 발표를 준비할 때는 듣거나 읽을 사람을 고려하며 그렇게 많은 첨삭 과정을 반복했으면서, 왜 코딩을 할 때는 읽을 사람을 고려하지 않았을까. 클린코드의 앞부분에서 저자가 이야기했듯, 클린 코드를 위한 노력이 일상의 습관이 되어 몸에 체화될 수 있도록 계속해서 신경써야겠다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
SRP(Single Responsibility Principle) : 클래스를 변경할 이유는 하나여야 한다. 즉, 클래스가 한 가지 책임을 갖도록 하자는 것.
OCP(Open Closed Principle) : 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다. 이는 하위 클래스가 상위 클래스로부터 필요하지 않은 기능을 상속받는 것을 방지하기 위함임. (출처 : 클래스 설계 원칙, https://terms.naver.com/entry.naverdocId=3533000&cid=58528&categoryId=58528)