Stay hungry, Stay foolish

😃 책에서 기억하고 싶은 내용을 써보세요. 클래스는 작아야한다. 클래스 규칙은 크기, 작아야한다. 함수의 크기는 행수로 판단했지만, 클래스 크기는 맡은 책임의 갯수로 판단한다. 클래스 작명을 명확하게 하기 어렵다면 크기가 너무 커서 그렇다, 맡은 책임이 많은것이다. 여러일을 하는 만능 클래스를 단일 책임 클래스 여려개로 분리하는 일을 하지 않는 개발자가 많다. 그들은 단일 책임 클래스가 여러개면 이 클래스 저 클래스 넘나들며 이해하기 어려워진다고 걱정한다. 하지만 큰클래스 하나든 작은클래스 여러개든 익힐 내용은 그 양이 비슷하다. 결론은 큰 만능 클래스 하나 보다 단일 책임 클래스 여러개가 바람직하다 응집도 클래스는 인스턴스 변수 수가 작아야 한다. 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 ..

😃 책에서 기억하고 싶은 내용을 써보세요. TDD 법칙 세 가지 1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 진행한다. 3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. -> 이렇게 일 하면 사실상 실제 코드를 전부 테스트 해볼 수 있다.  테스트 코드도 깨끗하게 유지하기 당연히 테스트 코드도 실제 코드처럼 변수명, 함수의 기능 등을 신경써서 작성하여야 한다. 더러운 테스트 코드는 프로젝트의 사이즈가 커질 수록 병목의 원인이 되고 결국은 테스트 코드를 폐기하게 된다. 그러면 결함율이 높아지고 결국은 코드가 망가지기 시작하는 것이다. 따라서 테스트 코드도 막짜면 안된다. 코드에 유연성, ..

😃 책에서 기억하고 싶은 내용을 써보세요. 오류코드보다 예외처리를 try-catch 뒀다가 뭐하나 작성해라 먼저 강제로 예외를 일으키는 테스트 케이스를 작성 후 테스트를 통과하게 코드를 작성해봐라 null을 반환하지 마라 null을 반환하는 것은 호출자에게 에러를 떠넘기는 행위다 또한 메서드에서 null을 인수로 전달하지도 마라 오류처리를 프로그램 논리와 분리해서 독립적으로 구성한다면 더욱 안정적이고 깨끗한 코드를 짤 수 있다. 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 나는 예외처리를 잘 사용하고 있는가..? null을 반환하거나 인수로 전달하는 api를 짠적이 있던가,,? 생각해봐야겠다

😃 책에서 기억하고 싶은 내용을 써보세요. 자료 추상화 클래스에 getter, setter 를 추가한다고 추상화가 이루어 지는것은 아니다. 객체가 포함하는 자료를 표현할 가장 좋은 방법을 생각해 봐야한다. 객체와 자료구조 객체는 추상화 뒤로 자료름 숨긴 채 자료를 다루는 함수만 공개한다. 자료 구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다. 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요