예외처리 방식 오류 코드를 리턴하지 말고, 예외를 던져라 (당연) 예전 에러코드로 반환하는 방식 오류가 발생한 부분에서 예외를 던진다. (별도의 예외 처리가 필요하다면 checked exception을 사용한다. 또는 throws 명시) checked exception을 사용하지 않는다면, 메서드 선언부에 throws를 명시 예외를 처리할 수 있는 곳에서 catch하여 처리 *문제점 * 특정 메서드에서 checked exception을 throw하고 상위 메서드에서 catch 한다면 모든 중간 메서드들은 throws를 해야 한다. OCP 위배 : 상위 메서드에서 하위 메서드의 디테일에 대해 알아야 한다. 필요한 경우 checked exception을 사용하지만, 일반적으로 득보다 실이 많다. Checke..

자료구조 vs 객체 자료구조 vs 객체 //자료구조 public interface Vehicle { double getFuelTankCapacityInGallons(); double getGallonsOfGasoline(); } public class Car implements Vehicle { double fuelTankCapacityInGallons; double gallonsOfGasoline; public double getFuelTankCapacityInGallons() { return this.fuelTankCapacityInGallons; } public double getGallonsOfGasoline() { return this.gallonsOfGasoline; } } 자료구조는 값을 가..

포맷팅이 중요한 이유 가독성에 필수적이다. 코드를 잘못해석해 버그를 발생할 여지를 줄인다! 클린코드 포맷팅 200라인 이하로 유지하자. 코드길이가 200라인을 넘어간다면, 클래스가 여러가지 일을 하고 있을 가능성이 높다. SRP (클래스 단일 책임 원칙) 위배! 밀접한 개념은 서로 가까이 둔다. 행 묶음은 완결된 생각 하나를 표현하기 때문에 개념은 빈 행으로 분리 변수는 사용되는 위치에서 최대한 가까이 선언한다. Java Class Declarations Class 내부 코드 순서 (static - instance - 생성자 - 메서드) static 변수 public -> protected -> private 순서 instance 변수 public -> protected -> private 순서 생성자 ..

주석을 최대한 쓰지 말자 주석은 나쁜 코드를 보완하지 못한다. 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. // 직원에게 복지 혜택을 받을 자격이 있는지 검사 if ((employee.flags & HOURLY_FLAG) && employee.age > 65) if (employee.isElligibleForFullBenefits()) 코드로도 좋은 의도를 표현할 수 있다. 주석은 방치된다. 새로운 추가 기능 및 변경사항이 생기면 주석도 수정을 해야한다. 코드는 컴파일되어 호출되지만, 주석은 그저 주석이기 때문에 결국 의미없는 텍스트가 되어버린다. 좋은 주석 // kk:mm:ss EEE, MMM dd, yyyy 형식 Pattern timeFormat = Pattern.compil..

SOLID 객체지향 설계의 5가지 원칙 SRP : 단일 책임 원칙 한 클래스는 하나의 책임만 가져야 한다. 클래스는 하나의 기능만 가지며, 어떤 변화에 의해 클래스를 변경 해야 하는 이유는 오직 하나뿐이어야 한다. SRP로 책임이 분명해지기 때문에, 변경에 의한 연쇄작용에서 자유로워 질 수 있다. 가독성 향상과 유지보수가 용이해진다. 실전에서는 쉽지 않지만 늘 상기해야 한다. OCP : 개방-폐쇄 원칙 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀있어야 한다. 변경을 위한 비용은 가능한 줄이고, 확장을 위한 비용은 극대화 한다. 요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소에는 수정이 일어나지 않고, 기존 구성 요소를 쉽게 확장해서 재사용한다. 객체지향의 추상화와 다형성을 활용한다. ..

나쁜 코드 성능이 나쁜 코드 불필요한 연산이 들어가서 개선의 여지가 있는 코드 의미가 모호한 코드 이해하기 어려운 코드, 네이밍과 그 내용이 다른 코드 중복된 코드 비슷한 내용인데 중복되는 코드들은 버그를 낳는다. 깨진 유리창 법칙 - 나쁜 코드는 유리창 처럼 계속 나쁜 코드가 만들어지도록 한다. 생산성 저하 - 나쁜 코드는 팀 생산성을 저하시킨다. 기술부채를 만들어 수정을 더 어렵게 한다. 결국 새로운 시스템을 만들어야 한다. 시간이 없다고 나쁜 코드를 사용하면, 결국 일정을 못맞춘다. 클린 코드 성능이 좋은 코드 의미가 명확한 코드 - 가독성이 좋은 코드 중복이 제거된 코드 보이스카우트 룰 : 전보다 더 깨끗한 상태로 만든다. 의미가 분명한 이름 짓기 이름을 잘 짓는 간단한 규칙 소프트웨어에서 이름은..