전체 글 (51) 썸네일형 리스트형 단위 테스트 #8 목차 테스트 코드의 중요성 테스트의 종류 Unit Test 작성 테스트 코드의 중요성 테스트 코드는 실수를 바로 잡아준다. 테스트 코드는 반드시 존재해야하며, 실제 코드 못지 않게 중요하다. 테스트 케이스는 변경이 쉽도록 한다. 코드에 유선성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위테스트다. 테스트 케이스가 있으면 변경이 두렵지 않다. 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 테스트 커버리지가 높을수록 버그에 대한 공포가 줄어든다. 지저분한 테스트 코드는 테스트를 안하니만 못하다. 테스트는 자동화되어야 한다. 테스트를 양심껏 가끔하는 것이 아니라 매번 배포하기전에 테스트를 실행하여 잘 동작하는지 검증하여야 한다. 테스트 의 종류 Test Pyramid Unit Test : 프로그.. 모호한 경계를 구분짓기 #7 목차 경계 경계 짓기 (1) 우리 코드를 보호하기 경계 짓기 (2) 외부 코드와 호환하기 외부 라이브러리 테스트하기 - Learning Test 경계 오픈소스, 라이브러리를 안쓰는 프로젝트는 없다. 우리가 만든 코드에 외부에서 들어온 코드를 병합해야 한다. 외부 코드는 외부에서 만든 코드인데, 외부 시스템과 호출하거나 단순히 외부에서 만들어진 코드일 수 있다. 우리 코드와 외부코드를 깔끔하게 통합시키기 위해 경계를 잘 지어야 한다. 경계 짓기(1) 우리 코드를 보호하기 캡슐화(Encapsulation) 객체의 실제 구현을 외부로부터 감추는 방식 우리 코드를 보호하기 Sensor 를 관리하고 싶다. Sensor는 외부에서 사용된다. Sensor id와 Sensor 객체로 저장하고 싶어서, Map을 사용한다.. 예외 처리하기 #6 목차 예외 처리 방식 Unchecked Exception을 사용하라 Exception 잘 쓰기 실무 예외 처리 패턴 오픈소스 속 Exception 살펴보기 예외 처리 방식 오류 코드를 리턴하지 말고, 예외를 던져라 옛날에는 오류를 나타낼 때 에러코드를 던졌다. 하지만 예외를 던지는 것이 명확하고, 처리 흐름이 깔끔해진다. 오류가 발생한 부분에서 예외를 던진다. (별도의 처리가 필요한 예외라면 checked exception으로 던진다) checked exception에 대한 예외처리를 하지 않는다면 메서드 선언부에 throws를 명시해야 한다. 예외를 처리할 수 있는 곳에서 catch 하여 처리한다. Unchecked Exception을 사용하라 Checked vs Unchecked Exception E.. 객체와 자료구조 #5 목차 자료구조 vs 객체 객체 - 디미터 법칙 DTO Active Record 자료구조 vs 객체 자료구조 객체 데이터 그 자체 비즈니스 로직과 관련 자료를 공개한다. 자료를 숨기고, 추상화 한다. 자료를 다루는 함수만 공개한다. 변수 사이에 조회 함수와 설정 함수로 변수를 다룬다고 객체가 되지 않는다. 추상 인터페이스를 제공해 사용자가 구현을 모른채 자료의 핵심을 조작할 수 있다. 예시 1 //자료구조 public interface Vehicle { double getFuelTankCapacityInGallons(); // 연료탱크 용량(갤런 단위) double getGallonsOfGasoline(); // 가솔린 (갤런 단위) } public class Car implements Vehicle { .. 형식 맞추기 #4 목차 포맷팅이 중요한 이유 클린 코드 포맷팅 Java Class Declarations Team Coding Convention 포맷팅이 중요한 이유 가독성에 필수적이다. // 안좋은 포맷팅.. public void horriblyFormattedMethod() { System.out.println("First line); System.out.println("Second line); System.out.println("Third line); for (int i = 0; i < 3; i++) System.out.println("number " + i); } // 좋은 포맷팅 public void horriblyFormattedMethod() { System.out.println("First line); S.. 코드를 보조하는 주석 #3 목차 주석을 최대한 쓰지 말자 좋은 주석 주석보다 annotation JavaDoc 주석을 최대한 쓰지 말자 주석은 나쁜 코드를 보완하지 못한다. // 직원에게 복지 혜택을 받을 자격이 있는지 검사한다. if((employee.flags && HOURLY_FLAG) && employee.age > 65) // 의미있는 이름을 지으면 해결된다. if(employee.isEligibleForFullBenefits()) 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 자신이 저지른 난장판을 주석으로 설명하지 말고 개선하는데 시간을 보내야 한다. 코드로도 의도를 표현할 수 있다. 주석은 방치된다. 코드의 변화에 따라가지 못하고, 주석은 방치된다. 코드는 컴파일되어 호출되지만, 그저 주석이기.. 함수를 안전하고 간결하게 작성하기 #2 목차 SOLID 간결한 함수 작성하기 안전한 함수 작성하기 함수 리펙토링 SOLID 원칙 1. 단일 책임 원칙(Single Responsibility Principle) 2. 개방 폐쇄 원칙(Open-Closed Principle) 3. 리스코프 치환 원칙(Liskov Substitution Principle) 4. 인터페이스 분리 원칙(Interface Segregation Principle) 5. 의존 관계 역전 원칙(Dependency Inversion Principle) SRP (단일 책임 원칙) - 한 클래스는 하나의 책임만 가져야 한다. 클래스는 하나의 기능만 가지며, 어떤 변화에 의해 클래스를 변경해야 하는 이유는 하나뿐이어야 한다. SRP 책임이 분명해지기 때문에, 변경에 의한 연쇄작용에서.. 클린 코드와 그 첫걸음 네이밍 #1 목차 나쁜 코드 클린 코드 의미 있는 이름 짓기 Google Java Naming Guide 나쁜 코드 성능이 나쁜 코드 - 불필요한 연산이 들어가서 개선의 여지가 있는 코드 의미가 모호한 코드 - 이해하기 어려운 코드 네이밍과 그 내용이 다른 코드 중복된 코드 - 비슷한 내용인데 중복되는 코드들 버그를 낳는다. 나쁜 코드가 나쁜 이유 깨진 유리창 법칙 - 나쁜 코드는 유리창처럼 계속 나쁜 코드가 만들어지록 한다. 생산성 저하 - 나쁜 코드는 팀 생상선을 저하시킨다. 기술부채를 만들어 수정을 더 어렵게 한다. 새로운 시스템을 만들어야 한다. - 현시스템을 유지 보수하며 대체할 새로운 시스템 개발은 현실적으로 매우 어렵다. 나쁜 코드를 짜는 이유 일정이 촉박해서 일정 안에 새로운 기능을 완성해야 한다. 하.. 이전 1 2 3 4 5 6 7 다음
