개발노트

목차 8장 경계 외부 코드 사용하기 경계 살피고 익히기 학습 테스트는 공짜 이상이다 아직 존재하지 않는 코드를 사용하기 깨끗한 경계 Intro 시스템에 들어가는 모든 소프트웨어를 "직접" 개발하는 경우는 드물다. 패키지를 사거나, 오픈소스를 이용하거나, 다른 팀이 제공하는 컴포넌트를 사용한다. 어떤 식으로든 이러한 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다. 이 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교에 대해 알아보자. 소프트웨어 경계에 대해 이해가 되었는가??? 이 장에서 말하는 경계는 "외부코드" 또는 "외부 라이브러리", "외부 API" 를 의미하는 듯 하다. 외부 코드 사용하기 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의하자..

목차10장 클래스 클래스 체계 캡슐화 클래스는 작아야 한다! 단일 책임 원칙 응집도 Cohesion 응집도를 유지하면 작은 클래스 여럿이 나온다 변경하기 쉬운 클래스 변경으로부터 거리 Intro이전 챕터에서는 코드, 코드 블록, 함수 구현 방법과 함수 간의 관련 맺는 방식을 공부했다. 하지만 좀 더 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기 어렵다. 그러니 클래스에 대해 자세히 알아두자. 클래스 체계클래스는 아래와 같은 순서로 코드를 작성하자. 1) static 변수 : public → protected → package → private 2) instance 변수 : public → protected → package → private 3) 생성자 4) 메서드 : (public → privat..

목차 7장 오류 처리 오류 코드보다 예외를 사용하라 Try-Catch-Finally 문부터 작성하라 미확인(Unchecked) 예외를 사용하라 예외에 의미를 제공하라 호출자를 고려해 예외 클래스를 정의하라 정상 흐름을 정의하라 null을 반환하지 마라 null을 전달하지 마라 결론 Intro 깨끗한 코드와 오류 처리는 확실히 연관성이 있다. 여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기 어려워진다면 깨끗한 코드라 부르기 어렵다. 따라서 깨끗한 코드에 한 걸음 다가가는 오류 처리 기법과 고려 사항에 대해 알아둘 필요가 있다. 오류 코드보다 예외를 사용하라 오류가 발생하면 예외를 던지는 편이 낫다. 그러면 논리가 오류 처리 코드와 뒤섞이지 않기 때문에 호출자 코드가 더 깔끔해진다. ..

목차 6장 객체와 자료 구조 자료 추상화 자료/객체 비대칭 디미터 법칙 자료 전달 객체 결론 객체는 자료를 숨기고 동작을 공개하며, 자료 구조는 자료를 공개한다. Intro 변수를 private(비공개)로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다. 변수 타입이나 구현을 맘대로 바꾸고 싶어서다. 그렇다면 어째서 수많은 프로그래머가 조회(get)함수와 설정(set)함수를 당연하게 public(공개)으로 선언해서 외부에 노출하는 걸까? 자료 추상화 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다. 인터페이스나 get/set 함수만으로는 추상화가 이뤄지지 않는다. 아래 2개의 클래스는 모두 2차원 점을 표현하였다. 목록 6-1) 구체적인 클래스 - 구현을 외부로 노..

목차 4장 주석 주석은 나쁜 코드를 보완하지 못한다 코드로 의도를 표현하라 좋은 주석 법적인 주석 정보를 제공하는 주석 의미를 설명하는 주석 의미를 명료하게 밝히는 주석 결과를 경고하는 주석 TODO 주석 중요성을 강조하는 주석 공개 API에서 Javadocs 나쁜 주석 주절거리는 주석 같은 이야기를 중복하는 주석 오해할 여지가 있는 주석 의무적으로 다는 주석 이력을 기록하는 주석 있으나 마나 한 주석 무서운 잡음 함수나 변수로 표현할 수 있다면 주석을 달지 마라 위치를 표시하는 주석 닫는 괄호에 다는 주석 공로를 돌리거나 저자를 표시하는 주석 주석으로 처리한 코드 HTML주석 전역 정보 너무 많은 정보 모호한 관계 함수 헤더 비공개 코드에서 Javadocs 나쁜 코드에 주석을 달지 마라. 새로 짜라. ..

목차 3장 함수 작게 만들어라! 한 가지만 해라! 함수 당 추상화 수준은 하나로! Switch 문 서술적인 이름을 사용하라! 함수 인수는 최대한 작게! 부수 효과를 일으키지 마라! 명령과 조회를 분리하라! 오류 코드보다 예외를 사용하라! 반복하지 마라! 구조적 프로그래밍 함수를 어떻게 짜죠? 어떤 프로그램이든 기본적인 단위가 함수다. 작게 만들어라! 함수를 만들 때 최대한 '작게' 만들어라 public static String renderPageWithSetupsAndTeardowns(PageData pageData, boolean isSuite) throws Exception{ boolen isTestPage = pageData.hasAttribute("Test"); if(isTestPage){ Wik..

리팩토링 외부 동작은 변경하지 않고, 내부 구조를 변경하는 작업이다. 따라서, 버그 수정/기능 추가는 리팩토링에 포함되지 않는다. 왜냐? 결과가 바뀌니깐! 그리고 기능을 추가하기 전에, 리팩토링을 먼저 하자. 가독성 향상과 유지보수가 용이해지기 때문에 기능 추가가 훨씬 수월하다. 프로젝트 초기 아키텍트 설계가 완벽하더라도, 기능 추가와 버그 수정들이 있다면 설계는 점차 무너지게 된다. 따라서 리팩토링은 지속적으로 필요하다. 리팩토링은 개발자의 관점에 따라 주관적이다. 자신의 논리적 판단을 근거로 코드를 수정하는 작업이기 때문이다. 리팩토링의 목적 소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만드는 것(→ 가독성이 좋은 클린한 코드 짜기)이다. 이는 개발 속도를 빠르게 해준다. 리팩토링은 성능을 최적화시키..

1. Clean Code 가 뭔데? Clean code 깨끗한 코드라는 것은, (작성자 뿐만 아니라 이외 사람들이) 읽고 고치기 쉬운 코드이다. 추가로, 한 가지에 집중되어 있으며 테스트 케이스가 있는 코드를 말한다. 2. Clean Code 왜 필요하지? Clean Code 는 빠른 유지보수가 가능하다. Software 개발에서는 처음 개발하는 것보다 유지보수 업무가 훨씬 많다. 따라서 유지보수 하기 쉽게 만드는 것이 중요하며, Clean Code 를 통해 가능하다. "Clean Code" 가 만들어진건 어쩌면 많은 소스코드들이 깨끗하지 않기 때문에 나타난 용어이지 않을까? 그러면 소스들이 더러워진 이유는 뭘까? 소스가 더러워지는 가장 큰 이유는 바로 기한이다. 기한을 맞추기 위해 나쁜 코드를 작성하게..