노개북

🔖 오늘 읽은 범위 : 추천사 & 들어가면서사소한 곳에서 발휘하는 정직은 사소하지 않다. 중요하다.소프트웨어 설계에서 재작업은 가치를 가져온다.심지어 자동차 업계도 대다수 활동을 제조가 아니라 유지보수다.TotalProductiveManagement → Lean →

🔖 오늘 읽은 범위 : 1장. 깨끗한 코드 p.1 ~ p8코드는 요구사항을 상세히 표현하는 수단추상화 수준은 점차 높아지지만 그것 역시 코드이다나쁜 코드를 헤쳐나가는 고행wading 을 겪고 미루지 말라 르블랑의 법칙 → 나중은 결코 오지않는다. 나쁜 코드가 쌓일

🔖 오늘 읽은 범위 : 1. 깨끗한 코드 8p ~ 20p우아하고 효율적인 코드의존성을 최대한 줄여 한 가지를 제대로 하는 코드창문이 한번 깨지고 나면 쇠퇴가 시작되버림잘 쓴 문장처럼 읽히는 코드 → 명쾌한 추상화작성자가 아닌 사람도 읽고 고치기 쉽다 → TDD코드만으

🔖 오늘 읽은 범위 : 2장 의미 있는 이름 (22~31p)좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.따로 주석이 필요하다면 의도를 분명히 드러내지 못한 것변수의 존재 이유는?수행 기능은?사용 방법은?자신에게만 편한 약어 ❌ty

🔖 오늘 읽은 범위 : 2장 의미 있는 이름 (31~38p)작은 루프에서 변수 i, j, k는 🙆‍♂️, l 은 절대 ❌똑똑한 프로그래머는 똑똑함을 자랑하고 싶어하지만 전문가 프로그래머는 명료함이 최고임을 안다명사, 명사구 사용: Customer, WikiPage,

🔖 오늘 읽은 범위 : 3. 함수 (40~54p)함수는 프로그래밍의 가장 기본적인 단위if문/else문/while문 등에 들어가는 블록은 한줄이어야 한다.함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다. 1단에서 바로 함수 호출한가지: 지정된 함수 이름 아

🔖 오늘 읽은 범위 : 3. 함수 (54~65p)함수에서 한 가지 하기로 약속해놓고 몰래 다른 부수 효과를 일으키지마라시간적인 결합 이나 순서 종속성을 초래한다Session.initialize() 는 의도치 않게 세션 정보를 지워버린다→ 적어도 이름을 checkPas

🔖 오늘 읽은 범위 : 4.주석(68~75p)실패를 만회하기 위해 주석을 사용한다 → 정말 코드로 의도를 표현할 방법이 더 없나 고민주석을 유지보수하는것은 불가능 → 오래될 수록 코드에서 멀어진다 나중에 추가된 인스턴스 변수들이 주석을 원본 코드에서 멀어지게 했을듯

🔖 오늘 읽은 범위 : 4장 주석 (75~94p)이유없이 의무감이나 업무 표준때문에 마지못해 주석을 단다면 시간 낭비 주석을 달기로 결정했다면 최고의 주석을 달아라 이해가 안 되어 다른 모듈까지 뒤져야 하는 주석은 낭비 코드의 내용을 반복하거나 덜 언급하는 주석

🔖 오늘 읽은 범위 : 5. 형식 맞추기 (96~116p)돌아가는 코드 vs 형식을 맞춘 코드 오늘 구현한 기능은 다음 버전에서 바뀔 확률은 아주 높다. 오늘 구현한 코드의 구현 스타일과 가독성은 유지보수 용이성과 확장성에 계속 영향을 미친다. 세로 길이 50

🔖 오늘 읽은 범위 : Mission중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기 → 진짜 문제에 신경 쓸 여유 생김추상적인 개념 하나에는 일관된 단어를 선택해 고수하라IDE의 자동완성을 생각해서라도 불필요한 접두사 다 붙이지말자함수에서 들여쓰기 수준

🔖 오늘 읽은 범위 : 6. 객체와 자료구조(118~128p)변수를 비공개(private)로 정의 → 외부에 의존성이 없게 하면 맘대로 바꿀수 있다왜 get, set 은 항상 public 일까?자료를 세세하게 공개하기 보다는 추상적인 개념으로 표현하는 편이 좋다직교좌

🔖 오늘 읽은 범위 : 7. 오류처리 (130~137p)예외처리가 아닌 오류 코드반환 방식을 쓰면 함수를 호출한 즉시 오류를 확인해야한다오류가 발생하면 예외를 던져라 → 호출자 코드가 깔끔해지고 논리와 오류처리가 뒤섞이지 않음try 블록은 트랜잭션과 비슷try 블록에

🔖 오늘 읽은 범위 : 7. 오류처리 (137~142p)논리와 오류 구분은 좋지만 오류 감지가 프로그램 언저리로 밀려날 수 있다.기본 값을 리턴함으로서 불필요한 중단을 제거하는 예제 특수상황을 처리할 필요가 없으면 더 좋겠다 위와 같이 기본값을 반환하면 중단할 필

🔖 오늘 읽은 범위 : 9. 단위테스트(154~164p)실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.법칙을 따

