[전호영] 3장, 4장 : 함수, 주석

3장/전호영.md

@@ -0,0 +1,28 @@
+# 다시 읽어 볼 문장들
+- 함수를 만드는 첫째 규칙은 '작게'다.
+- 함수를 만드는 둘째 규칙은 '더 작게!'다.
+- 다시 말해\, if 문/else 문/while 문 등에 들어가는 블록은 한 줄이어야 한다는 의미다.
+- 이 말은 중첩 구조가 생길만큼 함수가 커져서는 안된다는 뜻이다. 그러므로 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다.
+- 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다.
+- 우리가 함수를 만드는 이유는 큰 개념을 (다시 말해, 함수 이름을) 다음 추ㅏㅇ화 수준에서 여러 단계로 나눠 수행하기 위해서가 아니던가.
+- 근본 개념과 세부사항을 뒤섞기 시작하면, 깨어진 창문처럼 사람들이 함수에 세부사항을 점점 더 추가한다.
+- 핵심은 짧으면서도 '한 가지'만 하는 함수다.
+- 위에서 아래로 읽어내려 가듯이 코드를 구현하면 추상화 수준을 일관되게 유지하기 쉬워진다.
+- 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.
+- 길고 서술적인 이름이 길고 서술적인 주석보다 좋다.
+- 함수에서 이상적인 인수 개수는 0개(무항)다. 다음은 1개(단항)고, 다음은 2개(이항)다. 3개(삼항)은 가능한 피하는 편이 좋다. 4개 이상(다항)은 특별한 이유가 필요하다. 특별한 이유가 있어도 사용하면 안된다.
+- 플래그 인수는 추하다. 함수로 부울 값을 넘기는 관례는 정말로 끔찍하다. 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까!
+
+```java
+    Circle makeCircle(double x, double y, double radius);
+    Circle makeCircle(Point center, double radius);
+```
+- 객체를 생성해 인수를 줄이는 방법이 눈속임이라 여겨질지 모르지만 그렇지 않다. 위 예제에서 x와 y를 묶었듯이 변수를 묶어 넘기려면 이름을 붙여야 하므로 결국은 개념을 표현하게 된다.
+- 부수 효과를 일으키지 마라!
+- 함수는 그 언어에서 동사며, 클래스는 명사다. 요구사항 문서에 나오는 명사와 동사를 클래스와 함수 후보로 고려한다는 끔찍한 옛 규칙으로 역행하자는 이야기가 아니다. 아니, 이것은 오히려 훨신 더 오래된 진실이다. 프로그래밍의 기술은 언제나 언어 설계의 기술이다. 예전에도 그랬고 지금도 마찬가지다.
+- 대가 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다. 프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 좀 더 표현력이 강한 언어를 만들어 이야기를 풀어간다. 재귀라는 기교로 각 동작은 바로 그 도메인에 특화된 언어를 사용해 자신만의 이야기를 풀어간다.
+- 진짜 목표는 시스템이라는 이야기를 풀어가는 데 있다는 사실을 명심하기 바란다.
+
+# 느낀점
+
+작은 사이즈의, 한 가지 역할만 가지고, 이름만 봐도 어떤 일을 하는지 딱 알 수 있으며, 함수 블록의 로직이, 위에서 아래로 자여느레 이해할 수 있는 함수를 만드는 것의 중요함에 대해 강조하는 느낌을 받았다. 주석에 대한 내용, 객체를 생성해 인수를 줄이는 방법은 내가 코드를 짜며 계속 고민했던 지점이라 더 좋게 느껴졌다. 하지만 마지막 3-7 목록을 봤을 땐, 과도하게 분리가 되었다 느껴졌다. 과도하게 분리가 되니, 각 함수를 찾아가는데 약간 피로함을 느꼈다. 이런 부분은 개발을 하면서 스스로 잘 조절을 해야하는 것 같다.

4장/전호영.md

@@ -0,0 +1,9 @@
+# 다시 읽어 볼 문장들
+- 잘 달린 주석은 그 어떤 정보보다 유용하다. 경솔하고 근거 없는 주석은 코드를 이해하기 어렵게 만든다. 오래되고 조잡한 주석은 거짓과 잘못된 정보를 퍼뜨려 해악을 미친다.
+- 우리는 코드로 의도를 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다. 여기서 내가 실패라는 단어를 썼다는 사실에 주목한다. 진심이다. 주석은 언제나 실패를 의미한다. 때때로 주석 없이는 자신을 표현할 방법을 찾지 못해 할 수 없이 주석을 사용한다. 그래서 주석은 반겨 맞을 손님이 아니다.
+- 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다.
+
+# 느낀점
+- 개인적으로 주석을 안 적으려고 노력하고, 그 이유도 저자가 말하는 바와 비슷해서 공감하는 부분이 많았다. 물론 저자만큼 주석을 매우매우 싫어하는 것은 아니지만...
+ 가끔 사용하지 않는 코드를 지우지 않고, 일정에 급급해 // 처리 해서 넘어간 적이 있는데, 이런 부분을 좀 주의해야 겠다.
+