프로그래밍 관련 원칙
Law of Demeter(디미터 법칙)
최소지식의 법칙: 알지 못하는 객체에게 말을 걸지 말아라. 알지 못하는 객체란 객체자신, 객체의 메소드가 파라미터로 전달받은 객체, 객체의 메소드안에 안스턴스화된 객체,
어떤 클래스의 멤버(메소드, 속성)는 반드시 다음과 같은 객체들의 멤버들만을 실행시켜야 한다.
- 해당 메소드 또는 속성이 선언된 객체
- 메소드의 파라미터로 보내진 객체
- 메소드 또는 속성이 직접 초기화시킨 객체
- 호출을 위한 메소드 또는 속성으로서 같은 클라스 안에서 선언된 객체
- 전역 객체
//법칙위반
console.log(aStudent.class.grade)
//법칙준수
console.log(aStudent.getGrade())
데메테르 법칙을 위반하면 프로그램의 규모가 커질수록 클래스간 필요없는 의존관계가 많아지고 클래스간의 관계가 복잡해진다 그렇게 될수록 사양변경이 발생했을 경우 수정범위가 커지는등 유지보수가 어려워지며 예상치못한 버그가 발생하는 원인이 되기도한다.
콘웨이의 법칙
“모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다.”
이 법칙이 주장하는것은 작업의 효울성을 높이기 위해서는 유연한 조직구조가 필요하다는 것이다.
과거 본인이 경험한 프로젝트는 아래와 같은 조직구조였고 고비용, 저효율에 엄청난수의 버그로 릴리즈가 지연되는 일이 자주 발생하였다
End User → 영업사원 → 개발팀장 → 개발팀원 → 외주개발사 → 외주개발사의 하청개발사
실제 조사에서도 조직구조가 버그발생에 영향을 끼친다는 결과가 존재한다.
보이스카웃 법칙
“언제나 처음 왔을 때보다 깨끗하게 해놓고 캠프장을 떠날 것”
프로그램 소스를 리포지토리에 커밋할때에는 커밋하기전보다 좋은상태로 만들어야한다는 의미이다.
버그수정이나 사양변경등에 의해 코드를 수정해야 할 경우 단지 그 태스크만을 완료하기위해 주변기능에 끼치는 영향 등을 고려하지않고 수정 하는 개발자가 많이있다.그럴경우 관련이 없다고 생각한 다른기능에서 degrade가 발생하는 경우가 생긴다.
이렇듯 개발이 계속될수록 코드가 엉망이되고 지저분해지는 경우의 발생을 막기위해 딤원의 개발자 모두가 협력하여 팀의 코드를 좋은상태로 유지해야하는 마음가짐이 중요하다.
YAGNI
“You ain’t gonna need it”
지금 당장 필요하지 않은 코드는 작성하지 말라라는 의미이다.
테스트 주도 개발시에는 테스트 되지않은 코드가 없게끔해야하며 그러기 위해서는 사용되지앟는 코드를 앞으로 사용 할 가능성이 있다는 이유로 작성해서는 안된다.
DRY
“Don’t Repeat Yourself”
같은일을 반복하지 말아라라는 의미이다.(중복을 허용하지 말아라)
이 원칙이 잘 적용되면 어떠한 요소에 대한 변경도 논리적으로 관계없는 다른요소가 변경되는등의 영향은 발생하지않는다.
대규모 프로젝트는 각자 담당하는 모듈을 개발한 후 나중에 결합하는 과정을 거치게 되는데 이 과정에서 같은기능의 중복이 발생하며 유지보수가 힘들어지게된다.
개발 단계에서부터 공통 컴포넌트를 작성하여 사전에 중복개발을 방지하는등의 노력이 필요하다.
KISS
“Keep it simple, stupid”
단순하게 하라라는 의미이다.
위대한 연설가들이 공통적으로 지킨 원칙 중의 하나가 바로 KISS 의 법칙에 입각한 스피치였다는 것인데, 진부하거나 과장되고 ,현학적인 표현이 아닌 평이하고 단순한 표현만으로도 감동적인 연설을 해낼 수 있다.
시스템 개발에서도 마찬가지이다.
프로젝트의 목적을 이해하고 사용자의 입장에서 알기쉽게 단순화하여 설계를 하는것이 중요하다.
SOLID
오브젝트 지향설계에 관한 원칙의 앞글자를 딴 SOLID라는 개발원칙이다.
| 약자 | 의미(en) | 의미(ko) | 설명 |
|---|---|---|---|
| S (SRP) | Single Responsibility Principle | 단일 책임의 원칙 | 클래스를 변경하는 이유는 하나뿐이어야한다 |
| O (OCP) | Open/closed principle | 개방폐쇄원칙 | 클래스는 확장에 개방적이고 수정에 폐쇄적이어야한다 |
| L (LSP) | Liskov substitution principle | 리스코프 치환 법칙 | 서브 타입은 언제나 기반 타입과 호환될 수 있어야 한다 |
| I (ISP) | Interface segregation principle | 인터페이스 분리원칙 | 사용하지 않는 인터페이스는 구현하지 말아야 한다 |
| D (DIP) | Dependency inversion principle | 의존성역전의 원칙 | 상위모듈은 하위모듈에 의존해서는 안된다 |