개발노트

목차 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..

Unit Test (단위 테스트) 단위 테스트는 프로그램의 기본 단위가 되는 모듈을 테스트하는 것이다. 모듈 테스트라고도 한다. 개발자가 개발한 모듈이 의도대로 동작하는지를 테스트한다. TDD 싸이클을 기반하여 테스트하게되면, 모듈 내의 데이터 흐름에 대한 예외 케이스를 작성(Red)하고, 이를 통과하도록 모듈을 개발(Green) 한다. 이때, 가짜 객체(Mock object)를 사용하여 테스트를 진행할 수 있다. 웹의 백엔드에서 단위테스트를 진행하는 레이어는 service, controller 이며, 각각 내부 기능들에 대해 단위 테스트를 진행한다. Repository 레이어는 보통 통합 테스트 대상이다. TDD (Test Driven Development) TDD 란 Test Driven Develo..

Robert C. Martin's Software design principles(SOLID) Robejt C. Martin은 5가지 Software design principles을 정의하였고 앞글자를 따서 SOLID라고 부른다. SRP Single Responsibility Principle : 하나의 클래스는 하나의 책임만 한다 OCP Open-Closed Principle : 클래스는 확장엔 열려있고 변경에는 닫혀있다 LSP Liskov Substitution Principle : 부모가 하는 동작은 자식도 다 할 수 있어야 함. 부모의 역할을 자식이 대체 가능 (기반 클래스의 메소드는 파생 클래스 객체의 상세를 알지 않고서도 사용될 수 있어야 한다.) ISP Interface Segregatio..