Day 12 🔖 오늘 읽은 범위 : 6장 객체와 자료구조(p.118~p.128) 😃 책에서 기억하고 싶은 내용 개발자는 객체가 포함하는 자료를 포현할 가장 좋은 방법을 심각하게 고민해야 한다.(p.119) 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.(p.119) 자료 구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.(p.119) 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. 반면, 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.(p.122) 절차적인 코드는 새로운 자료 구조를 추가하기 어렵다. 그러려면 모든 함수를 고쳐야 한다. 객체 지향 코드는 새로운 운 함수를 추가하기 어렵다. 그러려면 모든 클래스를 고쳐..

DAY 11 🔖 미션: 더러운 코드를 고치자 💩 더러운 코드 const merry = document.querySelector(".js-clock"); function getClock() { const christmas = new Date("2021, 12, 25"); const date = new Date(); const timeGap = christmas - date; const xDay = Math.floor(timeGap / (1000 * 60 * 60 * 24)); const xHours = Math.floor( (timeGap - xDay * 1000 * 60 * 60 * 24) / (1000 * 60 * 60) ); const xMinutes = Math.floor((timeGap % (60..

Day 09 🔖 오늘 읽은 범위 : 4장 주석 (p.83~p.94) 😃 책에서 기억하고 싶은 내용 함수나 변수로 표현할 수 있다면 주석을 달지 마라.(p.84) 소스 코드 관리 시스템은 누가 언제 무엇을 추가했는지 귀신처럼 기억한다. 저자 이름으로 코드를 오염시킬 필요 없다.(p.86) 주석으로 처리한 코드만큼 밉살스러운 관행도 드물다.(p.86) 소스 코드 관리 시스템이 우리를 대신해 코드를 기억해준다. 이제는 주석으로 처리할 필요가 없다. 그냥 코드를 삭제하라. 잃어버릴 염려는 없다. 약속한다.(p.87) 주석을 달아야 한다면 근처에 있는 코드만 기술하라. 코드 일부에 주석을 달면서 시스템의 전반적인 정보를 기술하지 마라.(p.88) 주석에다 흥미로운 역사나 관련 없는 정보를 장황하게 늘여놓지 마라...

Day 08 🔖 오늘 읽은 범위 : 4장 주석 (p.68~p.83) 😃 책에서 기억하고 싶은 내용 나쁜 코드에 주석을 달지 마라. 새로 짜라.(p.68) 잘 달린 주석은 그 어떤 정보보다 유용하다. 경솔하고 근거 없는 주석은 코드를 이해하기 어렵게 만든다. 오래되고 조잡한 주석은 거짓과 잘못된 정보를 퍼뜨려 해악을 미친다.(p.68) 부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다.(p.69) 진신을 한 곳에만 존재한다. 바로 코드다. 코드만이 자기가 하는 일을 진실되게 말한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. 그러므로 우리는 주석을 가능한 줄이도록 꾸준히 노력해야 한다.(p.69) 자신이 저지른 난장판을 주석으로 설명하려 애쓰는 대신에 그 난장판을 깨끗이 치우는 데 시간을 보내라!(..

Day 07 🔖 오늘 읽은 범위 : 3장 함수 (p.54~p.65) 😃 책에서 기억하고 싶은 내용 부수 효과는 거짓말이다. 함수에서 한 가지를 하겠다고 약속하고선 남몰래 다른 짓도 하니까.(p.54) 일반적으로 출력 인수는 피해야 한다. 함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하는 방식을 택한다.(p.56) 함수는 뭔가를 수행하거나 무언가에 답하거나 둘 중 하나만 해야 한다. 둘 다 하면 안 된다. 객체 상태를 변경하거나 아니면 객체 정보를 반환하거나 둘 중 하나다. 둘 다 하면 혼란을 초래한다.(p.56) try/catch 블록은 원래 추하다. 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 뒤섞는다. 그러므로 try/catch 블록을 별도 함수로 뽑아내는 편이 좋다...

Day 06 🔖 오늘 읽은 범위 : 3장 함수 (p.40~p.54) 😃 책에서 기억하고 싶은 내용 함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다.(p.42) if 문/else 문/while 문 등에 들어가는 블록은 한 줄이어야 한다는 의미다. 대게 거기서 함수를 호출한다. 그러면 바깥을 감싸는 함수가 작아질 뿐 아니라, 블록 안에서 호출하는 함수 이름을 적절히 짓는다면, 코드를 이해하기도 쉬워진다.(p.44) 함수는 한 가지를 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다.(p.44) 함수가 '한 가지'만을 하는지 판단하는 방법이 하나 더 있다. 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 ..

Day 05 🔖 오늘 읽은 범위 : 2장 의미있는 이름 (p.34~p.38) 😃 책에서 기억하고 싶은 내용 말장난을 하지마라.(p.34) 해법 영역에서 가져온 이름을 사용하라.(p.34) 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다. 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 일부를 가져와야 한다.(p.35) 의미 있는 맥락을 추가하라.(p.35) 불필요한 맥락을 없애라.(p.37) 우리들 대다수는 자신이 짠 클래스 이름과 메서드 이름을 모두 암기하지 못한다. 암기는 요즘 나오는 도구에게 맡기고, 우리는 문장이나 문단처럼 읽히는 코드 아니면 (정보를 표시하는 최선의 방법이 항상 문장만은 아니므로) 적어도 표나 자료 구조처럼 읽히는 코드를 짜는 데만 집중해야 마..

Day 04 🔖 오늘 읽은 범위 : 2장 의미있는 이름 (~p.33) 😃 책에서 기억하고 싶은 내용 의도를 분명히 밝혀라.(p.22) 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.(p.22) 그릇된 정보를 피하라.(p.24) 의미 있게 구분하라.(p.25) 발음하기 쉬운 이름을 사용하라.(p.27) 검색하기 쉬운 이름을 사용하라.(p.28) 긴이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다.(p.28) 인코딩을 피하라.(p.29) 자신의 기억력을 자랑하지 마라.(p.31) 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로..

Day 03 🔖 오늘 읽은 범위 : 1장 깨끗한 코드 (~p.20) 😃 책에서 기억하고 싶은 내용 캠프장은 처음 왔을 때 보다 더 깨끗하게 해놓고 떠나라.(p.19) 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다. '코드 감각'을 확실히 얻는다는 보장도 없다. 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기수과 기교와 도구를 소개할 뿐이다. (p.20) 🤔 오늘 읽은 소감과 떠오르는 생각 오늘은 어제 읽은 부분을 다시 한번 읽어보면서 되새기고 남은 부분을 읽으면서 1장 깨끗한 코드 부분을 모두 읽었다. '이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다. '코드 감각'을 확실히 얻는다는 보장도 없다. 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기수과 기교와 도..