#1. [개체지향 원칙] 5대 원칙(SOLID)
좋은 설계는 유지보수의 편의성을 위하여
24개의 개발 원칙
#2. [개체지향 원칙] 단일 책임 원칙(Single Responsibility Principle)
단일 책임 원칙은 개체는 단 하나의 책임만 가져야 한다 는 원칙입니다.
#3. [개체지향 원칙] 개방-폐쇄 원칙(Open-Closed Principle)
개방-폐쇄 원칙은 확장에는 열려 있되, 수정에는 닫혀 있게 작성하라 라는 원칙입니다.
#4. [개체지향 원칙] 리스코프 치환 원칙(Liskov Substitution Principle)
리스코프 치환 원칙은 자식 개체는 부모 개체를 완전하게 치환할 수 있어야 한다 는 원칙입니다.
#5. [개체지향 원칙] 인터페이스 분리 원칙(Interface Segregation Principle)
인터페이스 분리 원칙은 클라이언트는 자신이 사용하지 않는 것에 강제로 의존하지 말아야 한다 는 원칙입니다.
#6. [개체지향 원칙] 의존성 역전 원칙(Dependency Inversion Principle)
의존성 역전 원칙은 상위 수준 모듈은 하위 수준 모듈에 의존하지 말아야 한다 는 원칙입니다.
#7. [개체지향 원칙] 캡슐화(Encapsulation)
캡슐화는 개체 사용자가 개체의 내부 상태의 구현 원리를 알 필요가 없게 하라 라는 원칙입니다.
#8. [개체지향 원칙] 명시적 의존성 원칙(Explicit Dependencies Principle)
명시적 의존성 원칙은 개체나 함수는 제대로 작동하는데 필요한 요소를 명시적으로 요청하라 라는 원칙입니다.
#9. [개체지향 원칙] 묻지 말고 말하라 원칙(Tell, Don’t Ask Principle)
묻지 말고 말하라 원칙은 개체의 내부 정보를 자꾸 묻지 말고 그냥 원하는 작업을 시켜라 라는 원칙입니다.
#10. [개체지향 원칙] 헐리우드 원칙(Hollywood Principle)
헐리우드 원칙은 헐리우드 영화 제작사가 오디션 배우에게 전화하지 마세요. 연락처 주시면 우리가 전화드릴께요. 라고 안내한 말에서 유래된 원칙입니다.
#11. [개체지향 원칙] 제어의 역전 원칙(Inversion of Control Principle)
제어의 역전 원칙은 외부 라이브러리의 제어를 따르라 라는 원칙입니다.
#12. [개체지향 원칙] 관심사의 분리 원칙(Separation of Concerns Principle)
관심사의 분리 원칙은 구별되는 부분들로 분리시켜라 라는 원칙입니다.
#13. [개체지향 원칙] 안정적인 의존성(Stable Dependencies Principle)
안정적인 의존성 원칙은 패키지 간의 의존성은 안정성의 방향이어야 한다 라는 원칙입니다.
#14. [개발 원칙] 아키텍처 민첩성 원칙(Architectural Agility Principle)
아키텍처 민첩성 원칙은 요구사항 변화에 적응할 수 있도록 아키텍처를 설계하라 는 원칙입니다.
#15. [개발 원칙] 보이 스카우트 규칙(Boy Scout Rule)
보이 스카우트 규칙은 캠핑장은 처음 왔을 때보다 더 깨끗하게 하고 떠나라 라는 원칙입니다.
#16. [개발 원칙] 단순하게 유지하라(Keep It Simple)
단순하게 유지하라는 원칙은 흔히 KISS(Keep It Simple, Stupid) 라고도 불립니다.
#17. [개발 원칙] 필요할때 구현하라(You Aren’t Gonna Need It)
필요할때 구현하라는 항상 실제로 필요할때 구현해야 하며, 나중에 필요하다고 예상하고 미리 구현하지 마라 라는 원칙입니다.(앞글자를 따서 YAGNI 라고도 합니다.)
#18. [개발 원칙] 스스로 반복하지 마라(Don’t Repeat Yourself)
스스로 반복하지 마라 원칙은 추상화를 통해 논리의 중복을 제거하라 라는 원칙입니다. 흔히 DRY 라고도 불립니다.
#19. [개발 원칙] 한번 단 한번만(Once and Only Once)
한번 단 한번만 원칙은 “스스로 반복하지 마라” 와 같이 반복하지 말라는 원칙입니다.
#20. [개발 원칙] 불완전성의 허용(Tolerance for Imperfection)
불완전성의 허용은 아키텍처는 완전할 수 없으니 다양한 문제에 균형을 유지하라 라는 원칙입니다.
#21. [개발 원칙] 최소한의 놀라움 원칙(Principle of Least Astonishment)
최소한의 놀라움 원칙은 사용자나 동료가 예측 가능하게 하라 라는 원칙입니다.
#23. [개발 원칙] 좋은 개발 관행
[좋은 코드] 집단 코드 소유권(Collective Code Ownership)
#24. [개발 원칙] 나쁜 개발 관행
[나쁜 코딩 관행] 코드 냄새(Code Smells)