내 코드가 그렇게 이상한가요

설계를 소홀히 했을 때 폐해가 발생함코드 읽고 이해하는데 오랜 시간 걸림꼬리에 꼬리 무는 버그더 나쁜 구조 발생지양할 방법 → 코드에서 어떠한 의도도 읽을 수 없음기술 중심 명명일련번호 명명지향할 방법의도, 목적 정확히 드러내는 이름 사용중첩 if 문을 사용하는 경우를

자주 바뀔 가능성이 있는 코드를 구현할 때는 변수 이름을 쉽게 붙이는 것도 좋은 기본 설계의도를 쉽게 알 수 있는 이름 붙이기재할당은 변수의 용도가 바뀌는 문제 일으킴가독성 떡락버그 양산 가능성 떡상어떤 값을 계산하는데 어떤 값을 사용하는지 명확히!위 관계가 이름만 보

OOP = 클래스 기반 프로그래밍클래스 기반클래스 = 데이터 + 데이터 조작 논리프로그램 = 클래스 + 클래스클래스 설계가 잘 되면 유지보수, 변경이 쉬운 코드 작성 가능클래스 단위로도 잘 동작하게 설계해야 한다초기설정을 따로 하지 않아도 곧바로 사용할 수 있도록 만들

상태 변경할 수 있는 거상태 변경 불가한 거요즘 프로그래밍 스타일 트랜드변수에 값을 다시 할당하는 거변수 재활용 하지 않고, 새로운 변수를 만들어 회피 가능인스턴스 변수에 final 붙이기 → 불변매개변수에 final 붙이기 → 불변한쪽 변경이 재사용하는 다른쪽에 영향

모듈 내부에 있는 데이터와 로직 사이 관계가 얼마나 강한지 나타내는 지표응집도가 높을 수록 구조 변경, 유지보수 편리static 메소드는 객체 생성하지 않고 사용 가능데이터와 사용 로직이 멀리 떨어지게 될 가능성 존재인스턴스 변수 사용이 불가하기 때문에 근본적으로 응집

조건문을 중첩하면가독성 떡락사양 변경 어렵early return으로 중첩 제거간단하게 기능추가 가능가드도 early Return 중 하나요구사항을 그대로 구현한 형태가 가능해짐else 구문 지양조기 리턴 사용하면 제거 가능switch 문은 악마 콜렉터대게 비슷한 형태의

바퀴 재창조 하지마셈컬렉션을 반복문으로 처리하면, 조건 중첩이 발생하기 쉬움스트림 같은 선언형 프로그래밍으로 같은 기능을 가독성 있게 구현 가능반복문, 조건문 없어도 같은 기능 구현위 구문으로 인해 발생하는 버그도 줄어듬 → 선언형이므로조기 continue특정 조건하에

모듈(클래스, 패키지, etc) 사이 의존도를 나타내는 지표강한 결합어떤 클래스가 다른 클래스에 많이 의존하고 있는 구조느슨한 결합자신이 해야 하는 일하지 않으면 안 되는 임무클래스가 담당하는 책임은 하나로 제한해야 한다.소프트웨어 책임자신의 관심사와 관련해서 정상적으

악마 설명절대로 실행되지 않는 조건 내부에 있는 코드악마 사유가독성 떡락사양변경 시 버그 유발퇴치법발견 즉시 제거 요망IDE의 정적 분석 도구가 데드코드 보면 기함을 토함그거보고 고치면 됨.천사 설명지금 필요 없는 기능을 만들지 말라천사 사유예측에 들어맞지 않는 로직

이름을 대충 붙이면, 책무 얽힘 → 강한 결합 → 클래스 거대 → 갓 클래스비즈니스 목적이 중요한 역할하므로, 목적 중심 이름 설계가 유효그냥 ‘상품’ 클래스는 갓 클래스 될 가능성 있음관심사(유스케이스, 목적, 역할)에 따라서 분리상품 클래스는 관심사에 따라 (예약상

주석은 코드 이해하는 데 도움 주는 도구다만, 대충 작성하면 버그 원인이 되는 잠재적 악마주석과 구현 시점이 멀어지면 → 주석이 거짓말 할 가능성 높아짐구현 변경 시 주석도 함께 변경해야 함최대한 의도가 제대로 전달될 수 있도록 해야 함클래스, 메소드 이름 신경써서 짓

메소드 설계는 클래스 설계와 아주 밀접한 관련인스턴스 변수 안전하게 조작하도록 메소드 설계 → 클래스 내부 정상적 상태 보장 가능반드시 현재 클래스의 인스턴스 변수 사용토록 설계완전 생성자 패턴(가드 in 생성자)다른 클래스의 인스턴스 변수를 변경하고 싶다면새로운 인스

설계 청사진사물 특징, 관계 그림으로 나타낸 것시스템 구조 설명특정 목적 달성 위해 최소한으로 필요한 요소를 갖춘 것모델 만드는 활동모델링 하지 않으면, 변경하기 어렵고 악마 불러들이는 코드 작성모델링을 제대로 하지 않은 User 클래스는 버그를 한 움큼 머금은 악마

리팩토링실질적 동작 유지하면서 구조만 정리하는 작업실질적 동작이 바뀐다면 리팩토링 아님.실질적 동작 변하지 않았음을 단위 테스트를 통해 확인ㄴ여러가지 리팩토링 사항중첩 제거조기 리턴, 조기 예외의미 단위로 로직 정리생성자 가드 부분, 바인딩 부분 분리조건 읽기 쉽게 하

소프트웨어 설계소프트웨어의 품질특성을 향상시키기 위한 구조를 만드는 것유지보수성시스템이 정상 운용되도록 유지보수하기 얼마나 쉬운가를 나타내는 정도수정성 (변경용이성)버그를 발생시키지 않고 얼마나 쉽고 정확하게 코드를 변경할 수 있는 나타내는 정도레거시 코드변경하기 어렵

커뮤니케이션 부족하면 설계 품질에 문제 발생커뮤니케이션 문제 생기면 버그가 많아지는 경향콘웨이 법칙시스템 구조는 조직을 닮아 간다시스템 구조가 팀 단위(릴리즈 단위) 처럼 구성역콘웨이 법칙이란게 있으나, 유명무실심리적 안정성어떤 발언을 했을때, 부끄럽거나 거절당하지 않