성능이 나쁜 코드불필요한 연산이 들어가서 개선의 여지가 있는 코드의미가 모호한 코드이해하기 어려운 코드네이밍과 그 내용이 다른 코드중복된 코드비슷한 내용인데 중복되는 코드들은 버그를 낳는다.일정이 촉박해서 (일정 안에 새로운 기능을 완성해야한다.)영향 범위가 넓어서 (
SRP (단일 책임 원칙)OCP (개방 - 폐쇄 원칙)LSP (리스코프 치환 원칙)ISP (인터페이스 분리 원칙)DIP (의존성 역전 원칙) 하위 모델의 변경이 상위 모듈의 변경을 요구하는 위계관계를 끊는다. 실제 사용관계는 그대로이지만, 추상화를 매개로 메세
01. 주석을 최대한 쓰지 말자 주석을 최대한 쓰지 말자 주석은 나쁜 코드를 보완하지 못한다. 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 자신이 저지른 난장판을 주석으로 설명하지 말고 개선하는데 시간을 보내야 한다. 코드로
01. 포맷팅이 중요한 이유 가독성에 필수적이다 코드를 수월하게 읽어나갈 수 있다. 아마추어처럼 보이지 않는다. 포맷팅으로 인해 코드를 잘못해석해 버그를 발생할 위험을 줄인다. 02. 클린코드 포맷팅 200라인 코드 길이를 200줄 정도로 제한하는
객체가 row를 담을 뿐 아니라 database에 대한 접근을 포함한다.Person의 속성을 담을 뿐 아니라, 생성수정도 객체 안에서 수행할 수 있다. row를 담는 객체와 database에 접근할 수 있는 객체가 분리되어 있다.Person은 값만 담고 있고, 생성,
01. 예외 처리 방식 02. Unckecked Exception 사용 03. Exception 잘 쓰기 04. 실무 예외 처리 패턴 05. 오픈소스 속 Exception 살펴보기
오픈소스, 라이브러리를 안 쓰는 프로젝트는 없다.우리가 만든 코드에 외부에서 들어온 코드를 병합해야 한다.외부 코드는 외부에서 만든 코드인데, 외부 시스템과 호출하거나 단순히 외부에서 만들어진 코드일 수 있다.우리 코드와 일부 코드를 깔끔하게 통합시키기 위해 경계를 잘
프로그램 내부의 개별 컴포넌트의 동작을 테스트한다. 배포하기 전에 자동으로 실행되도록 많이 사용한다.프로그램 내부의 개별 컴포넌트들을 합쳐서 동작을 테스트 한다. Unit Test는 각 컴포넌트를 고립시켜 테스트 하기 때문에 컴포넌트의 interaction을 확인하는
클래스를 개발할 때 기본적으로 구현을 감추고, 외부 객체와 상호작용하는 부분만 노출외부의 잘못된 사용 방지자잘한 단일 클래스가 많아지면 큰 그림을 이해하기 어렵다고 우려.하지만 작은 클래스가 많은 시스템이든 큰 클래스가 몇 개뿐인 시스템이든 돌아가는 부품은 그 수가 비
소프트웨어 시스템은 준비 과정과 런타임 로직을 분리객체의 생성과 객체를 사용하는 부분은 분리시작 단계는 모든 어플리케이션이 풀어야할 관심사main 함수에서 시스템에 필요한 객체를 생성한 후 어플리케이션에 넘긴다.어플리케이션은 그저 만들어진 객체를 사용한다.모든 객체가
00. 창발적 설계란 창발성 (Emergence) 하위 계층에는 없는 특성이나 행동이 상위 계층(전체구조)에서 자발적으로 돌연히 출연하는 현상 > 각각의 개미는 집을 지을 능력이 없지만, 작은 개미들의 상호작용을 통해 집이라는 결과물이 나오는 것 처럼 작은 요소들의 상호작용의 반복이 전체구조에 영향을 미친다. 창발적 설계 모든 테스트를 실행한다. 중복...
어플리케이션을 효율적으로 실행하기 위해 멀티코어를 온전히 활용하도록 구현하는 방식(외부 서비스의 응답을 기다리면서 아무일도 하지 않으면 CPU 사이클이 낭비된다.)
repository 이름과 README.ml를 보고 프로젝트의 성격 파악패키지 구조를 살펴본다(멀티 모듈인지)build.gradle을 보고 어떤 디펜던시를 쓰는 지 살펴본다.config 패키지 하위에 어떤 설정들이 되어있나 본다.controller 패키지 하위 코드를