개발노트

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

개발할 때 비슷하게 생긴 문자들때문에 고통받으신적 없나요~? 대표적으로 구분이 필요한 문자 타입은 아래와 같이 2가지 형태가 있어요! 숫자 0, 한글의 ㅇ, 영어의 o 바코드 닉네임을 만들기에 용이한 1, i, l, | 이것들을 좀 더 명확하게 표시해주는 폰트가 있어서 소개해보려고 합니다. 바로 네이버에서 제작한 D2 Coding 글꼴 입니다 D2 Coding 글꼴 네이버 개발자 센터에서 제공하고 있으며, 나눔바른고딕을 바탕으로 개발자의 코딩을 위해 가독성과 유사 문자간 변별력을 높인 글꼴입니다. 또한, 한글과의 조화를 고려하여 최적화 시킨 글꼴로 한국인 개발자에게 최적화된 글꼴입니다. D2 Coding 글꼴은 고정폭 글꼴로 제작되어 어떤 개발환경에서도 자간과 행간을 유지하도록 디자인 되어 있습니다. 유..

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

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