dev.jaieve 공부기록

DAY 10 🚀 오늘 읽은 범위 : 8 🔥 책에서 기억하고 싶은 내용 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보자! 🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면?

DAY 8 🚀 오늘 읽은 범위 : 6장 객체와 자료구조 🔥 책에서 기억하고 싶은 내용 1. 자료추상화 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다.(p. 119) 2. 자료/객체 비대칭 객체는 추상화 뒤로 자료를 숨긴채 자료를 다루는 함수만 공개한다. 자료구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.(p. 119) 3. 디미터 법칙 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. ... 즉, 객체는 조회 함수(getter)로 내부구조를 공개하면 안된다.(p.123) 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보자! 1. 자료 추상화 추상인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 ..

DAY 7 🚀 오늘 읽은 범위 : 5장 형식 맞추기 🔥 책에서 기억하고 싶은 내용 적당한 행 길이를 유지 소스 파일 첫부분은 고차원 개념과 알고리즘을 설명하낟. 아래로 내려갈수록 의도를 세세하게 묘사한. 마지막에는 가장 저차원 함수와 세부 내역이 나온다. 빈 행은 새로운 개념을 시작한다는 시각적 단서이다. 코드를 읽어내려가다 보면 빈 행 바로 다음 줄에 눈길이 멈춘다. 인스턴스 변수는 클래스이 맨 처음에 선언한다.(p.103) ... 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다. 또 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다. 그러면 프로그램이 자연스럽게 읽힌다. ... 그만큼 모듈 전체의 가독성도 높아진다.(p.104) 신문 기사와 마찬가지로 가장 중요한 개념을 ..

DAY 5 🚀 오늘 읽은 범위 : 3장 함수 🔥 책에서 기억하고 싶은 내용 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.(p. 44) 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.[G34] 함수 당 추상화 수준은 하나로! 함수가 확실히 ‘한 가지’ 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다.(p. 45) 근본 개념과 세부사항을 뒤섞기 시작하면, 깨어진 창문처럼 사람들이 함수에 세부사항을 점점 더 추가한다.(p. 46) 서술적인 이름을 사용하라! 함수가 하는 일을 좀 더 잘 표현하므로 훨씬 좋은 이름이다. ... 함수가 작고 단순할수록 서술적인 이름을 고르기도 쉬워진다.(p.49) 객체를 생성해 인수를..

DAY 4 🚀 오늘 읽은 범위 : 다른 사람들의 TIL 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보자! leeq님 링크 1장을 읽고 작성한 TIL을 읽으면서 leeq님만이 느끼신 공감대에 대해서 알 수 있었다. 역시 공학계열이라면 무엇인가 일맥상통하는 부분이 있을 수 밖에 없다는 생각을 장난삼아 해봤다. leeq님의 개인적인 견해를 읽고 큰 공감을 했다. 작년 8월 회사에 첫 입사를 하고 클린코드에 대해 고민하면서, 이 책을 어떤 사람에게 추천하고 싶은지 고민해봤었는데 그 사람은 바로 sysout을 마구잡이로 뽑아내던 동기였다. 그리고 기본적인 Naming convension과 indent조차 지키지 않는 초보 개발자들에게는 이 책의 개념이 아무리 어려워도 프그래머로 돈을 벌어먹겠다는 생각을 해..

DAY 3 🚀 오늘 읽은 범위 : 2장 의미있는 이름 🔥 책에서 기억하고 싶은 내용 클래스 이름과 객체 이름은 명사나 명사구가 적합하다. ... 메서드 이름은 동사나 동사구가 적합하다(p. 32) 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야한다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.(p. 35) 일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.(p. 37) 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보자! 검색하기 쉬운 이름을 사용하라 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.(p. 26) 실제로 회사에서 특정 클래스..

DAY 2 🚀 오늘 읽은 범위 : 추천사 ~ 1장 깨끗한 코드 🔥 책에서 기억하고 싶은 내용 기능을 추가할수록 코드는 엉망이 되어갔고, 결국은 감당이 불가능한 수준에 이르렀다. 회사가 망한 원인은 바로 나쁜 코드 탓이었다. 프로그래머라면 누구나 당연히 나쁜 코드로 고생한 경험이 있다. 그렇다면 묻겠다. 어째서 나쁜 코드를 짰는가? 급해서? 서두르느라? 아마 그랬으리라. 제대로 짤 시간이 없다고 생각해서, 코드를 다듬느라 시간을 보냈다가 상사한테 욕먹을까 봐, 지겨워서 빨리 끝내려고, 다른 업무가 너무 밀려 후딱 해치우고 밀린 업무로 넘어가려고...... 모두가 겪어본 상황이다. 우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. (p.4) ... 다시 돌아와 나중에 정리..