랑데브

🔖 오늘 읽은 범위 : 10장, 클래스 (p.179 ~ p.191) 😀 책에서 기억하고 싶은 내용 큰 함수를 작은 함수 여럿으로 쪼개라. 몇몇 함수가 몇몇 변수만 사용한다면 독자적인 클래스로 분리해라. 변경하기 쉬운 클래스 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다. 개방 폐쇄 원칙Open-Closed Principle 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다. 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다. 시스템의 결합도를 낮추면 유연성과 재사용성도 높아진다. 시스템 요소가 서로 잘 격리되어 있으면 각 요소를 이해하기 더 ..

🔖 오늘 읽은 범위 : 10장, 클래스 (p.170 ~ p.178) 😀 책에서 기억하고 싶은 내용 클래스 체계 정적 공개 상수 → 정적 비공개 변수 → 비공개 인스턴스 변수 → 공개 함수 → 비공개 함수 공개 변수가 필요한 경우는 거의 없다. 추상화 단계가 순차적으로 내려간다. 프로그램은 신문기사처럼 읽힌다. 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. 같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면 그 함수나 변수를 protected로 선언하거나 패키지 전체로 공개한다. 하지만 그 전에 비공개 상태를 유지할 온갖 방법을 강구한다. 클래스는 작아야 한다. 작명은 클래스 크기를 줄이는 첫 번째 관문이다. 간결한 이름이 떠오르지 않는다면 클래스 크기가 너무 큰 것이다. 클래스..

🔖 오늘 읽은 범위 : 9장, 단위 테스트 (p.158 ~ p.169) 😀 책에서 기억하고 싶은 내용 테스트 코드에서 가독성을 높이려면, 명료성, 단순성, 풍부한 표현력이 필요하다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다. 테스트 API 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 다르다. 단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다. StringBuffer를 피해라. assert문 개수를 줄여라. 테스트 함수마다 한 개념만 테스트하라. F.I.R.S.T 규칙 Fast: 테스트는 빨라야 한다. 테스트가 느리면 자주 돌릴 엄두를 못 낸다. Independent: 각 테스트는 서로 의존하면 안 된다. 각 테스트는 독립적으로, 그리고 어떤 순서로 ..

🔖 오늘 읽은 범위 : 9장, 단위 테스트 (p.154 ~ p.157) 😀 책에서 기억하고 싶은 내용 TDD 법칙 세가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 테스트 코드는 실제 코드 못지 않게 중요하다. 코드에 유연성, 유지 보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다. 🤔 오늘 읽은 소감은? 테스트 주도로 개발하는 것이 왜 중요한지 생각해볼 수 있었다. 코드를 작성하면서도 확신을 가지지 못할 때가 많았는데 테스트 주도 개발 방..

🔖 오늘 읽은 범위 : 7장, 오류 처리 (p.138 ~ p.142) 😀 책에서 기억하고 싶은 내용 null을 반환하지 마라 사용하려는 외부 API가 null을 반환한다면 감싸기 메서드를 구현해 예외를 던지거나 특수 사례 객체를 반환하는 방식을 고려한다. 메서드에서 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은 더 나쁘다. 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 그렇다면 애초에 null을 넘기지 못하도록 금지하는 정책이 합리적이다. 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다. 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다...

🔖 오늘 읽은 범위 : 7장, 오류 처리 (p.130 ~ p.137) 😀 책에서 기억하고 싶은 내용 오류가 발생하면 예외를 던지는 편이 낫다. Try-Catch-Finally 문부터 작성하라 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 미확인 예외를 사용하라 오류 메시지에 정보를 담아 예외와 함께 던져라 외부 API를 사용할 때는 감싸기 기법이 최선이다. 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다. 🤔 오늘 읽은 소감은? 로직과 에러 처리하는 코드를 분리해야겠다. 일일이 에러를 정의해주는 것보다는 try catch 문을 이용해 에러 처리를 해야겠다. 예외 처리하는 법을 연습해봐야겠다. 🧐 궁금한 내용이 있거나,..

🔖 오늘 읽은 범위 : 6장, 객체와 자료 구조 (p.118 ~ p.128) 😀 책에서 기억하고 싶은 내용 변수를 비공개로 정의하는 이유는 남들이 변수에 의존하지 않게 만들고 싶어서다. 구현을 감추려면 추상화가 필요하다. 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지는 않는다. getter와 setter 함수로 변수를 다룬다고 클래스가 되지는 않는다. 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. 객체와 자료 구조의 차이 객체는 동작을 공개하고 자료를 숨긴다. 그래서 기존 동작을 ..

미션! 더러운 코드를 고쳐라! 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 * 60 * 1000)) / ..

🔖 오늘 읽은 범위 : 5장, 형식 맞추기 (p.96 ~ p.116) 😀 책에서 기억하고 싶은 내용 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다. 코드 형식은 의사소통의 일환이다. 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지 보수 용이성과 확장성에 계속 영향을 미친다. 이름은 간단하면서도 설명이 가능하게 짓는다. 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경 써서 짓는다. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록..

TIL (2022.01.29) DAY 8 🔖 오늘 읽은 범위 : 4장, 주석 (p.75 ~ p.94) 😀 책에서 기억하고 싶은 내용 나쁜 주석 주절거리는 주석 같은 이야기를 중복하는 주석 오해할 여지가 있는 주석 의무적으로 다는 주석 모든 함수에 Javadocs를 달거나 모든 변수에 주석을 달아야 한다는 규칙은 어리석기 그지없다. 이력을 기록하는 주석 예전에는 모든 모듈 첫머리에 변경 이력을 기록하고 관리하는 관례가 바람직했다. 당시에는 소스 코드 관리 시스템이 없었으니까. 하지만 이제는 혼란만 가중할 뿐이다. 너무 당연한 사실을 언급하며 새로운 정보를 제공하지 못하는 주석 개발자가 주석을 무시하는 습관에 빠진다. 있으나 마나 한 주석을 달려는 유혹에서 벗어나 코드를 정리하라. 함수나 변수로 표현할 수 ..