🔖 오늘 읽은 범위 : 9. 단위테스트(164~168p)함수마다 assert문을 단 하나만 사용해야한다 → 결론이 하나이므로 코드를 이해하기 쉽고 빠르다결론이 두 개 이상이면? → 테스트를 두개로 쪼갠다단 테스트를 분리하면 중복되는 코드가 많아진다Template Me

🔖 오늘 읽은 범위 : 10. 클래스 (172~185p)신문 기사처럼 읽히는 순차적 추상화 단계public static variableprivate static variableprivate instance variablepublic instance variable (

🔖 오늘 읽은 범위 : 10. 클래스 (185~191p)SELECT 만 지원하다가 UPDATE 문이 필요하면 클래스를 변경해야한다 → SRP위반public 인터페이스를 Sql 클래스에서 파생하는 클래스로 분리valuList와 같은 private 메서드는 해당 파생 클

🔖 오늘 읽은 범위 : Final mission우리는 코드의 저자다. 독자와 잘 소통할 수 있는 깨끗한 코드를 쓸 책임이 있다코드를 읽기 쉽게 만들면 짜기도 쉽다중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기 → 진짜 문제에 신경 쓸 여유 생김좋은 이름

🔖 오늘 읽은 범위 : 8. 경계(143~152p)인터페이스 제공자: 더 많은 환경에 대한 적용성 넓히려 애씀인터페이스 사용자: 자신의 요구에 집중하는 인터페이스 만들기를 바람Map 이 반환하는 Object를 올바른 유형으로 변환할 책임은 사용하는 클라이언트에 있다G

🔖 오늘 읽은 범위 : 11. 시스템(194~205p)도시에는 큰 그림을 그리는 사람들도 있고 작은 사항에 집중하는 사람들도 있다적절한 추상화와 모듈화 → 큰 그림은 이해하지 못해도 개인이 관리하는 구성요소는 효율적으로 돌아간다깨끗한 코드 → 낮은 추상화 수준에서 관

🔖 오늘 읽은 범위 : 11. 시스템(205~214p)순수 자바 관점 구현하는 스프링 AOP, JBoss AOP 같은 프레임워크는 내부적으로 프록시 사용스프링은 비즈니스 논리를 POJO로 구현도메인에 초점을 맞춤엔터프라이즈 프레임워크에 의존하지 않음테스트가 쉽고 간단

🔖 오늘 읽은 범위 : 12. 창발성(216~223p)설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다SRP를 준수하는 클래스는 테스트가 훨씬 더 쉽다DIP, DI, 인터페이스, 추상화 를 사용해 결합도를 낮춰야 테스트가 쉽다테스트 케이스가 있으니까 코드를 정리비슷

🔖 오늘 읽은 범위 : 13. 동시성(226~235p)동시성은 coupling(결합) 을 없애는 전략what 과 when을 분리하는 전략서블릿 웹 혹은 EJB 컨테이너라는 우산안의 컨테이너는 동시성을 부분적으로 관리웹 요청시마다 비동기식으로 서블릿을 실행특정 시스템은

🔖 오늘 읽은 범위 : 13. 동시성(235~244p)공유 객체 하나에는 메서드 하나만 사용해야 한다클라이언트에서 잠금: 첫 번째 메서드를 호출하기 전에 서버를 잠근다. 마지막 메서드 호출시까지 잠금을 유지서버에서 잠금: 서버를 잠그고 모든 메서드를 호출한 후 잠금을

🔖 오늘 읽은 범위 : 14. 점진적인 개선(246~270p)Args 생성자에 인수 문자열과 형식 문자열을 넘겨 Args 인스턴스를 생성한 후 Args 인스턴스에 인수 값을 질의프로그래밍은 과학보다 공예에 가깝다 → 초안부터 작성하고 정리하자리팩토링을 위해 인수를 추

🔖 오늘 읽은 범위 : 14. 점진적인 개선(270~295p)한 번에 하나씩 고치면서 테스트 수행, 하나라도 실패할시 수정 후 진행각 인수 유형을 처리하는 코드를 모두 ArgumentMarchaler 클래스에 넣고 나서 ArgumentMarshaler 파생 클래스를

🔖 오늘 읽은 범위 : 14. 점진적인 개선(295~320p)큰목표 하나를 이루기 위해 자잘한 단계를 수없이 거친다.각 단계를 거쳐야 다음 단계가 가능하다.새 인수 유형을 제대로 받아들이는지 확인할 테스트 추가스키마 구문분석 코드 정리해당 유형에 대한 감지 코드 추가

🔖 오늘 읽은 범위 : 14. 점진적인 개선(321p)단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다아침에 엉망으로 짠 코드를 오후에 정리하는건 어렵지않고 5분전에 엉망으로 짠 코드는 더 정리가 쉽다코드는 언제나 최대한 깔끔하고 단순하게 정리하자

🔖 오늘 읽은 범위 : 15. JUnit 들여다보기(324~334p)테스트 프레임워크로 가장 유명한 JUnit의 실제 내부 코드를 가져와 평가해보자보이스카우트 규칙에 따라 처음 왔을때 보다 더 깨끗하게 해놓고 떠나야 한다멤버 변수 앞에 붙인 접두어 f → 모두 제거오

🔖 오늘 읽은 범위 : 15. JUnit 들여다보기(334~342p)findCommonSuffix 에는 숨겨진 시간적인 결합이 존재findCommandSuffix는 findCommonPrefix가 prefixIndex를 계산한다는 사실에 의존하므로 잘못된 순서로 호출